On Thu, Oct 2, 2008 at 3:58 PM, Emanuel Rumpf <[EMAIL PROTECTED]> wrote:
> - Use something that could at the end serve as a standard method for
> all actions in rosegarden.
> - I partly like the idea of an external file for the actions, since
> source might look cleaner.
Well, we seem to have a consensus that reducing the amount of crap in
the source code and moving it out to more readily editable files may
be a worthwhile goal.
One problem I have with the way things are going at the moment is that
it looks like it will at least double the amount of cruddy boilerplate
C++ that goes into setting up actions in the view classes, and I
really would like to avoid that.
Here's one suggestion. We reduce each of the "static" action
constructors (not necessarily the ones that are created on the fly
like the note radio buttons, but at least the basic menu functions) to
a one-liner that creates an action, assigns it an action name, and
connects it to a slot:
connect(newAction("filter_selection"), SIGNAL(triggered()), this,
SLOT(slotFilterSelection()));
where newAction is a function in the base class, or another class,
that just does something like
QAction *
EditViewBase::newAction(QString name) const
{
// note -- action must be child of edit view (for later lookup)
QAction *a = new QAction(this);
a->setObjectName(name);
return a;
}
Meanwhile, we create an external file in XML or another format, that
describes the menu and toolbar layouts and action properties,
including for each action:
* the label
* the icon name, if it differs from the action name
* the shortcut (as text, e.g. "Ctrl+L" -- Qt is perfectly happy to
accept this sort of text as argument to setShortcut)
* the radio group for this action, if there is one
* whether it is toggleable (presumably also need different
signal/slot connection for this)
* state tags in which it is available
We also promise to make everything in this file translatable -- but we
don't need to worry about that at the outset, so long as we know it
will be possible (which it will).
XML or something else? Advantages of XML: (1) we already have the
basic structure for the file; (2) Qt contains an XML parser. I'm not
very fond of it to edit either, but we shouldn't have to edit it too
often.
And finally, we have a class, somewhat simpler than the whole KXMLGUI
caboodle, that reads the XML file (or whatever it is), creates the
menus and toolbars (given a main window to query the menu bar and tool
bar on), and populates the actions setting their appropriate
properties. Invoking this would basically replace the call to
KXMLGUIClient::createGUI in the existing view constructors. I can
write this class.
We would also need to replace existing calls to
KXMLGUIClient::stateChanged() with calls to a method on this class
setting or resetting a suitable state tag, but that should be
straightforward enough.
This won't work for all actions, but it will tidy up many of the
static ones, and produce a neater result than our old system.
One other advantage is that it is somewhat parallelisable -- by
reducing the amount of code in the view classes, we get them to
compile (and be identifiably correct) more easily; producing and
refining the XML or whatever file can be done in parallel with this;
and writing the class that reads this file and sets up the actions can
be done in parallel with both, provided the basic structure is
understood. And if the XML file is incomplete or incorrect, or the
code that loads it is wrong, it doesn't prevent the main bulk of the
code from building and we can always complete or fix it afterwards.
Objections?
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
