GtkApplication

[Matthias Clasen <matthias clasen gmail com>]

So, I've been dragging my feet a little bit on getting
GApplication/GtkApplication merged.

After looking at the stuff again for the last two evenings, I think we
should probably just get over it and merge most of what is currently
there. I don't think the current functionality

- uniqueness
- actions
- standard actions (Quit, Activate)

 is controversial.

There are some points I am not really happy with, though, and want to
air at least one more time here:


1) The GApplication/GtkApplication split and some of the object
construction gymnastics that it forces us to do, ie
g_application_new_subtype with its callbacks and the thread-private
construction data hack. One of outcomes here is that g_object_new
(GTK_TYPE_APPLICATION) will not work, which will make bindings people
unhappy.

One thing that I've proposed to Colin to make this at least somewhat
less ugly is to move most of the 'special-sauce' constructor work into
a separate api, like

g_application_register (GApplication    *app,
                                  gint                 *argc,
                                  gchar           ***argv,
                                  GVariant          *platform_data)

Then gtk_application_new could look more like this:

 app = g_object_new (GTK_TYPE_APPLICATION, "appid", appid, NULL);
 g_application_register (app, argc, argv, gtk_application_get_platform_data ());


2) There is no session management at all, currently. We can _probably_ add it
at a later point, but there are some questions about the larger story
for app authors here. If we say that apps should just keep their state
safe at all times and Quit is enough, then we probably want to make
gnome-session just call Quit on apps instead of its current
query-end-session/end-session/stop dance. Or is gnome-shell taking
over session handling and calling Quit on all apps ? But that does not
cover the inhibit functionality that gnome-session currently has.

On the other hand, the gnome-shell api is very close to the Windows
API for this, so supporting that would give us a chance of doing
things in a portable way.

If we were to go with just taking the current gnome-session api more
or less 1-1, it would look like the following, maybe:
enum GtkApplicationInhibitFlags {
 GTK_APPLICATION_INIBIT_LOGOUT,
 GTK_APPLICATION_INHIBIT_USER_SWITCH,
 GTK_APPLICATION_INHIBIT_SUSPEND,
 GTK_APPLICATION_INHIBIT_IDLE
};

void
gtk_application_inhibit (GtkApplication             *app,
                                  GtkApplicationInhibitFlags  flags,
                                  const gchar                *reason)
gtk_application_uninhibit (GtkApplication *app)

gboolean
GtkApplication::query-end-session  (GtkApplication *application,
                                                    gboolean        forced);
gboolean
GtkApplication::end-session           (GtkApplication *application);
void
GtkApplication::cancel-end-session (GtkApplication *application);

void
gtk_application_end_session_response    (GtkApplication *application,
                                                            gboolean
        is_ok,
                                                            const
gchar    *reason);


As I said earlier, it is probably ok to leave this out in the initial
merge, but it definitively feels like an api gap to me.


3)   /* TODO look up .desktop file on freedesktop platform, initialize
title etc. */

We should get this done to make the get_window() have some tangible benefit.
Of course, we don't want to read all desktop files just to find the
right one. Until we have a better solution, what Colin and I have
discussed is to have the launching app (who most likely already has
the desktop file in hands) put the path of the desktop file into an
environment.



Matthias