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 Select Expand


Action(int id, const Shortcut& shortcut);
// or
Action(const wxString& script, const Shortcut& shortcut);

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.
  

The application can add Actions to ActionsManager in two ways:

• One at a time:
  
  Code Select Expand
  
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

  
• Many actions at once. For this, a special struct is provided:
  
  Code Select Expand
  
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]);

  

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 Select Expand


    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;


Here's the current to-do:

Code Select Expand


// 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


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]

So, comments?

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]

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.

As mentioned above:

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.

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]

As mentioned above:

Sorry, I've got that wording wrong, so I missed that part. :oops:

In other words, [...]

...great! I couldn't think of anything that's missing.
Morten.

[Michael]

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.

Personally, I think that this is a very good idea. Actions would enable C::B to adpat itself to the different user's requirements and prefernces and therefore make its use easier and more pleasant.

Michael

[takeshimiya]

I guess you know my comment: This is really amazing!

I don't know how it'll handle the logic separation of the bindings (toolbars, menus, etc) from the actions (idActionOpen, etc).
So, itsn't missing a BindingsManager counterpart? Or the handling of bindings would be done in another way?

Because I'm thinking that the actions would be the same, but doing a pluggable architecture, the user can add another bindings (a mouse gesture, vim-like command, voice recognition, etc) through plugins.
That would be even more flexible and powerful.

But I must say I'm surprised, Yiannis you're so fast! I though this would made in 2.0 or so being optimistic, but I was wrong

[Pecan]

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.

Does this mean a user/plugin could record the scintilla macros
(using the macro recorder) and add/delete them as individual actions
at the users whim?

Does this mean a set of macros could be loaded from an external
source (eg, {Ctrl+Enter}={END+ENTER+TAB+TAB}) and register each as an action?

Edit:
Will there be plugin fights over menu/taskbar items? Is arbitration needed?
Nothin' like a good plugin fight!
thanks
pecan

[jmccay]

Just adding a reply to the feature request post to allow people to backtrack what's being discussed to get relavent information to form an informed opinion.

http://forums.next.codeblocks.org/index.php?topic=1377.0

jmccay

[mandrav]

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.

Does this mean a user/plugin could record the scintilla macros
(using the macro recorder) and add/delete them as individual actions
at the users whim?

Does this mean a set of macros could be loaded from an external
source (eg, {Ctrl+Enter}={END+ENTER+TAB+TAB}) and register each as an action?

Yes, plugins will be able to register/unregister actions. Actually it will be the only way to add menu/toolbar items.

Edit:
Will there be plugin fights over menu/taskbar items? Is arbitration needed?
Nothin' like a good plugin fight!

This is handled by the ActionsManager.

[takeshimiya]

If ActionsManager handles the add menu/toolbar items, how one could add another binding such as mouse gestures?
Will it be a way to add new bindings to actions provided by plugins?

[thomas]

Do you have code which recognizes mouse gestures?

[Urxae]

If ActionsManager handles the add menu/toolbar items, how one could add another binding such as mouse gestures?
Will it be a way to add new bindings to actions provided by plugins?

Well, given the availability of this:

Now that actions are registered, you can "launch" an action at any time using ActionsManager::Get()->Launch(action_name).

I'd say adding a mouse gestures plugin wouldn't be much harder than:

• Providing a config dialog to allow the user to bind gestures to actions. This assumes of course that plugins are able to obtain a list of the names of currently registered actions from the action manager. Mandrav's post didn't provide examples of this, but if he hasn't implemented it yet it should be fairly trivial to do so, I think
• Detecting when mouse gestures are performed (probably the hardest part).
• Launching the appropriate actions using the action manager, as in above quote.

[thomas]

That's why I asked... the rest is really trivial.

[Urxae]

That's why I asked... the rest is really trivial.

You posted while I was still composing my post, but I didn't want to throw away the entire post just because you beat me .