Fwd: GtkApplication and argc/arv

["jose aliste gmail com" <jose aliste gmail com>]

(I am sorry to Tristan, as I forgot to answer to the list the first time)

---------- Forwarded message ----------
From: jose aliste gmail com <jose aliste gmail com>
Date: Fri, Feb 25, 2011 at 4:31 AM
Subject: Re: GtkApplication and argc/arv
To: Tristan Van Berkom <tvb gnome org>


Hi

On Thu, Feb 24, 2011 at 8:52 PM, Tristan Van Berkom <tvb gnome org> wrote:
> 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.

Yeah, indeed, but the thing is, although evince is quite stable these
days, It will still crash now and then with some
akward pdf files, and actually, it was moved from a single instanced
app (it was one by 2.26) to a one process per document app so when it
crashes, only the culprit document instance will close.

>
> 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).
>
I am not arguing against GtkApplication. I see there are some
plans/api to make GtkApplications more easily integrated in the shell
and a lot of other nice things, it allows to reduce some code that
apps were replicating, etc.  but by the reason I mentioned earlier, I
don't think it's desirable to have evince ported to it, just because
not being single instance is a  feature, and not a bug, from my point
of view, for evince.

Cheers

José




> Cheers,
>       -Tristan
>