Dear Chris,
I just now, after all this time got to looking into Developer B stuff. I reread the dev-list and the wiki.
Emanuel wrote some time ago concerning adding shortcut information to the .rc files:
> > ...accepted by QKeySequence, e.g. "Ctrl+L".
> >
>
> Shouldn't this be: "Qt::CTRL + Qt::Key_L" ?
the wiki still shows:
> If the action has a shortcut, add a shortcut=“text” attribute where text > is a shortcut description using the syntax accepted by QKeySequence, e.g. > “Ctrl+L”
Which is correct? I'm imagining the Emanuel has it correct.
I will keep studying all of this a bit today, before diving head first tomorrow.
Thank you for any input.
Sincerely,
Julie S.
--- On Fri, 10/3/08, Emanuel Rumpf <xbran23@...> wrote:
> From: Emanuel Rumpf <xbran23@...>
> Subject: Re: [Rosegarden-devel] actions: here's the plan
> To: Rosegarden-devel@...
> Date: Friday, October 3, 2008, 6:29 PM
> 2008/10/3 Chris Cannam <cannam@...>:
> >
> > Where we used to call KStandardAction functions to
> create the standard
> > e.g. file menu actions, we will need new actions
> created explicitly
> >
>
> Done already. But in conventional Qt4 style.
> The objectName is missing there.
>
>
>
> > (see the psName field of each structure definition).
> >
> That's is the 3. parameter : "file_open" in
> { Open, KStdAccel::Open,
> "file_open",
> I18N_NOOP("&Open..."), 0,
> "fileopen" }
>
>
> >
> > Finally, calls to stateChanged("state_name",
> KXMLGUIClient::StateReverse)
> > please change to
> leaveActionState("state_name");
> >
> > and calls to
> > stateChanged("state_name",
> KXMLGUIClient::StateNoReverse) please
> > change to enterActionState("state_name").
> >
>
> NOTE: also remove the #include kxmlgui... from the head of
> the file then.
>
>
> >
> > Developer B: GUI definition files.
> >
> >
> > <Action name="open_in_event_list"
> text="Open in &Event List
> > Editor" icon="eventlist"/>
> >
> > ...maybe....add a shortcut="text"
> > ...checkable (toggleable), add
> checkable="true"
> >
> > ...accepted by QKeySequence, e.g. "Ctrl+L".
> >
>
> Shouldn't this be: "Qt::CTRL + Qt::Key_L" ?
>
>
>
> > ...radio-group: add a group="group_name"
> > something that you can make up that is vaguely
> relevant to the group
> >
> In the files I edited, the previous GroupNames have been
> preserved.
> In most cases I also defined ActionGroups and added the
> actions to those.
> These could also be removed then,
> as well as the icon definitions and IconLoader - right ?
>
>
> >
> > Some actions appear in the menus but not in the .rc
> files. Many of
> > these will be KDE standard actions (File|Open etc).
> These need to be
> > added to the .rc files in the proper places using the
> action names,
> > labels, and icon names found here:
> >
>
> I converted KStandart actions to QActions already.
> You know that it was a standard action, because:
>
> 1. it has a name listed in the kde standard actions header
> 2. it has no object name applied
> 3. the action group is likely none
>
> Example of a converted action that was a KStandard:
>
> QAction* qa_close = new QAction(i18n("&Close
> File"), this );
> connect( qa_close, SIGNAL(toggled()), this,
> SLOT(slotFileClose()) ); ;
> //qa_close->setCheckable( true ); //
> qa_close->setAutoRepeat( false ); //
> //qa_close->setObjectName("");
> //qa_close->setActionGroup( 0 ); // QActionGroup*
>
> -------------------------------------------------------------------------
> This would become :
> connect( newAction( "file_close" ),
> SIGNAL(toggled()), this,
> SLOT(slotFileClose()) );
>
>
>
> >
> > Developer C: Action loading code.
> >
> > Implement the newAction and stateChanged functions for
> use by Developer A.
> >
> > Implement a new createGUI function that loads the XML
> and sets up the
> > actions into menus and so on appropriately.
> >
> >
> > So those are the roles.
> >
>
>
> > Emanuel, I would like to suggest that you be developer
> A, if that's OK with you.
> >
> Hm. Not so much.
> Anyone else volunteering ?
> I already worked through all this, and don't want to
> edit the things again.
> I would prefere to fix the remaining 1000 errors.
> I'm going to use the new style for the actions from now
> on.
> (and write only the single connect statement mentioned on
> top)
>
> Also despite of code cleanup, I see no real necessity to
> change those
> action already defined. I wrote them in a way, that most
> would work
> with simple additions like adding an objectName.
> But I see, with the new style newAction() function,
> they might interfere or not work at all (?)
>
> There are some hundred actions and transforming them is
> a lot of work. That's why I would prefere a system,
> that
> worked with the old defines too.
>
> This is step-by-step versus all-embracing cleanup.
> An overall cleanup is nice sure, but
> I imagine that once the gui is showing up,
> a lot more-necessary tasks will pop-up.
>
> Anyway. The plan is good.
> I'm happy with an overall cleanup too.
>
>
> > Julie, if you have the time and you don't mind,
> would you be developer B?
> >
> > And I am assuming I will be developer C unless anyone
> objects.
> >
> ok.
>
>
>
> Question:
> Why do we keep the connect statement at all ?
>
> Maybe I'm wrong, but I imagine the connection:
> connect( newAction( "file_close" ),
> SIGNAL(toggled()), this,
> SLOT(slotFileClose()) );
>
> could be defined in the xml file too: ( and set-up by the
> parsing script )
>
>
>
>
> All in all, I agree with the plan.
> It will make the code cleaner, more adjustable.
>
> Thanks for the proposal.
> Emanuel
>
> -------------------------------------------------------------------------
> 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
> Rosegarden-devel@... - use the link below
> to unsubscribe
> https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
|
