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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list