After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 639925 - g_application_run() is sometimes too late to init GTK+.
g_application_run() is sometimes too late to init GTK+.
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gapplication
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-01-19 08:44 UTC by Murray Cumming
Modified: 2011-03-19 12:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Murray Cumming 2011-01-19 08:44:24 UTC
g_application_run() takes the argc and argv parameters so it can call gtk_init(). However, it would be helpful if g_application_new() and gtk_application_new() optionally took these instead. Then GtkApplication can make it unnecessary for applications to call gtk_init().

At the moment, if my main() does not call gtk_init(), then I can't call any other methods, such as gtk_window_new() before calling gtk_application_run(). I understand that you'd prefer me to do that in an "activate" signal handler, because this run might not be the primary instance, so my GTK stuff might not be necessary, but I might not want that efficiency forced on my application structure. This is particularly awkward for language bindings such as gtkmm.

Is there any reason to force application developers not to use GTK+ unnecessarily, instead of just helping them to do that?
Comment 1 Christian Dywan 2011-01-19 09:59:44 UTC
Why does this matter to bindings?

The reason as far as I'm aware is to make startup fast by avoiding X11 at startup if it's not the primary instance. It's not just structure but performance.
Comment 2 Murray Cumming 2011-01-19 10:45:20 UTC
Because bindings have more "automatic" memory management. At least in C++, we are very likely to instantiate objects before calling g_application_run(), and we might even be instantiating them implicitly without being aware of it. To instantiate gtkmm objects we need GTK+ to be initialized.

Performance is a good reason to allow people to avoid that, but it should not be forced on people.

I have worked around this in gtkmm's Gtk::Application for now, but my hack feels fragile because I am forced to remember the argc and argv until later so I can provide them _again_ to g_application_run().
Comment 3 Matthias Clasen 2011-01-19 16:50:58 UTC
The best value to pass to gtk_init() is NULL,NULL, anyway, so I don't see the particular relevance...
Comment 4 Murray Cumming 2011-01-20 08:05:22 UTC
(In reply to comment #3)
> The best value to pass to gtk_init() is NULL,NULL, anyway, so I don't see the
> particular relevance...

It is? That would be ideal. But that's not mentioned here:
http://library.gnome.org/devel/gtk/unstable/gtk3-General.html#gtk-init
or here:
http://library.gnome.org/devel//gio/unstable/GApplication.html#g-application-run
Comment 5 Murray Cumming 2011-02-09 11:45:48 UTC
It would really help me to wrap GtkApplication properly in gtkmm if you could explain.

If we should pass NULL, NULL to g_application_run() then why are the parameters there anyway?

And is there some particular way to use G/GtkApplication together with g_option_context_parse()?
Comment 6 Murray Cumming 2011-03-19 12:54:55 UTC
(In reply to comment #5)
> It would really help me to wrap GtkApplication properly in gtkmm if you could
> explain.

That was answered and documented in bug #643649.
Comment 7 Murray Cumming 2011-03-19 12:58:36 UTC
Gtk::Application's constructor takes argc/argv optionally, so that C++ coders can decide to initialize gtkmm and gtk earlier. Gtk::Application is generally unfinished though.

I'm closing this because this is probably not interesting to C coders, who may be happy to call gtk_init() separately anyway. And GtkApplication seems to be pushing developers hard to make their application's single-instance (though without an explanation of why), so it therefore makes sense to discourage earlier initialization of gtk.