Re: GMenuModel has landed
- From: Stefan Sauer <ensonic hora-obscura de>
- To: gtk-devel-list gnome org
- Subject: Re: GMenuModel has landed
- Date: Sun, 11 Dec 2011 21:14:47 +0100
On 12/09/2011 01:00 AM, Ryan Lortie wrote:
> hi,
>
> Today I landed the GMenuModel work on glib master. A release will be
> following shortly.
Just one quick question - why is this in GLib? Is that to allow
command-line apps to have a menu?
Stefan
> There is related work in the 'wip/gmenu' branch of Gtk+ that will
> hopefully be landing soon. There is a trivial example in
> gtk+/examples/bloatpad.c that demonstrates some of the ideas here.
>
> 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.
>
> GMenuModel is an interface to describe the content of a menu and GMenu
> is its obvious implementation (think GtkTreeView vs. GtkTreeStore).
> Your application will construct a series of interlinked GMenu instances
> to describe the content of your menus. Fortunately, there is an XML
> parser to do this automatically. It is integrated with GtkBuilder.
>
> Providing the menu in abstract form instead of GtkWidget form addresses
> a few long-standing issues in Gtk. The most notable one is that we will
> finally have proper support for the menubar on the mac.
>
> 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
>
> 2) this is how the mac universe operates
>
> The API to set the menubar for the application is, unsurprisingly:
>
> void g_application_set_menubar (GApplication *application,
> GMenuModel *menubar);
>
> A new type of menu has also been introduced: the application menu. This
> is the menu that gnome-shell currently only has a "Quit" item in. Your
> application can now control the contents of this menu by whipping up a
> GMenu and setting it:
>
> void g_application_set_app_menu (GApplication *application,
> GMenuModel *app_menu);
>
>
> We may add other types of menus in the future. A jumplist/dock menu
> comes to mind.
>
> GMenuModel is a strictly read-only API. It describes the structure of a
> menu, but has no support for invoking actions when items in the menu are
> clicked. This is handled through the already-existing (but now
> improved) GActionGroup API.
>
> 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).
>
> For example:
>
> <item label='_Quit' action='app.quit'/>
>
> Clicking this menu item would result in the 'quit' action being invoked
> on your GApplication.
>
> There is a new GActionMap interface that GApplication now implements.
> It can be used to easily add actions to your GApplication.
>
> 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.
>
> There are two new XSettings properties that have been added to
> gnome-settings-daemon that specify if the shell will show the
> application menu or the menubar. These values have hard-wired defaults
> on non-X platforms.
>
> shows-app-menu shows-menubar
> gnome-shell: yes no
> GNOME 2: no no
> unity: yes yes
> mac os: yes yes
>
> If a particular desktop environment doesn't show a menu then it will be
> displayed at the top of each GtkApplicationWindow associated with that
> application. For example, on gnome-shell, the menubar set with
> g_application_set_menubar() will be at the top of each window, but on
> the mac, it will be at the top of the screen.
>
>
> We're currently open to making changes to the APIs, so please check them
> out and give feedback, but remember that they may change. If you have
> questions about how to use something, please reply here and I'll answer
> it for the benefit of all. I hope to use the contents of this thread as
> the basis for writing some introductory material on the topic.
>
> Cheers
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]