Fix darktable.gui initializing and cleanup

[jenshannoschwalm]

1. We don't want to clear darktable.gui in dt_gui_gtk_init() as we did that via calloc very early. Some things have been set up so far, one example is the last module group in darkroom.
2. Initialize the mutex early so we can't run into undefined mutex lock/unlock, make sure we destroy it whenever we cleanup.
3. Avoid darktable.gui memleaks

@wpferguson you might also want to check :-)

[dterrahe]

So I was curious why the gui needed any mutexes. "Intuitively" the gui object would only be accessed in the gui thread (but obviously, there could be exceptions (that might still benefit from rewriting using signals, but anyway)).

Doing a search, the mutex seems to only "protect" the show_focus_peaking field. As far as I can tell, that is only accessed in the gui thread, so...

darktable.gui is initialised early "ensure that we can load the Gtk theme early enough that the splash screen..." but then, the value of gui->gtkrc that is set during that early dt_gui_theme_init does not seem to ever get used again (or it would have suffered from the memset(0), so might as well be a local variable (and darktable.gui allocated and initialised later, for example in dt_gui_gtk_init itself).

Don't know where the last module group in darkroom is initialised? I see darktable.gui->grouping = dt_conf_get_bool("ui_last/grouping"); with the rationale "we initialize grouping early because it's needed for collection init". I'm not sure I understand that or whether a such a dependency would make logical sense. But nobody will want to dig into that now.

[ralfbrown]

Doing a search, the mutex seems to only "protect" the show_focus_peaking field. As far as I can tell, that is only accessed in the gui thread, so...

Concur. So the mutex can be removed (if one wanted to be extra-sure to avoid races on show_focus_peaking, it could be made atomic).

[jenshannoschwalm]

Focus_peaking yes, but also dt_gui_gtk_write_config() and dt_gui_gtk_load_config()

Don't know where the last module group in darkroom is initialised? I see darktable.gui->grouping = dt_conf_get_bool("ui_last/grouping"); with the rationale "we initialize grouping early because it's needed for collection init". I'm not sure I understand that or ...

Neither me but as darktable.gui was memset zero later that idea was not working anyway :-)

[dterrahe]

dt_gui_gtk_write_config() and dt_gui_gtk_load_config()

Presumably those were meant to make sure they picked up the latest versions of focus peaking. They also run in the gui thread only. Presumably focus peaking was originally implemented in the pipe so it may have had a purpose at some point, but not now as far as I can tell.

[TurboGit]

So let's remove this mutex on early cycle for 5.6 to have some field testing. But as said here, a mutex for something only in GUI thread is not needed so we should be safe.

[jenshannoschwalm]

oki, doki