Relax splash on top

[jenshannoschwalm]

While we possibly spend a lot of time (like in xmp crawler ...) while having the splash screen open users might want to do other work but the splash requested to be "above" prohibits that.

So let us not interfere in WM/user actions.

See #18209

---

Other options "how-to-fix" might be gtk_window_set_keep_above(GTK_WINDOW(splash_screen), FALSE) after some timeout or alike.

[ralfbrown]

That sort-of works - at the end of startup, the main window pops in front of the splash screen (obscuring it with a blank window) for a couple of seconds before it resizes to its final dimensions and the splash screen goes away.

[dterrahe]

This stuff is all so horribly non-standardized and platform and even window manager specific, so no matter what you do, you won't get any guarantees.

the main window pops in front of the splash screen

One idea, that avoids tinkering with transient/urgency/type_hint/above/below/focus/lower/restack/etc, is delaying

gtk_widget_show_all(dt_ui_main_window(gui->ui));

until everything is ready (including libs/iops/views). Previously you'd want the main window to pop up as early as possible, even when empty, so there would be something showing, but now there's the splash for that...

Care needs to be taken; calling show_all later, when all libs etc are added, might unhide stuff that was specifically hidden in the current order. So you need to replace gtk_widget_show_all(dt_ui_main_window(gui->ui)); with gtk_widget_show_all(widget); to mark all contents of the main window visible and then at the end (after closing the splash in dt_init with darktable_splash_screen_destroy) just call gtk_widget_show (not _all) on main_window. (gtk_widget_show(dt_ui_main_window(darktable.gui->ui));)

If you do this, dt_colorspaces_set_display_profile will complain, with gtk errors, that the main gtkwindow doesn't have a gdkwindow yet, but the explicit call to dt_colorspaces_set_display_profile in dt_gui_gtk_init isn't needed anymore anyway, because when the window is finally shown, it will send a configure event which will update the display profile.

There's another critical in dt_control_change_cursor. Don't know why that's needed anyway (or if it still is) and where it might best be moved to.

Also, obviously, the case where the splash is shown longer for crawling or isn't shown needs to be considered. But with the splash, tested on linux/wayland/windows, showing only the splash until fully ready makes for a smoother experience (for me).

[dterrahe]

Separately it might make sense after dt_control_crawler_run to

if(!dt_conf_get_bool("show_splash_screen")) darktable_splash_screen_destroy();

otherwise it is confusing/not obvious why that setting is ignored/makes no difference. (#18228)

[ralfbrown]

dt_gui_gtk_init is already being called before the main window gets shown, and I haven't seen any warning/error messages.

Just moving the show_all to immediately before if(changed_xmp_files) seems to do the trick with no obvious bad effects.
(oops, forgot to comment out the keep_above - without the keep_above, I still get a flash of the unresized main window, but it seems noticeable quicker)

I had the same thought you did about destroying the splash screen after the crawl if the user pref is to not show it.

[dterrahe]

OK, turns out there already was a

gtk_widget_show_all(dt_ui_main_window(darktable.gui->ui));

immediately after dt_gui_gtk_load_config, which could be (re)moved to just before darktable_splash_screen_destroy. Creating the window and then killing the splash is a little smoother than killing the flash and then having a second gap before the full window has layouted.

It would be nice to add darktable_splash_screen_set_progress(_("loading utility modules")); just before dt_lib_init and darktable_splash_screen_set_progress(_("loading views")); just before dt_view_manager_gui_init so that the splash doesn't blame the processing modules for all of that. dt_gui_process_events doesn't seem to be necessary once the splash closes.

[jenshannoschwalm]

All ideas good and have been force-pushed

@TurboGit for master it would be both commits, for 5.0.1 only the first one because of strings.

[dterrahe]

can be removed

[jenshannoschwalm]

You mean removing the dt_gui_process_events(); ? I thought so too but then dt hangs .

[dterrahe]

referred to process_events which doesn't seem to be needed here.

[jenshannoschwalm]

right, misleading comment

[ralfbrown]

I was working in parallel to the two of you, so between our two PRs we should be able to get something workable without visual glitches.

It turns out that the gtk_widget_show_all in darktable.c isn't actually necessary....

[jenshannoschwalm]

You wanna take over? I have to work on a chicken right now, wife is coming home soon :-)