Re: GMenuModel has landed

[Jannis Pohlmann <jannis xfce org>]

On Thu, 08 Dec 2011 19:00:01 -0500
Ryan Lortie <desrt desrt ca> wrote:

> The main thing to understand about this work is that we are changing
> how menus work in Gtk+.  The days of constructing a GtkMenuBar widget
> and packing it into a VBox at the top of your window are gone.

First of all: I like this. I assume that application and window menus
are exported by some means so that e.g. desktop environments can
display them in whatever form they like (mac-like global window menu,
docks, indicators)? How is this done (I'm guessing D-Bus)?

> GMenuModel is an interface to describe the content of a menu and GMenu
> is its obvious implementation (think GtkTreeView vs. GtkTreeStore).

Hmm, we have GtkTreeModel and its implementation GtkTreeStore, and now
GMenuModel and its implementation GMenu. IMHO the name GMenuModel
suggests it's a model for a GMenu. How about calling it GAbstractMenu
and GMenu? Or maybe even switch names so that GMenu refers to the
interface and G<Something>Model is the implmentation?

> Menubars are no longer a per-window concept.  They are now set for the
> entire application.  This is done for two reasons:
> 
>   1) every app already has the same menubar (content) in each window

How about apps that add/remove items or change the sensitivity of menu
items depending on the selection inside the window? An example of this
would be a file manager that adds items to the "File" menu depending on
whether a file or folder is selected in the directory view of a
window.

> The API to set the menubar for the application is, unsurprisingly:
> 
> void      g_application_set_menubar     (GApplication *application,
>                                          GMenuModel   *menubar);

How about calling it 

  g_application_set_window_menu() 

and the other one 

  g_application_set_app{lication}_menu()? 

It seems weird to talk about a menu "bar" if all you are trying to do
is specify a menu for your windows. Who knows how it will be
displayed (maybe just a button like in Chromium?) Perhaps it shouldn't
even include references to graphical elements like windows and instead
be called something like 

  g_application_set_main_menu()

but this might be too easy to confuse with _app_menu() conceptually. In
any case, I find "set_menubar" a bad name.
 
> void      g_application_set_app_menu     (GApplication *application,
>                                           GMenuModel   *app_menu);

Sorry, I'm really picky today. Why "application" but "app"? It almost
sounds like the app is something different than the application itself.
Personally, I wouldn't mind the extra typing.

> We may add other types of menus in the future.  A jumplist/dock menu
> comes to mind.

Yay! I'd be really happy if we got an easy way to integrate such
features in Xfce almost for free. :)
 
> When creating a menu item, you specify an action name.  This looks
> like "app.preferences" or "win.fullscreen".  The part before the dot
> is the location of the action (in this case the hard-coded strings
> "app" and "win" refer to app-wide and window-specific actions,
> respectively).

Again, I'd prefer "application" and "window" over "app" and "win". I
see no need for this shortening. Another question: Is there any reason
not to use "/foo/bar" instead of "foo.bar"? Since we're using '/' as a
separator in GTKUIManager this might feel a little more consistent. (Of
course, people dealing with D-Bus a lot will feel at home with '.'.)

> Gtk also has a new class called GtkApplicationWindow that implements
> GActionMap.  That's where the "win." actions go.  Even though the menu
> is globally-specified at the level of the application, the actions are
> correctly routed to the appropriate window automatically.

I'm interested in how this is done. Would you mind to explain or point
to code/documentation?
 
  - Jannis