Excerpts from Tristan Van Berkom's message of vie feb 25 00:52:21 +0100 2011: > On Fri, Feb 25, 2011 at 8:25 AM, jose aliste gmail com > <jose aliste gmail com> wrote: > > Hi, > > > > On Tue, Feb 22, 2011 at 6:45 AM, Murray Cumming <murrayc murrayc com> wrote: > >> On Mon, 2011-02-21 at 21:57 +0100, Murray Cumming wrote: > >>> I'm trying to wrap GtkApplication for gtkmm but I can't really do that > >>> until I understand how it's meant to be used. > >>> > >>> In general, I find the documentation lacks overview and advice, partly > >>> because it's spread between GApplication and GtkApplication and mentions > >>> some concepts without explaining them first. So I have some questions. > >>> > >>> 1. > >>> Are we still meant to call gtk_init(&argc, &argv) when using > >>> GtkApplication, which takes argc/argv again via g_application_run(). Or > >>> is gtk_init() then superfluous? > >>> > >>> Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I > >>> don't understand why: > >>> http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3 > >>> > >>> 2. > >>> How should we use GOptionContext to parse command line arguments from > >>> argc/argv when using GtkApplication. Is this the ideal way, using the > >>> command-line signal? > >>> http://git.gnome.org/browse/totem/tree/src/totem.c#n187 > >>> It seems a little long-winded. > >> > >> And more simply: > >> > >> 3. Will we recommend that all GTK+ applications generally use > >> GtkApplication? > >> > >> 4. Do we believe that all (GTK+) applications should be single-instance > >> applications? > > > > Just to point out an example, Evince does not use GtkApplication and > > it's not single instanced (there is one process per each document you > > see) and I don't think there are plans to make it single instanced. > > Right, > however as I mentioned it would not hurt evince if it was a single > instance, we would save on memory and gain in startup time for every > document that evince is invoked for, without harming evince in any way. We think that robustness is more important than using more memory or taking a bit longer to start (I would like to see the numbers that proof that, since we changed from single process to multi-process nobody has filed a bug report about evince consuming more memory or being slower at startup). Evince depends on external libraries to render pdf, ps, etc. and it's easy to make those libs crash with buggy documents. So, unless GtkApplication allows us to keep our current multi-process model, still behaving as a single-instance app, we are not going to migrate. > Furthermore using GtkApplication everywhere "opens up the door" for > more sophisticated integration that could hypothetically happen > in the future. > > - it would allow for system watchdogs to be implemented without any explicit > cooperation on the part of the application for one, > > - it could serve to provide some basic system messaging for the > desktop and applications, like updating the input method for all > running applications, or even changing the desktop locale and > retranslating messages (albeit runtime translation switching would > of course require more api, but GtkLabel for instance could be > given a translatable format and retranslate itself automatically whenever > the desktop language changes...). > > I'm not saying that everybody should hurry up and do extra work they dont > need to... however I do think having a unified GtkApplication api with as many > apps using it as possible seems to be a step in the right direction (whether > its the GNOME Shell that communicates with the GtkApplication, or > MyCustomHandPhoneShell that uses it... having a well defined/unified > api for this stuff seems like a good thing to have). > Regards, -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
Attachment:
signature.asc
Description: PGP signature