Re: GMenuModel has landed

[Ryan Lortie <desrt desrt ca>]

hi Tristan,

Thanks for the questions.

On Fri, 2011-12-09 at 14:56 +0900, Tristan Van Berkom wrote:
> I think that the (twice) mentioned solution to this problem sounds
> elegant enough, i.e. if you have 2 windows with different menubars
> then they can easily be '2 applications' at least in terms of data
> sets.
> 
> However, I'm curious as to how elegantly one can implement this.

Not elegantly, presently.  It's theoretically possible to have two
GApplication instances in the same process, but 'running' them at the
same time (so that the lifecycle of the process is tied to the lifecycle
of either app) looks a bit weird and may actually be impossible.

That's an API fix needed in GApplication, to be sure.

There are also apparently some nasty races involved with trying to use
two names for uniqueness on D-Bus related to how activation works.  Add
those to the normal hazards you have with holding two locks...

> Also, I'm still concerned about GApplication, I raised this point
> last year and I wonder if any progress has been made... what is 
> the fallback ?
> 
> Can g_application_run() please at the very minimum fall back on
> calling g_main_loop_run() when there is no D-Bus daemon ?

Since last year, the situation has improved in two substantial ways:

 - we introduced the concept of "non-unique" applications that don't
   attempt to acquire D-Bus names

 - we made it so that if the D-Bus daemon isn't available, the
   application just continues along as a normal program without
   checking for uniqueness, exporting its actions, etc.

In the future we hope to write better 'native' backends for Windows and
Mac that do more than just ... nothing.

> If I write an application with this abstract GMenu model and then
> run it on a system that by no means has any need to run a D-Bus
> daemon, nor any need to run a window manager, or has a window
> manager that is not GMenu aware at all, what happens ?

See above for the D-Bus thing, but as mentioned in my original email, we
now have two booleans in GtkSettings that are manipulated by
gnome-settings-daemon (ie: same delivery mechanism as the choice of
theme) and control if the menu is shown in the local process.  By
default, the menu is shown, so it is only hidden if the desktop shell
has explicitly indicated that it will show it.

> Can the menu bar automatically display using a basic GtkMenuBar
> in the main GtkApplicationWindow... when there is no D-Bus
> daemon running ?

Yes.  This is exactly what happens.

> Also... concerning MVC menus in general:
> 
> Can this whole GMenuModel and GMenu thing be extendable 
> without modifying GTK+ sources at all ?
> 
> In my imagination, all I have to do is:
>   - Implement menus to understand an extra property name
>     i.e. implement the view, by deriving a GtkMenuItem with
>     widgets to represent that data
>   - Create the data model from my application and assign
>     this extra property name a value, perhaps
>       "is-range" = TRUE and "range-value" = 50
>   - Bingo, all of a sudden I'm using my new GtkScaleMenuItem
>     with an embedded GtkHScale and it's value preset to 50

Indeed, Canonical has extensive plans to do this.  They use menus for
their indicators in the top-right of the screen and they have all manner
of interesting widgetry up there (including a range widget for volume).

One side note that your example brings up: it is not possible to modify
a menu item after it has been created.  For this reason, you would never
see range-value='50'.  Rather, you'd associate the range with a GAction
that has a floating-point (or int) state, which would provide two-way
synchronisation with the application.

Back to the extendablity question: I've played with this before and come
up with a semi-reasonable system to support it.  There would be a
type='' attribute added to menuitems.  If this attribute was present on
the item then Gtk would attempt to open a dynamic module of a given name
from a particular directory.  type='foo' might
hit /usr/lib/gtk-3.0/modules/libgmenu-foo.so for example.

That would be a module/extension-point/etc that implements a factory
interface for creating menuitems of your required type.

So that's the good news -- if you're a desktop environment.

The bad news is this: I don't expect this to be supported on a
per-application basis or to be possible to use at all from the menubars
of an application.  We need to make sure menus will continue to work on
all platforms (including the mac and unity -- which will both display
your menus in a different place, not even using Gtk in the case of the
mac).

This means that you will only be able to use a minimum baseline level of
functionality (labels, checks, radios, accels, icons, etc.) in the
normal menubar and application menu of your program.

What this base level of functionality is has yet to be written down --
and is not entirely known.  It's something that I hope to come to grips
with as we proceed towards the stable release.

Cheers