Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Using Actions in CB: a discussion
mandrav:
EDIT: this was splitted from the original topic, labeled "Code::Blocks Menus and Shortcuts revamping"[/url].
These last couple of days, I 've been coding an initial implementation of an ActionsManager. I will now describe where I 'm at and listen to comments.
------------------
We have Actions. They can be constructed in one of two ways:
--- Code: ---Action(int id, const Shortcut& shortcut);
// or
Action(const wxString& script, const Shortcut& shortcut);
--- End code ---
All constructor arguments have default values, except the script one.
This means that we can have two types of actions:
[*] Code actions. These are implemented as wx events, hence the required ID, so ActionsManager can call the correct event handler using the action's ID.
[*] Script actions. When launched, these actions load and run a script file.
[/list]
The application can add Actions to ActionsManager in two ways:
[*] One at a time:
--- Code: ---Action action(idActionFileOpen);
action.description = _("Opens a file");
action.shortcut = Shortcut(AK_O, false, true, false); // args are: key, alt, ctrl, shift
ActionsManager::Get()->Add(_T("File.Open"), action); // add the action named as "File.Open"
// etc
--- End code ---
[*] Many actions at once. For this, a special struct is provided:
--- Code: ---ActionRegistrar actions[] =
{
{ _T("File.Open"), Action(idActionOpen, Shortcut(AK_O, false, true, false)) },
{ _T("App.Quit"), Action(idActionQuit, Shortcut(AK_Q, false, true, false)) },
{ _T("App.About"), Action(idActionAbout, Shortcut(AK_F1, false, false, false)) },
{ _T("App.Test"), Action(idActionTest) },
{ _T("App.Test2"), Action(idActionTest2) },
EndOfActionRegistrar // this just helps ActionsManager to see the end of this array
};
// register all actions at once
ActionsManager::Get()->Add(&actions[0]);
--- End code ---
[/list]
Now that actions are registered, you can "launch" an action at any time using ActionsManager::Get()->Launch(action_name).
Actions can be enabled/disabled using ActionsManager::Get()->Enable(action_name, true|false). Automatically, all menu entries or toolbars bound to the specified action become enabled/disabled accordingly.
ActionsManager will offer all that is needed to create menubars, popup menus and toolbars. Only toolbars are not implemented yet.
--- Code: --- ActionsManager* am = ActionsManager::Get();
// create main menubar layout
// add a "File" menu in "MainMenu"
int id = am->AddMenu(_T("MainMenu"), _("&File"));
// add "Open" entry (under "File") and bind to action "File.Open"
am->AddMenuEntry(id, _("&Open"), _T("File.Open"));
// just add a separator
am->AddMenuSeparator(id);
// add "Quit" entry and bind to action "App.Quit"
am->AddMenuEntry(id, _("&Quit"), _T("App.Quit"));
// ask ActionsManager for the "MainMenu" menubar
// it will be created on-the-fly
SetMenuBar(am->GetMenuBar(_T("MainMenu"));
// create a menu for the editor popup "EditorCtxMenu"
id = am->AddMenu(_T("EditorCtxMenu"), _("Editor menu"));
am->AddMenuEntry(id, _("&Enable quit"), _T("App.Test2"));
// when you want to launch the editor popup menu, use:
// wxMenu* menu = new wxMenu;
// ActionsManager::Get()->CreateContextMenu(&menu, _T("EditorCtxMenu"));
// PopupMenu(menu);
// delete menu;
--- End code ---
Here's the current to-do:
--- Code: ---// TODO (mandrav#1#): Serialize actions
// TODO (mandrav#1#): Create toolbar(s) from actions
// TODO (mandrav#1#): Create UI to edit menus/toolbars
// TODO (mandrav#1#): Add support for check/radio actions
--- End code ---
Serialization should be trivial to do. The actions configuration file will be loaded after all modules have finished registering their actions and menu/toolbar layouts. This way, the actions configuration will override any in-program settings.
Actions not registered by the application will not be serialized. The exception to this are script-actions. The user will be able to add script actions freely.
So, comments?
Pecan:
Bump. I think this is important. And it took me
10 minutes to find the thead again.
Not ignoring this, just trying to get my
head around it.
pecan
MortenMacFly:
--- Quote from: mandrav on December 17, 2005, 08:44:47 pm ---So, comments?
--- End quote ---
Sounds nice to me, hence I have a question to clarify: Are the action declarations itself "hard-coded" or will they be loaded via a configuration file and then implemented at run-time? I think of personalities and whether a new personality would allow me to switch the actions to be registered then.
Morten.
mandrav:
--- Quote from: MortenMacFly on December 18, 2005, 05:58:38 pm ---Sounds nice to me, hence I have a question to clarify: Are the action declarations itself "hard-coded" or will they be loaded via a configuration file and then implemented at run-time? I think of personalities and whether a new personality would allow me to switch the actions to be registered then.
--- End quote ---
As mentioned above:
--- Quote from: mandrav ---The actions configuration file will be loaded after all modules have finished registering their actions and menu/toolbar layouts. This way, the actions configuration will override any in-program settings.
Actions not registered by the application will not be serialized. The exception to this are script-actions. The user will be able to add script actions freely.
--- End quote ---
In other words, the user will be able to restructure all the menus (main menubar, context menus, etc) by adding/removing actions to them. The same goes for the toolbar.
Also, the user will be able to add actions that call user-defined scripts. That is, add functionality not known to C::B at compile-time.
MortenMacFly:
--- Quote from: mandrav on December 18, 2005, 07:05:02 pm ---As mentioned above:
--- End quote ---
Sorry, I've got that wording wrong, so I missed that part. :oops:
--- Quote from: mandrav on December 18, 2005, 07:05:02 pm ---In other words, [...]
--- End quote ---
...great! I couldn't think of anything that's missing. :P
Morten.
Navigation
[0] Message Index
[#] Next page
Go to full version