On Thu, Oct 2, 2008 at 10:59 AM, Chris Cannam
<[EMAIL PROTECTED]> wrote:
> 1. Retain the KDE mechanisms. [...]
> 2. Hard-code everything [...]
> 3. Replace the KDE mechanisms with a pure Qt4 mechanism in which
> everything was defined in some sort of rc file
To give an idea of how these might differ, let's consider one action,
which I will arbitrarily pick to be "Filter Selection" in the notation
view.
In the old KDE3 app, we set this up with:
new KAction(i18n("&Filter Selection"), "filter", Key_F + CTRL, this,
SLOT(slotFilterSelection()), actionCollection(),
"filter_selection");
in the code (note that this is simplified by using a stock KDE icon,
called "filter"). Then there are three lines in the XML -- one to add
it to the Edit menu, one to add it to the Tools toolbar, and one to
declare that it should be available when the have_selection state is
active. All three of these lines are the same, they just say
<Action name="filter_selection"/>
and differ only in context. The work of adding it to menus and
toolbars appropriately is done in the single createGUI call that
appears somewhere in the view constructor.
Presumably, with option 1 this would remain much the same.
Nonetheless I'm reluctant to support option 1, because of the mongrel
nature of the resulting code.
With option 2, hard-coding everything, we would need something like
this to create the action:
QIcon icon = IconLoader().load("filter");
QAction *filter = new QAction(icon, i18n("&Filter Selection"), this);
filter->setObjectName("filter_selection");
filter->setShortcut("Ctrl+F");
connect(filter, SIGNAL(triggered()), this, SLOT(slotFilterSelection()));
(of course, the first four lines could be collapsed into a single call
to an addAction method in the base class, with object name, label,
icon name and shortcut arguments.)
Then we would have to add it to a menu:
editMenu->addAction(filter);
presuming that editMenu was set appropriately, and also add it to a toolbar:
toolsToolbar->addAction(filter);
presuming that toolsToolbar was set appropriately. A subtlety here is
that we couldn't necessarily do both of these at the point of
construction, as the order of items in the menus and toolbars may
differ (in principle -- that might not be a good thing in itself
obviously).
We would also need to manage menu state, which may be done through
entering/leaving state signals -- with the method I use in SV (which
has hard-coded menu structure, although it's much simpler than
Rosegarden) this would involve a line like:
connect(this, SIGNAL(stateHaveSelection(bool)), filter,
SLOT(setEnabled(bool)));
This is all therefore more code, though not impossibly more. The only
part that would be completely new would be the code to handle menu
state. There would of course be no XML rc file in this model.
Option 3 would give us something like this in the code:
QAction *filter = new QAction;
filter->setObjectName("filter_selection");
connect(filter, SIGNAL(triggered()), this, SLOT(slotFilterSelection()));
and maybe something like this in the XML at the point where the action
was inserted into a menu:
<Action name="filter_selection" icon="filter" text="&Filter
Selection" shortcut="Ctrl+F"/>
And then, of course, we would need to provide code to read the XML,
build up the menu and toolbar structure, and apply these properties.
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
