What shall we do about KActions in the Qt4 port? In the old code, we have various ways of handling menu and toolbar actions, mostly using the KActionCollection and KXMLGui classes.
Broadly speaking, for each available action, a KAction is created and added to the current view's KActionCollection. That in itself is not enough to make the action appear anywhere. The view then uses the KXMLGui structure to read its .rc file, create a set of menus and toolbars based on the structure in that file, and add the actions to it in the named places. The same KXMLGui structure is used to handle activations when the "mode" changes (e.g. making editing functions available when a note is selected, etc). So, the old code has a mixture of hard-coded stuff, and stuff that can be fiddled with in the .rc file. Usually, the action names, labels, shortcuts and icons are hard coded -- although I think KDE will override the shortcuts in the action collection if the user has their own shortcut configuration. The menu names and labels, the ordering of actions on the menus, and the toolbar names, ordering and contents all come from the .rc file. (We do create a few menus explicitly, generally where the number of entries is dynamic in some way -- like the note and mark choosing menus. But mostly it's as described above.) This method is sort of OK, but it's not great. Having the menu layout in the .rc file is quite nice, because it makes it easy to experiment with and adjust (as we have done at great length in the past). But it still leaves a lot that is hard coded; it's always been a pain that you can't set the labels for actions in the .rc file, for example. (And it seems inconsistent that you can't do that, when you can set the labels for menus.) We basically have three choices for how to go on with this: 1. Retain the KDE mechanisms. We could do this either using the KDE4 libraries (most of the same classes are still there) or by pulling in the code to our own codebase. We could even pull in the KDE3 code and update it ourselves. So, we would continue to associate actions with an action collection container, and continue to use KXMLGui or something like it to create the menus and toolbars and handle activation. This may turn out to be easy, but it's not necessarily easy to predict -- there may be assumptions made in the KDE code about the use of other KDE classes. 2. Hard-code everything (menu layouts, toolbars, activations) using pure Qt4 mechanisms. This is not particularly hard to do, except that there is a huge amount of it. We would need to reproduce the exact layout carefully (currently the actions are created in a different order from the order in which they actually appear in the menus), would need to introduce explicit code to create toolbars, and would need quite a lot of new code to support activation and menu states. And we would lose the ability to change menu layouts without recompiling -- do we care? 3. Replace the KDE mechanisms with a pure Qt4 mechanism in which everything was defined in some sort of rc file, including the action labels and shortcuts and all the other stuff that was hard-coded previously, leaving only the action identifiers in the code. This would be attractively clean and would not have to be as complicated as KXMLGui (which I think is rather overengineered), but would obviously mean writing Real Code. Complicating matters, I see that Emanuel has gone some way on the road to option 2, hard-coding everything, by e.g. creating some menus explicitly and adding actions to them in the code. I don't think that this work is far enough advanced to make choosing 2 a no-brainer -- there would still be a great deal of work left to do -- but it may make it harder to track back and start on something else. Any opinions? Chris ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
