Add logic for migrating to Jaunch launcher #94
Conversation
ctrueden
commented
Nov 19, 2024
ctrueden
commented
- Update license blurbs for 2024
- ImageJUpdater: let any/all services be null
- ImageJUpdater: Do not update the updater separately
- WIP: Add logic for migrating to Jaunch launcher
The code was already written to support the services not being set, with various fallbacks in place. So let's mark the params accordingly.
The removed code does the following:
* check if the updater can be updated
* if yes, download updater and it's dependencies and install it,
do not ask for approval
* try to restart the updater in place
* if that does not work, ask for restart of Fiji
This is why it should be removed:
* if other components depend on the updater, this can break the installation
because the other component will not get updated at the same time as the updater
* the updater will be updated without the users approval
CTR: I asked Johannes why this logic was introduced. Here is what he said:
> The reason was dependency hell. If you don't update the updater first,
> then create a new class loader, then re-load the updater and run it,
> it really can break everything, especially when imagej-ui-swing is
> updated (and not necessarily the updater).
CTR: So really, there are things that can go wrong either way. In the
interest of simplicity, we remove the logic. If all hell breaks loose,
we can put it back, and deal with the fallout as best we can. But I
expect that removing this logic will fix more problems than it causes.
Closes #83.
Signed-off-by: Curtis Rueden <[email protected]>
ctrueden
force-pushed
the
new-launcher
branch
5 times, most recently
from
7e3a1fe to
6cfcad4
Compare
ctrueden
force-pushed
the
new-launcher
branch
from
4c3fc6e to
cb78283
Compare
|
Note that some of the art on the update buttons does not render on windows:
|
|
Other problems: I mentioned here that when I build Jaunch locally, copy it over to a However, this also happens if I copy jaunch executables to a
Incidentally I also opened fiji/fiji#375 but that is probably related to how the restart is being handled, also. Maybe we shouldn't do the auto-restart for the user? It may be too magical and on non-Mac I can see people being confused about having to use a different executable. We probably want to tell them to remove their |
|
Here are some alternative art sequences that replace the broken characters in the screenshot above with ASCII ones:
|
This is precisely why I did code up the auto-restart: so they don't need to choose correctly between |
I see. I guess an upgrade has never fully succeeded on my system so I was not aware that the
|
Nah, the rename of the old executable just isn't implemented yet by the migrator.
Great! |
