Re: GMenuModel has landed
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
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
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
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
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
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
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
On 9 December 2011 04:34, Allin Cottrell cottr...@wfu.edu 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
hi; On 9 December 2011 09:11, Petr Tomasek toma...@etf.cuni.cz 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
On Fri, Dec 9, 2011 at 6:11 PM, Petr Tomasek toma...@etf.cuni.cz 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 http://www.etf.cuni.cz/~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
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
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 xclae...@gmail.com 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
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
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
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
Re: GMenuModel has landed
On Fri, 09 Dec 2011 09:14:31 -0500 Ryan Lortie de...@desrt.ca 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
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: menu id='menubar' submenu label='_File' section item label='_New' action='app.new'/ item label='_Open' action='app.open'/ item label='_Save' action='win.save'/ item label='_Print' action='win.print'/ /section section id='recent-documents'/ section item label='_Close' action='win.close'/ item label='_Quit' action='app.quit'/ /section /submenu ... /menu 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
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
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
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
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
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
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
On Fri, Dec 9, 2011 at 9:34 AM, Jannis Pohlmann jan...@xfce.org 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
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
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
GMenuModel has landed
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: 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
Re: GMenuModel has landed
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 e...@kiyuko.org 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
Re: GMenuModel has landed
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
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
On Thu, 08 Dec 2011 19:00:01 -0500
Ryan Lortie de...@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 GSomethingModel 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
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
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
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
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
