Retire native splash loading

[vogella]

This is a follow-up from a discussion about the usefullness of the native splash handler we had in the PMC call.

As the Java code which shows the splash is executed relatively fast, it was indicated that we could stop loading the bmp at startup time and leave the loading of a potential splash to the Java splash handler.

WDYT @tjwatson @nnemkin @akurtakov

[nnemkin]

I'd love to remove it. Early window system initialization in the launcher and splash screen hand-off to SWT require some messy code. Both the launcher and SWT could be significantly simplified if we remove the native splash screen.

I know that non-OSGI SWT app startup is fast enough to implement the splash in Java, but I'm not sure about the platform.

[tjwatson]

I'd love to get rid the native launcher altogether and replace it by simple sh/bat scripts. If it isn't going to display the splash natively what is the point of all the complexity in building and running a native launcher? I suppose some native branding?

[nnemkin]

@tjwatson Good UX on Windows and macOS requires a native executable. It's not just branding, though branding is important. Various system and 3rd party services (for example, antivirus and firewall) identify running programs by their executable.

Cutting the launcher down to the bare minimum would be great. But I suspect that consumers depend on gazillion options being available in eclipse.ini.

[merks]

Getting rid of the launcher entirely seems super disruptive to anyone building products currently...

[tjwatson]

OK OK, just wishful thinking.

[tjwatson]

Cutting the launcher down to the bare minimum would be great. But I suspect that consumers depend on gazillion options being available in eclipse.ini.

On this point, other products I work on that use a script to launch java easily parse something like an eclipse.ini to get things like JVM args to pass to an exec of java.

[mickaelistria]

@tjwatson sticking to splash for this bug seems to be enough ;)

That said, is you don't like much having native launcher in Equinox and feel it's more part of Eclipse Platform to maintain them, it could probably be worth moving it to eclipse-platform project.
@nnemkin Can't a bash script be wrapped (by client) into an executable? I do sympathize with @tjwatson on that aspect: is it really worth for platform to ship binaries? Is it best for branding anyway (I've worked on several RCP applications, and ofter we were hiding the apps folders and files under a parent directory anyway, to group with other stuffs, or even to allow shipping 1 multi-platform zip; a bash script would have been as good).

[akurtakov]

Native launcher takes care of opening files on Gtk. Can it be done differently? Sure, it just hasn't been until now. Regarding splash screen itself - I like the idea and having simpler natives is always better.

[vogella]

Lets bring this to the next PMC meeting to decide. Afterwards we can start the changes, if the PMC agrees.

[vogella]

The PMC decided that we want to remove the native splash support. To avoid late regressions, we should do this early 4.25.

RCP and IDEs will still be able to show the splash via the Java spash handler. 3.x apps can specify this via the product and e4 apps can use the life cycle hook.

[akurtakov]

@nnemkin Are you working on this one? As I've been looking into adding Gtk 4.x support, not dealing with image loading would simplify it.

[github-actions]

This issue has been inactive for 180 days and is therefore labeled as stale.
If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below.
Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.