Follow-up Comment #4, bug #21751 (project mypaint):
I wish there was, but GTK has always been fairly minimal in that regards.
All is not lost, however. There's a very toylike implementation in the
bloatpad.c example, and I'm investigating how to make it all play nice with
GtkApplication and GtkApplicationWindow concepts, which are not so far from
MyPaint's concepts of Appplication and DrawWindow, after all.
Little observations:
* Builder XML can define accelerators in GMenuModels, but if you do that then
you can't change them later (or at least, the label doesn't update; go
figure). The thing to do is to define the menu structure without accels in the
XML, and then override the accels from the app's config.
* We'll get nicer startup and shutdown hooks, at least.
* We'll probably be forced to drop the Recent Files submenu, and have to redo
the mode stuff in a dumber way too. Main menus can no longer have new items
added to them dynamically after being created under the new model.
* The cleanest cross-desktop approach seems to be let the app show both the
AppMenu (that thing that GNOME has that nobody else uses) and a regular
menubar. We could use a GtkMenuButton on "each" main-window as a
Chrome/Firefox-like "cog" button, but that may require lots of redesign.
Sensible :) desktops like Xfce will still render a menu bar consisting of
"<app-menu> <menu-bar-items>".
* Other apps should in theory be able to invoke MyPaint's GActions over DBus,
which is pretty cool. ISTR EasyStroke thinking about this for gestural stuff
(but I may be wrong). Whatever, exposing it to the desktop like this gets you
a model closer to KDE's.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?21751>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Mypaint-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/mypaint-bugs
