Leaving this open to deal with documenting how to do it manually in 
the meantime, e.g. by moving the testmerge code to gtk-demo and/or 
adding it as an example to the connect-proxy signal documentation.

Urk, that comment was obviously meant for the other side of the 
dependency...

I have some code that provides a main window class (deriving from GtkWindow) which includes these features:

* UI Manager based menus (using some placeholders to arrange them properly)
* Quit and Close menu items (though these two need to be implemented yet)
* Optional statusbar (depends on a construct property)
* displays the tooltips for menu items in the status bar
* provides callback to save/restore window position and size

Do you want me to attach it?

The different and missing part is basically implementing a these MDI schemes (and a way to choose one):

Single-Window-App
 * hide "Quit" as "Close" is the same (and in case the user opens multiple
   windows, "Close" will still behave as with SDI - "Quit" would not)

SDI
 * implement quit as "go through the list and close one after the other"
 * this should use one list per class/type

MDI
 * implement quit as "close window" after emitting a "close" signal for every
   open document

Herzi: yes, please attach that code!

I think MDI issues are orthogonal to an AppWindow widget.  The MDI handler could wrap the appropriate bits of the menu API.

herzi: ping

Created attachment 80599 [details]
Header file of my code

Created attachment 80600 [details]
C-Source file of my code

These are the files that I'm using in several projects.

Progress in abstract base class for applications: http://live.gnome.org/GTK%2B/ApplicationClass

*** Bug 588855 has been marked as a duplicate of this bug. ***

*** Bug 533003 has been marked as a duplicate of this bug. ***

Created attachment 158630 [details] [review]
Add GtkApplication

This is a work in progress to stub out an application class.  The
primary goal is to provide a mechanism for applications to export
GtkActions, and there is a standard "Quit".

Future work:
 * Rebase on GApplication
 * Manage toplevel GtkWindows
 * Add a way to say "This is my application menubar", which gets
   put into all toplevel windows on non-OS-X, and into the top
   on OS X.

(In reply to comment #12)
>  * Add a way to say "This is my application menubar", which gets
>    put into all toplevel windows on non-OS-X, and into the top
>    on OS X.

Do I understand this right if I think "this patch is a preparation for the appwindow widget"?

The appwindow would then automatically have a GtkMenubar being built from the GtkApplication (unless being executed on Mac OS X or a GNU/Linux desktop using a global menu bar).

Will we need to have GtkUIManager support for the global menu? It would be great if the global menu could be managed by a GtkUIManager.

It would be great to have an analysis if we would need to break GtkUIManager (ABI and/or API) for this.

Created attachment 159032 [details] [review]
Add GtkApplication

This is a work in progress to stub out an application class.  The
primary goal is to provide a mechanism for applications to export
GtkActions, and there is a standard "Quit".

This is based on GApplication; see
http://people.gnome.org/~walters/gapplication-standalone.git/

Future work:
 * Manage toplevel GtkWindows
 * Add a way to say "This is my application menubar", which gets
   put into all toplevel windows on non-OS-X, and into the top
   on OS X.

Review of attachment 159032 [details] [review]:

A little comment: Do not use gtk_application_get_private() but app->priv instead. Also, I think It's not needed to seal the priv member in public structure.

Created attachment 159277 [details] [review]
Add GtkApplication

This is a work in progress to stub out an application class.  The
primary goal is to provide a mechanism for applications to export
GtkActions, and there is a standard "Quit".

This is based on GApplication; see
http://people.gnome.org/~walters/gapplication-standalone.git/

Future work:
 * Manage toplevel GtkWindows
 * Add a way to say "This is my application menubar", which gets
   put into all toplevel windows on non-OS-X, and into the top
   on OS X.

My comments to Colin were that, the GApplication interface should make it easy to add new "actions" (remote object methods) that would require arguments, or return arguments. Either through the GApplication API, or making it easy to implement new methods through GDBus (although it might lose some of its cross-platform appeal).

Also, should GtkApplication have a "present" action, to show the main window?

The patch to add GtkApplication should have one example of a stand-alone app, a single-instance application passing extra options, and an app that shows the exported actions for a running app.

just for reference: the wip/gapplication branch in GLib has the GApplication code from gapplication-standalone and is currently under review.

The GtkApplication patch now exists as a GTK+ branch off of gtk-2-22:

http://git.gnome.org/browse/gtk+/log/?h=wip/gapplication-2-22

I've always thought it would be nice to handle "initial launch of first instance" with the exact same callback as "new document filenames received from a second invocation" e.g. 
http://mail.gnome.org/archives/gtk-devel-list/2007-August/msg00039.html
in order to ensure that there weren't two codepaths, one rarely-tested.
Another advantage of this is that it actively discourages "args that only make sense for the first instance" / "args that cannot be forwarded"

Another random question is whether it automatically (by default) quits on losing the bus name, allowing --replace . If it does do this, then Quit dbus method isn't really required, since anyone can just take the bus name then drop it. Though Quit is perhaps more obvious. Also, --replace could be a default option automatically provided by gtk.

btw, gtk-example-application.c could be shorter ... some kind of convenience function would really be nice, or just an example with fewer bells and whistles in the docs.
Compare to: http://doc.trolltech.com/4.3/tutorial-t1.html
Yeah that program isn't doing quite as much, but nonetheless. The builder and action group stuff in the example looks like it's just itching for some kind of convenience API.

(In reply to comment #20)
> The GtkApplication patch now exists as a GTK+ branch off of gtk-2-22:
> 
> http://git.gnome.org/browse/gtk+/log/?h=wip/gapplication-2-22

Will this be merged in GTK+ 2.22, or just for GTK+ 3.x?

This was already merged in GTK+3