Re: GMenuModel has landed

[tristan . van . berkom]

On 2011-12-14, at 12:34 AM, Matthias Clasen  wrote:

> On Tue, Dec 13, 2011 at 12:21 AM, Tristan Van Berkom  wrote:
> 
>> GMenuModel in itself is a little stuck, it depends on GActions which
>> are really tied into the whole DBus thing, so even though conceptually
>> it might not be IO, actually it is an IPC data model (I'm really starting
>> to think we should definitely remove the word "Menu" from that
>> data model, GActionModel or GModel even... and keep it low-level
>> generic, reusable and "sweet", not a specially targetted dinasaur just
>> for menus).
> 
> Not sure why you think so. While

Simply because I've only seen GAction
as a counterpart of GApplication apis.

I was not aware of their usefulness 
outside of the 'application' context

> GActions certainly have been designed
> with an eye towards easy exporting on the bus, they work perfectly
> fine in-process as well.

are you arguing that perhaps GAction
as well as the encapsulating GMenuModel abstract interfaces should find a 
living area below libgio ?
(or as I recall, "above" since your
stack was upside down ;))

Personally I think data models & abstract interfaces for working with GObject 
look better in libgobject than
in libgio, it's not worth arguing that to the death but obviously, avoiding 
another occurrence of libgnomeui is worth arguing for... 

Cheers,
  -Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Matthias Clasen]

On Tue, Dec 13, 2011 at 12:21 AM, Tristan Van Berkom  wrote:

> GMenuModel in itself is a little stuck, it depends on GActions which
> are really tied into the whole DBus thing, so even though conceptually
> it might not be IO, actually it is an IPC data model (I'm really starting
> to think we should definitely remove the word "Menu" from that
> data model, GActionModel or GModel even... and keep it low-level
> generic, reusable and "sweet", not a specially targetted dinasaur just
> for menus).

Not sure why you think so. While GActions certainly have been designed
with an eye towards easy exporting on the bus, they work perfectly
fine in-process as well.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Simon McVittie]

On Tue, 13 Dec 2011 at 14:21:37 +0900, Tristan Van Berkom wrote:
> I would have to disagree about treemodel, data models, yes, would
> be nice to push down the stack from way on top in GTK+, but why
> not glib ? Of course I think the treemodel interface would have to
> be re-engineered to reach our expectations of excellence before
> being pushed all the way down to glib, but I think that would be
> more appropriate than "dumping it into libgio just because".

GLib is lower down the stack than GObject, so nothing in GLib can use the
GObject dynamic type system. So, anything sufficiently object-oriented that
it benefits from being a GObject has to go in either GObject or GIO.

At the moment, libgobject is literally just the abstract GObject type system
(including GValue, GType, signals, etc.), and doesn't have any "real-world"
functionality: all the actual uses of GObject are in GIO (or in separate
projects, of course). I think that's a reasonable definition of the layering.

In most distributions, GLib, GObject and GIO are all the same binary package
anyway (e.g. libglib2.0-0 in Debian and derivatives), so you either have
all or none.

S
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Tristan Van Berkom]

On Tue, Dec 13, 2011 at 6:53 AM, Matthew Brush  wrote:
> On 12/12/2011 10:45 AM, Ryan Lortie wrote:
>>
>> On Sun, 2011-12-11 at 18:24 -0800, Matthew Brush wrote:
>>>
>>> My (probably misguided) opinion is that if this type of stuff can't go
>>> into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome`
>>> library or something like this.  I have doubts how many apps linking to
>>> GIO without GTK+ are going to need such a model, either because they
>>> don't have a UI at all or are using some other toolkit which likely
>>> provides a mechanism of its own for this.
>>
>>
>> We had this conversation in context of GSettings, a few years ago.  It
>> wasn't really IO, so why should it go in GIO?  We threw around the idea
>> of libgplatform or libdesktop and so on and decided that we should just
>> treat libgio as this.  That's when we started (only half-jokingly)
>> insisting that GIO stands for "GLib Interfaces and Objects".
>>
>
> I think a separate G library would be an *excellent* idea, much more
> sensible and practical from a "consumer" (app developer) POV.  A quick scan
> through the API docs, I'd nominate the following to be moved to a separate
> library:
>
>  - Icons
>  - Settings
>  - Application support
>  - (the menu stuff)
>
> Everything else in there seems to be, even if not purely "IO", at least used
> by or in conjunction with the other stuff that is (I think).
>
>
>> I have a long-held belief that the "model" side of things that are not
>> directly related to widgets should be kept outside of the toolkit.  I'd
>> support, for example, a GtkTreeModel replacement to be merged into
>> libgio.
>>
>
> Yep, I certainly don't disagree with this either, just that it's strange to
> put this type of stuff in the IO library (IMO).  It feels like there's some
> stuff in the G stack that's looking for a home and everything just winds up
> in GIO, like it's a dumping ground for miscellaneous stuff (which I guess it
> is as you said, presently).
>
> I just fear people will start calling GIO "bloated" and GNOME-bound  and
> might cause people who would've otherwise used this excellent IO library to
> either re-write their own or look elsewhere.

I have to agree with Matthew to an extent, no people will probably not
rewrite their own versions of this code just because we eventually become
terribly disorganized, however they will notice the disorganization of the
stack and will become disgusted with it.

GMenuModel in itself is a little stuck, it depends on GActions which
are really tied into the whole DBus thing, so even though conceptually
it might not be IO, actually it is an IPC data model (I'm really starting
to think we should definitely remove the word "Menu" from that
data model, GActionModel or GModel even... and keep it low-level
generic, reusable and "sweet", not a specially targetted dinasaur just
for menus).

I would have to disagree about treemodel, data models, yes, would
be nice to push down the stack from way on top in GTK+, but why
not glib ? Of course I think the treemodel interface would have to
be re-engineered to reach our expectations of excellence before
being pushed all the way down to glib, but I think that would be
more appropriate than "dumping it into libgio just because".

GtkBuilder belongs in glib for instance, not in libgio.

Cheers,
   -Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Matthew Brush]

On 12/12/2011 10:45 AM, Ryan Lortie wrote:

On Sun, 2011-12-11 at 18:24 -0800, Matthew Brush wrote:

My (probably misguided) opinion is that if this type of stuff can't go
into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome`
library or something like this.  I have doubts how many apps linking to
GIO without GTK+ are going to need such a model, either because they
don't have a UI at all or are using some other toolkit which likely
provides a mechanism of its own for this.


We had this conversation in context of GSettings, a few years ago.  It
wasn't really IO, so why should it go in GIO?  We threw around the idea
of libgplatform or libdesktop and so on and decided that we should just
treat libgio as this.  That's when we started (only half-jokingly)
insisting that GIO stands for "GLib Interfaces and Objects".



I think a separate G library would be an *excellent* idea, much more 
sensible and practical from a "consumer" (app developer) POV.  A quick 
scan through the API docs, I'd nominate the following to be moved to a 
separate library:


  - Icons
  - Settings
  - Application support
  - (the menu stuff)

Everything else in there seems to be, even if not purely "IO", at least 
used by or in conjunction with the other stuff that is (I think).



I have a long-held belief that the "model" side of things that are not
directly related to widgets should be kept outside of the toolkit.  I'd
support, for example, a GtkTreeModel replacement to be merged into
libgio.



Yep, I certainly don't disagree with this either, just that it's strange 
to put this type of stuff in the IO library (IMO).  It feels like 
there's some stuff in the G stack that's looking for a home and 
everything just winds up in GIO, like it's a dumping ground for 
miscellaneous stuff (which I guess it is as you said, presently).


I just fear people will start calling GIO "bloated" and GNOME-bound  and 
might cause people who would've otherwise used this excellent IO library 
to either re-write their own or look elsewhere.


Just my $0.02 as a Joe Random Hacker :)

Cheers,
Matthew Brush
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

On Sun, 2011-12-11 at 18:24 -0800, Matthew Brush wrote:
> My (probably misguided) opinion is that if this type of stuff can't go 
> into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome` 
> library or something like this.  I have doubts how many apps linking to 
> GIO without GTK+ are going to need such a model, either because they 
> don't have a UI at all or are using some other toolkit which likely 
> provides a mechanism of its own for this.

We had this conversation in context of GSettings, a few years ago.  It
wasn't really IO, so why should it go in GIO?  We threw around the idea
of libgplatform or libdesktop and so on and decided that we should just
treat libgio as this.  That's when we started (only half-jokingly)
insisting that GIO stands for "GLib Interfaces and Objects".

I have a long-held belief that the "model" side of things that are not
directly related to widgets should be kept outside of the toolkit.  I'd
support, for example, a GtkTreeModel replacement to be merged into
libgio.

Meanwhile, from an intensely practical standpoint, GMenuModel is already
in use by at least 3 separate toolkits: Gtk+, Qt and the GNOME Shell.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Mikkel Kamstrup Erlandsen]

On 12/12/2011 03:24 AM, Matthew Brush wrote:

On 12/11/2011 12:14 PM, Stefan Sauer wrote:

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?



I tried to ask this here a day or two ago but had problems, so I asked
Ryan on IRC. The answer is that it's in GIO rather than GLib and there
is precedence; GIcon for example.


In Ubuntu, at least, we have quite a few daemons that export menu-like 
constructs which is then rendered in another process (the shell). Think 
distributed model-view-controller where the models are these daemons. 
These daemons have no reason to link to libgtk* (and does not need an X 
connection etc).


(and these daemons happen to use loads of GIcons as well - I love how 
glib/gio separates abstract entities from the actual toolkit)


Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Tristan Van Berkom]

On Mon, 2011-12-12 at 10:18 +0100, Stefan Sauer wrote:
> On 12/12/2011 03:24 AM, Matthew Brush wrote:
> > On 12/11/2011 12:14 PM, Stefan Sauer wrote:
> >> 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?
> >>
> >
> > I tried to ask this here a day or two ago but had problems, so I asked
> > Ryan on IRC. The answer is that it's in GIO rather than GLib and there
> > is precedence; GIcon for example.
> >
> > My (probably misguided) opinion is that if this type of stuff can't go
> > into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome`
> > library or something like this.  I have doubts how many apps linking
> > to GIO without GTK+ are going to need such a model, either because
> > they don't have a UI at all or are using some other toolkit which
> > likely provides a mechanism of its own for this.
> 
> I think this is not so easy. Having a glib-app library sounds goo, but I
> believe we don't want to have too many mini libraries. On the other hand
> I wouldn't look for it in gio either.

I know not everyone is so crazy about the idea, but perhaps this
will be a good starting point for implementing a decent desktop
IPC environment.

For an example that I'm familiar with, currently Glade has to
invoke DevHelp and detect DevHelp existence entirely through
the command line.

Ideally Glade, IMO should simply be activating the 'search' action
on the DevHelp entitiy.

>From my very limited understanding of GMenuModel, essentially this
is only a wrapper around GActions and action groups, implements a
hierarchy of actions and such with some probable merging/pathing
sugar apis, those actions will be accessible by other programs on
the Bus.

Some of those programs *might* happen to be a desktop environment
that wants to display menus from these hierarchical actions which
have been assigned a special token such as "I am the App menu", other
applications might very well not have anything to do with displaying
menus at all... perhaps a11y technologies could be transparently
integrated into a system that exports good introspection via the
GMenuModel, perhaps one could use GMenuModel to extend their 
application with a sister application which syncs the application 
state with some database or webserver interface... simply by
adding the extra program, starting it and giving it access to
the bus.

Point being that just because having a hierarchical structure of actions
exported on the bus might be useful for a desktop menuing system, does
not mean that it's not a useful concept when applied in different
ways... it might rather be called 'GActionModel' and then just by it's
name have much more relevance in libgio...

Just 2 extra cents...

Cheers,
   -Tristan


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Stefan Sauer]

On 12/12/2011 03:24 AM, Matthew Brush wrote:
> On 12/11/2011 12:14 PM, Stefan Sauer wrote:
>> 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?
>>
>
> I tried to ask this here a day or two ago but had problems, so I asked
> Ryan on IRC. The answer is that it's in GIO rather than GLib and there
> is precedence; GIcon for example.
>
> My (probably misguided) opinion is that if this type of stuff can't go
> into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome`
> library or something like this.  I have doubts how many apps linking
> to GIO without GTK+ are going to need such a model, either because
> they don't have a UI at all or are using some other toolkit which
> likely provides a mechanism of its own for this.

I think this is not so easy. Having a glib-app library sounds goo, but I
believe we don't want to have too many mini libraries. On the other hand
I wouldn't look for it in gio either.

Stefan

>
> Cheers,
> Matthew Brush - Just some guy
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Alexander Larsson]

On Fri, 2011-12-09 at 08:47 -0500, Ryan Lortie wrote:
> On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote:
> > Windows actually has an "application menu" thing. If you right-click on
> > the application on the panel you can get app-specific operations in the
> > menu. I'm not sure if the normal usecase for these match what the app
> > menu is typically used for though.
> 
> Is this the so-called jumplist?  It sounds more likely that we'd treat
> this as a 3rd type of menu -- since the shell, unity and mac os all have
> this same concept these days as well...

Yeah, this is one instance of the jumplist. The other one being on the
app icon in the start menu.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Matthew Brush]

On 12/11/2011 12:14 PM, Stefan Sauer wrote:

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?



I tried to ask this here a day or two ago but had problems, so I asked 
Ryan on IRC. The answer is that it's in GIO rather than GLib and there 
is precedence; GIcon for example.


My (probably misguided) opinion is that if this type of stuff can't go 
into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome` 
library or something like this.  I have doubts how many apps linking to 
GIO without GTK+ are going to need such a model, either because they 
don't have a UI at all or are using some other toolkit which likely 
provides a mechanism of its own for this.


Cheers,
Matthew Brush - Just some guy
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi Paul,

On Sun, 2011-12-11 at 16:33 -0500, Paul Tan wrote:
> It would be nice if the new menu system can still
> support dynamic (programmatic) adding and deleting
> submenu/menuitems, just like what we already have
> now in gtk2.  Examples are the "Favorite" menu in
> MS IE, and the "Bookmarks" in other browsers.

This is still supported.  Normally applications will create the bulk of
their menus using XML, but it's possible to name a particular menu (or
section of a menu) and acquire this object by name.  You can then
dynamically add items.

> If possible, would you consider bringing back the
> "tearoff menu" feature, which, according to a gtk
> developer, will be removed in gtk4.

I think this issue is orthogonal to GMenuModel, and it's one that I
don't have a strong opinion on.  Sorry.


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Paul Tan]

Hi,
It would be nice if the new menu system can still
support dynamic (programmatic) adding and deleting
submenu/menuitems, just like what we already have
now in gtk2.  Examples are the "Favorite" menu in
MS IE, and the "Bookmarks" in other browsers.
If possible, would you consider bringing back the
"tearoff menu" feature, which, according to a gtk
developer, will be removed in gtk4.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Stefan Sauer]

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:
>
>   
>
> 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

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Fri, 2011-12-09 at 16:07 +0100, Steve Frécinaux wrote:
> Do you plan on/Would the current Gmenu infrastructure allow something 
> like the mockups in [1] ? Especially, menus like the Mega-menu mockup 
> for EoG adding a dropdown menu in the title bar [2] would seem to be 
> feasible server-site, but what about the rest ?

We had a plan to introduce a GtkApplicationMenuButton as an alternative
to the gnome-shell application menu in order to display that menu.

The way GMenu is constructed is rather extremely generic: each item is
just a list of attributes plus (optionally) links to other GMenus.  You
can imagine quite a lot of ways that this could be used to construct
menus like those in the mockups.

I expect that the sort of things we see in the mega-menu examples are
things that might actually be appropriate for inclusion in the shell
application menu as well.  Unlike the menubars, I do expect that some
'more interesting' things will eventually want to go on there.

I think what needs to happen before we commit to anything is that we
have firm design mockups.  At that point, we can ask ourselves "okay.
what do we need to do to support this?"

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Fri, 2011-12-09 at 11:12 -0500, Morten Welinder wrote:
> Will the new api allow one to write a gui that looks and feels
> like it was made with the old api?

Yes.

Simply provide a menubar and no application menu and use
GtkApplicationWindow.  You will get the menubar added for you
automatically with the additional benefit that it works properly on the
mac and unity (without the current menubar-stealing/hiding hacks).

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Matthias Clasen]

On Fri, Dec 9, 2011 at 9:34 AM, Jannis Pohlmann  wrote:

>
> I guess this is unrelated but I have a question regarding extensions as
> well. Will there be functionality similar to GtkUIManager-based merging
> with placeholders in the GTK part of GMenu?
>
> We use this heavily in Thunar to allow plugins to specify items for
> file/folder context menus (and also for the window's "File" menu).

I've pushed an example to the branch that shows how plugins can extend
the menus.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Owen Taylor]

On Fri, 2011-12-09 at 00:25 -0500, Ryan Lortie wrote:
> hi,
> 
> On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote:
> > I think that you misunderstand how mac os works. 
> > 
> > Yes, a single menu bar is displayed at the top of the screen. This is
> > correct behavior according to Fit's Law, because you can bang the
> > pointer to the top of the screen and it can't overshoot.
> > 
> > No, applications are not limited to having a single menu bar. It's a
> > one-liner to switch menubars when different window (or notebook tab,
> > for that matter) gets focus.
> 
> This is obviously true from the fact that an application can detect
> which window has focus and the fact that the items in a menu can be
> changed, but it has to be done manually and is exceedingly uncommon in
> native mac os applications.

When designing for the Mac (or for a different global-menu-bar interface
like Unity), you probably don't want to make the set of menu options
bounce around depending on what window is selected.

But the jump from there to the idea that when you *do* have a per-window
menu, it should be the same for every application window seems
unwarranted.

Let's not fall into the fallacy that you can write one piece of code
without any conditionalization and have it be a well-designed UI for:

 Mac
 Windows
 GNOME
 Unity
 KDE

That's not possible, and we should concentrate on letting app developers
create applications that are competitive with native applications, even
if that means doing different things on different environments.

- Owen


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Morten Welinder]

Will the new api allow one to write a gui that looks and feels
like it was made with the old api?

Thanks,

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Steve Frécinaux]

On 12/09/2011 01:00 AM, Ryan Lortie wrote:
> We may add other types of menus in the future.  A jumplist/dock menu
> comes to mind.

Do you plan on/Would the current Gmenu infrastructure allow something 
like the mockups in [1] ? Especially, menus like the Mega-menu mockup 
for EoG adding a dropdown menu in the title bar [2] would seem to be 
feasible server-site, but what about the rest ?



[1] https://live.gnome.org/Design/Whiteboards/Menus
[2] https://live.gnome.org/Design/Whiteboards/Menus#Mega_Menus
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Fri, 2011-12-09 at 09:58 -0500, Shaun McCance wrote:
> I find it extremely unfortunate that GTK+ will be restricted to using
> the least common denominator. That's the kind of thing you get from
> wrapper libraries like wxWidgets.
> 
> In particular, from what I can tell, it means the searchable help menu
> work I did will be entirely impossible to rebase on this. Although do
> note that Mac OS has had that exact functionality for years.

On Fri, 2011-12-09 at 09:14 -0500, Ryan Lortie wrote:
> 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. 

I encourage you to investigate how it is possible to do this in a way
that will work for everyone and request changes/improvements to GMenu.
As far as I'm concerned, nothing is written in stone yet.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

On Fri, 2011-12-09 at 09:56 -0500, Ryan Lortie wrote:
> The way this works is with questions.

Uhm.  *sections.

Don't write email while trying to have a conversation at the same time,
kids :)


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Shaun McCance]

On Fri, 2011-12-09 at 09:14 -0500, Ryan Lortie wrote:
> 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.

I find it extremely unfortunate that GTK+ will be restricted to using
the least common denominator. That's the kind of thing you get from
wrapper libraries like wxWidgets.

In particular, from what I can tell, it means the searchable help menu
work I did will be entirely impossible to rebase on this. Although do
note that Mac OS has had that exact functionality for years.

--
Shaun


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi Jannis,

On Fri, 2011-12-09 at 15:34 +0100, Jannis Pohlmann wrote:
> I guess this is unrelated but I have a question regarding extensions as
> well. Will there be functionality similar to GtkUIManager-based merging
> with placeholders in the GTK part of GMenu? 
> 
> We use this heavily in Thunar to allow plugins to specify items for
> file/folder context menus (and also for the window's "File" menu).

The way this works is with questions.

Take this as an example that I've tossed around a lot:


  

  
  
  
  



  
  

  

  ...


Then you can feed that XML into a GtkBuilder.

Later, you can do this:

GMenu *menu = G_MENU (gtk_builder_get_object (builder, "recent-documents"));

and begin appending items to that menu.

Note that Gtk automatically introduces separators between the sections
at the toplevel (but not sections nested within sections).

In a similar form, you could introduce empty 'plugin area' sections into
your menus (or even the menubar -- but no separators there, of course)
that the plugins could insert their items into, in section form.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Jannis Pohlmann]

On Fri, 09 Dec 2011 09:14:31 -0500
Ryan Lortie  wrote:

> 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).

I guess this is unrelated but I have a question regarding extensions as
well. Will there be functionality similar to GtkUIManager-based merging
with placeholders in the GTK part of GMenu? 

We use this heavily in Thunar to allow plugins to specify items for
file/folder context menus (and also for the window's "File" menu).

  - Jannis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

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.

Cheer

Re: GMenuModel has landed

[Ryan Lortie]

On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote:
> Windows actually has an "application menu" thing. If you right-click on
> the application on the panel you can get app-specific operations in the
> menu. I'm not sure if the normal usecase for these match what the app
> menu is typically used for though.

Is this the so-called jumplist?  It sounds more likely that we'd treat
this as a 3rd type of menu -- since the shell, unity and mac os all have
this same concept these days as well...

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Fri, 2011-12-09 at 14:39 +0100, Nacho wrote:
> just one thing that I don't have quite clear...
> how will the extensibility be managed for the menus?
> i.e adding a new menuitem from a plugin.

If the plugin can gain access to the GMenu then it can modify it
(adding/removing items, etc).

In some ways this could be easier because of how 'sections' work in
GMenu -- any menu (including the menubar) can be composed of multiple
sections that are merged together.

If the plugin can gain access to the GApplication and/or
GtkApplicationWindows then it can add its actions there, as well.

No word on namespacing of actions or easy ability to remove all
menuitems/actions that were added by a particular plugin, though.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Nacho]

Hey guys,

just one thing that I don't have quite clear...
how will the extensibility be managed for the menus?
i.e adding a new menuitem from a plugin.

Regards.

On Fri, Dec 9, 2011 at 11:40 AM, Xavier Claessens  wrote:
> Le jeudi 08 décembre 2011 à 19:00 -0500, Ryan Lortie a écrit :
>>   1) every app already has the same menubar (content) in each window
>
> You obviously didn't write that email using evolution...
>
> Regards,
> Xavier Claessens.
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list



-- 
Ignacio Casal Quinteiro
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Fri, 2011-12-09 at 09:18 +, jcup...@gmail.com wrote:
> I suppose I could have a single menu tree with everything from every
> window type rolled together, but then I'd need a way to grey out
> irrelevant items per-window, which is almost the same thing as
> multiple menus. And I'd think it would be frustrating for the user to
> have to work with a menu system where 2/3rd of the visible items are
> noise.

If you target your menu items to 'win.x' actions and action 'x' doesn't
exist on a particular window then, indeed, it will be greyed out.

This makes sense for global menubar type situations, but I agree that
seeing a menu full of greyed items within a window is a bit less
optimal.  Perhaps we could hide the items in this case, instead of
greying them...

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Xavier Claessens]

Le jeudi 08 décembre 2011 à 19:00 -0500, Ryan Lortie a écrit :
>   1) every app already has the same menubar (content) in each window

You obviously didn't write that email using evolution...

Regards,
Xavier Claessens.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Tristan Van Berkom]

On Fri, Dec 9, 2011 at 6:11 PM, Petr Tomasek  wrote:
> On Thu, Dec 08, 2011 at 07:58:50PM -0500, Ryan Lortie wrote:
>> hi,
>>
>> On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
>> > Does this mean different windows belonging to the same application will
>> > not be able to have different per–window menubars? I’m thinking about
>> > Empathy here, with its Buddy List and Conversation windows having
>> > different menubars, but it’s not an uncommon scenario.
>>
>> I guess a reasonable question to ask here is what empathy would look
>> like if it were an application designed for mac os.
>
> Who cares about some stupid mac os?
> I'm sick of people trying to criple gnome to look like mac os :-(

Just as many of us are very sick of crippling GTK+ just to conform
to the GNOME desktop.

In this way it's a two-way street and we need to walk a thin line
and make sure that features like this can stand-alone without
GNOME or OSX or whatever system people want to build software
for.

Cheers,
 -Tristan

>
> --
> Petr Tomasek 
> Jabber: but...@jabbim.cz
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Emmanuele Bassi]

hi;

On 9 December 2011 09:11, Petr Tomasek  wrote:
> On Thu, Dec 08, 2011 at 07:58:50PM -0500, Ryan Lortie wrote:
>> hi,
>>
>> On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
>> > Does this mean different windows belonging to the same application will
>> > not be able to have different per–window menubars? I’m thinking about
>> > Empathy here, with its Buddy List and Conversation windows having
>> > different menubars, but it’s not an uncommon scenario.
>>
>> I guess a reasonable question to ask here is what empathy would look
>> like if it were an application designed for mac os.
>
> Who cares about some stupid mac os?
> I'm sick of people trying to criple gnome to look like mac os :-(

a) this has nothing to do with Gnome; GTK works on OSX, and this
change has been introduced also to help making GTK application behave
correctly out of the box there.
b) can you take your personal validation problems elsewhere? thanks.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Petr Tomasek]

On Thu, Dec 08, 2011 at 07:58:50PM -0500, Ryan Lortie wrote:
> hi,
> 
> On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
> > Does this mean different windows belonging to the same application will
> > not be able to have different per–window menubars? I’m thinking about
> > Empathy here, with its Buddy List and Conversation windows having
> > different menubars, but it’s not an uncommon scenario.
> 
> I guess a reasonable question to ask here is what empathy would look
> like if it were an application designed for mac os.

Who cares about some stupid mac os?
I'm sick of people trying to criple gnome to look like mac os :-(

-- 
Petr Tomasek 
Jabber: but...@jabbim.cz


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[jcupitt]

On 9 December 2011 04:34, Allin Cottrell  wrote:
> On Thu, 8 Dec 2011, Ryan Lortie wrote:
>> Today I landed the GMenuModel work on glib master [...]
>> 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
>
> Whoa! Where is that notion coming from? Some empirical input seems to be
> called for. It may not be the most typical situation, but a fair number of
> GTK apps put up different-looking windows, with substantially different menu

I like the sound of this change generally, but I think I need
per-window menus in my program too.

I have windows which display images, windows which display matrices,
windows which display program code, windows which display large
interactive graphs ... and so on. These different data types need
different operations available. I have to be able to add and remove
menus depending on the window type.

I suppose I could have a single menu tree with everything from every
window type rolled together, but then I'd need a way to grey out
irrelevant items per-window, which is almost the same thing as
multiple menus. And I'd think it would be frustrating for the user to
have to work with a menu system where 2/3rd of the visible items are
noise.

John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Alexander Larsson]

On Thu, 2011-12-08 at 19:58 -0500, Ryan Lortie wrote:

> 
> > I assume Windows will behave like GNOME 2 here. In the GNOME 2 case, is
> > the app menu collapsed with the menubar somehow?
> 
> Correct assumption.

Windows actually has an "application menu" thing. If you right-click on
the application on the panel you can get app-specific operations in the
menu. I'm not sure if the normal usecase for these match what the app
menu is typically used for though.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Tristan Van Berkom]

On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote:
> On Dec 8, 2011, at 4:58 PM, Ryan Lortie wrote:
> 
> > hi,
> > 
> > On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
> >> Does this mean different windows belonging to the same application will
> >> not be able to have different per–window menubars? I’m thinking about
> >> Empathy here, with its Buddy List and Conversation windows having
> >> different menubars, but it’s not an uncommon scenario.
> > 
> > I guess a reasonable question to ask here is what empathy would look
> > like if it were an application designed for mac os.
> 
> I think that you misunderstand how mac os works. 
> 
> Yes, a single menu bar is displayed at the top of the screen. This is correct 
> behavior according to Fit's Law, because you can bang the pointer to the top 
> of the screen and it can't overshoot.
> 
> No, applications are not limited to having a single menu bar. It's a 
> one-liner to switch menubars when different window (or notebook tab, for that 
> matter) gets focus.


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.

Can someone dish out an example (hopefully less than 10 lines of code)
that shows us how to make our applications become 
'multiple applications' ?

Of course, the prerequisites are:
  - All applications that my application creates should run in the
same process.
  - If D-Bus is present on the system, the application set should
still be one, single instance process.
  - There should only be one interface for loading files/uris,
not one interface 'per application' which my application 'is'.

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 ?

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 ?

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


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

Thanks,
  -Tristan


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote:
> I think that you misunderstand how mac os works. 
> 
> Yes, a single menu bar is displayed at the top of the screen. This is
> correct behavior according to Fit's Law, because you can bang the
> pointer to the top of the screen and it can't overshoot.
> 
> No, applications are not limited to having a single menu bar. It's a
> one-liner to switch menubars when different window (or notebook tab,
> for that matter) gets focus.

This is obviously true from the fact that an application can detect
which window has focus and the fact that the items in a menu can be
changed, but it has to be done manually and is exceedingly uncommon in
native mac os applications.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Allin Cottrell]

On Thu, 8 Dec 2011, Ryan Lortie wrote:


Today I landed the GMenuModel work on glib master [...]

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


Whoa! Where is that notion coming from? Some empirical input seems 
to be called for. It may not be the most typical situation, but a 
fair number of GTK apps put up different-looking windows, with 
substantially different menu bars, depending on what the user has 
chosen to do. Some (many?) apps are not one-trick ponies.


Allin Cottrell
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[John Ralls]

On Dec 8, 2011, at 4:58 PM, Ryan Lortie wrote:

> hi,
> 
> On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
>> Does this mean different windows belonging to the same application will
>> not be able to have different per–window menubars? I’m thinking about
>> Empathy here, with its Buddy List and Conversation windows having
>> different menubars, but it’s not an uncommon scenario.
> 
> I guess a reasonable question to ask here is what empathy would look
> like if it were an application designed for mac os.

I think that you misunderstand how mac os works. 

Yes, a single menu bar is displayed at the top of the screen. This is correct 
behavior according to Fit's Law, because you can bang the pointer to the top of 
the screen and it can't overshoot.

No, applications are not limited to having a single menu bar. It's a one-liner 
to switch menubars when different window (or notebook tab, for that matter) 
gets focus.

Regards,
John Ralls

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Jannis Pohlmann]

On Thu, 08 Dec 2011 19:00:01 -0500
Ryan Lortie  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 GModel 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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Danielle Madeley]

On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
> I haven’t looked at the code yet, but a couple questions came to mind
> while reading your summary. Hope you don’t mind if I ask them.
> 
> > 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
> 
> Does this mean different windows belonging to the same application will
> not be able to have different per–window menubars? I’m thinking about
> Empathy here, with its Buddy List and Conversation windows having
> different menubars, but it’s not an uncommon scenario.

While a valid question, for your example: Empathy is actually comprised
of several different applications. The roster app, the chat app and the
voip app are all separate.

-- 
Danielle Madeley
Software Developer, Collabora Ltd.  Melbourne, Australia

www.collabora.co.uk

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
> Does this mean different windows belonging to the same application will
> not be able to have different per–window menubars? I’m thinking about
> Empathy here, with its Buddy List and Conversation windows having
> different menubars, but it’s not an uncommon scenario.

I guess a reasonable question to ask here is what empathy would look
like if it were an application designed for mac os.

If people ask for it, I'm open to adding the ability to override menus
on a per-window basis, but it will be strongly recommended against.

I think a possible way of dealing with this would be to treat the
contact list and the chat windows as two separate applications -- it
almost seems that way these days anyway, with the messaging integrated
into the shell.

> I assume Windows will behave like GNOME 2 here. In the GNOME 2 case, is
> the app menu collapsed with the menubar somehow?

Correct assumption.

In the case that nobody is showing the application menu, an
"Application" item is added to the left of whatever would have otherwise
been the first item in the menubar.  If there is no menubar, then you
end up with a menubar with an "Application" menu and nothing else.

We're trying to decide what the best name for this menu should be.
Possibly it should be the same as the name of the application.


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Andrea Bolognani]

I haven’t looked at the code yet, but a couple questions came to mind
while reading your summary. Hope you don’t mind if I ask them.

> 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

Does this mean different windows belonging to the same application will
not be able to have different per–window menubars? I’m thinking about
Empathy here, with its Buddy List and Conversation windows having
different menubars, but it’s not an uncommon scenario.

> 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

I assume Windows will behave like GNOME 2 here. In the GNOME 2 case, is
the app menu collapsed with the menubar somehow?

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: Digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GMenuModel has landed

[Ryan Lortie]

hi,

Today I landed the GMenuModel work on glib master.  A release will be
following shortly.

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:

  

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