Suggestion: Dynamic GTK message box when GTK 3 or 2 is available (Working example included)

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Dynamic GTK 3 and 2 simple example, requires linking of -ldl only. Tested on Linux Mint 18.2 and Cent OS 7 (both 32 and 64 bits). (gtk_msg_box.c, text/x-csrc, 2017-08-13 21:02:07 +0000, 12525 bytes)

Reported in version: HG 2.1
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2017-08-13 21:02:07 +0000, Vitaly Novichkov wrote:

Created attachment 2840
Dynamic GTK 3 and 2 simple example, requires linking of -ldl only. Tested on Linux Mint 18.2 and Cent OS 7 (both 32 and 64 bits).

We are can have better-looked message box on Linux systems when we will use GTK library. I have implemented a simple example to show message box through GTK. No extra includes and linked libraries are required, everything is detecting dynamically.

When GTK fails to be loaded or initialized (is wrong version, or absence), we can just use regular X11 way.

I have included a simple example which can be built by simple "gcc gtk_msg_box.c -o msg -ldl" command. If GTK fails to be initialized, the loadGtk function returns zero.

On 2017-08-22 18:16:18 +0000, Ryan C. Gordon wrote:

My understanding is that there is a gtk_init() function, but no gtk_quit(); GTK+ apps are expected to stay initialized until they are terminated, so we can't completely clean up GTK+ once we use it for a message box.

--ryan.

On 2017-08-22 19:10:04 +0000, Vitaly Novichkov wrote:

As those libraries are initalized dynamically, we can try to quit GTK by simple closing of those libraries. In this example I made "unLoadGtk()" function to close opened GTK libraries. GTK is designed to terminate when application will close, but case is here we closing GTK libraries and there are thinking like "app that uses them is closed". The trap is only when GTK is linked to application. Case is here - it is not linked and used dynamically only.

On 2017-08-22 19:24:58 +0000, Vitaly Novichkov wrote:

Okay, I have tried to make a simple experiment which will load GTK2 and GTK3 sequentially (with closing of previous) to get a proof that is GTK unloaded by dlclose():

Okay, I have tried to this experiment: I tried to load GTK2 and then close library and load GTK3, and I have got this:

(msg:10594): GLib-GObject-WARNING **: cannot register existing type 'GdkDisplayManager'

(msg:10594): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(msg:10594): GLib-GObject-CRITICAL **: g_object_new: assertion 'G_TYPE_IS_OBJECT (object_type)' failed

But on attempt to do same with GTL3 -> GTK2 order, I getting this:

(msg:10660): GLib-GObject-WARNING **: cannot register existing type 'GdkDisplayManager'

(msg:10660): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(msg:10660): GLib-GObject-CRITICAL **: g_object_new: assertion 'G_TYPE_IS_OBJECT (object_type)' failed

(msg:10660): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(msg:10660): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(msg:10660): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(msg:10660): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(msg:10660): GLib-GObject-WARNING **: cannot register existing type 'GdkDisplay'

(msg:10660): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(msg:10660): GLib-GObject-CRITICAL **: g_type_register_static: assertion 'parent_type > 0' failed

(msg:10660): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(msg:10660): GLib-GObject-CRITICAL **: g_object_new: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
Segmentation fault

seems dlclose() doesn't unloads library completely or I will need load so differently, or call some extra function to finally get rid of GTK loaded into memory, will look for solution...

On 2017-08-22 19:31:12 +0000, Vitaly Novichkov wrote:

Okay, I have checked out the source code of "gtk_init()" and used functions by it seems it must not be something hard for system: it just parses arguments and sets some simple variables, but don't actually starts GTK by itself (which I guess, must be started on gtk_main() call only). This must work fine even you did dlclose() and dlopen() of it again, but okay, with my experiment, we can't switch GTK version on a fly.

https://code.woboq.org/gtk/gtk/gtk/gtkmain.c.html#gtk_init

[Wohlstand]

This feature I suggested a while ago to make the message box look nicer and better support any non-ASCII characters. I took the care to make this work without direct linkage to GTK libraries making them be optional: the generic X11 fallback will be worked instead of GTK-based won't work for any reason.

The last notice was against gtk_init() call that it hasn't "gtk_quit()" alternative. I had inspected the stuff, and the gtk_init() doesn't do anything other than just setting internal variables required for the framework's work. But I got no reply after that. @icculus, let's resume the discussion once you can?

[icculus]

I'm tossing this into the current milestone to take a look at it, but no promises yet.

The Wayland backend farms this work out to a separate process (zenity), to similar effects, so we might want to just unify how Wayland and X11 handle this (whether we use this approach or the existing Wayland code).

[Wohlstand]

Zenity way is just a workaround, mainly, zenity is intended to be used with bash scripts, and looks weird when binary application uses it instead of existing APIs.