Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Code::Blocks Menus and Shortcuts Revamping thread
takeshimiya:
Hi! I was thinking about how to improve the current menu handling, keybinding handling, toolbar handling, ... because now nothing of that is user-configurable.
So let's start the discussion of how to improve all of that (probably for Code::Blocks post-1.0):
All menus, toolbars and tools would need to be user configurable all in a central place,
with support for keybindings, setting up of icons, ...
Much like MS Office, Visual Studio, etc.
Altrough all of this would need a revamping of how the menus are handled.
Basically you'll have 2 things: Actions, and Bindings.
Actions would be things that can be done in C::B, usually functions/events which are currently
part of a menu, or user-configurable Tools.
And Bindings would be:
-Menu entries
-Toolbar entries
-Key shortcuts
-Commands (like in vi/emacs/autocad)
-Text (for toolbars/menus) -short and long text descriptions-
-Icons (for toolbars/menus)
All of this information could be saved in one of these options: a plain XML,
a straight XRC (with metadata if requiered), or as the rest of the program, in a wxConfig.
Probably the best solution is to modify wxKeyBinder to do all of that, and save everything in XRCs (using tinyxml).
And the XRCs for those settings would have to be in ~/.codelocks/ instead of /share/codeblocks/ because they will be
user-configurable "resources" rather than shared resources.
About Actions:
Each Action could have Properties (or Rules, or Contexts or whatever you want to call):
It's where the Action makes sense or does not.
Like a "Swap Header/Source" Action will only makes sense in C, or C++ file.
Or a "Build" Action only makes sense in a (more generic than a C, C++ rule) compiled language.
SciTE haves something like the Actions I'm referring, but it calls them Commands, and they are very flexible.
For example, in SciTE go to menu Options->Open Global Options File, which will open the SciTEGlobal.properties file.
You'll can find or write at the end of file something like:
--- Code: --- #For fixing the identation
command.name.31.*=Fix Indentation
command.mode.31.*=subsystem:lua,savebefore:no,groupundo
command.shortcut.31.*=Alt+Shift+I
command.31.*=fixIndentation
#For hexadecimal editing of the file:
command.name.2.*=Hex Editing
command.subsystem.2.*=3
command.2.*=HexEdit
command.save.before.2.*=2
#The above uses the default Ctrl-2. As the script uses the per-buffer
#table in Lua, you will also need to set:
ext.lua.reset=0
#For running the console inside SciTE:
command.name.3.*=Run in cmd
command.subsystem.3.*=0
command.3.*=cmd
--- End code ---
For more of this power see http://scintilla.sourceforge.net/SciTEDoc.html in the part of Commands.
I want to hear your thoughs on this! :D
takeshimiya:
I've submitted the feature request here but this would be better off in a devel mailing list.
mandrav:
Sounds like a nice idea.
What you mean (roughly) is have all menus/tools bound to a dispatcher function which will select the appropriate action based on a command/action binding map.
Is that so?
takeshimiya:
Yeah, something like that, and actually like the KeyBinder interface, but not limited to menus only:
-Main menu entries
-Context menu entries
-Tab context menu entries
-Toolbar entries
-Key shortcuts
-Mouse gestures
-Commands (like in vi/emacs/autocad)
-Text (for toolbars/menus) -short and long text descriptions-
-Icons (for toolbars/menus)
An example:
Command
Command name: cmdSaveFile
Command text: "Save File"
Command description: "Saves to disk the file open in the editor"
Bindings
Menu entry: "MainMenu->File->Save"
Menu entry: "ContextMenu->Save"
Menu icon: "MainMenu->File->Save->my_save_icon_menu.png"
Toolbar entry: "MainToolbar->Save"
Toolbar icon: "MainToolbar->Save->my_save_icon_toolbar.png"
Key entry: "Ctrl+S"
Mouse gesture entry: "L9U"
VIM-like command entry: ":save"
The main point is, that Commands would be defined in the code, and the Bindings would be all user-configurable.
280Z28:
I'm very interested and want to help with this! I'll add more later, but here's one I thought of and don't want to forget!
Plugins under the new model should have an "initialize interface" type of function that is called when the plugin is installed and at the user's manual command that registers events the plugin can handle and sets up a default set of bindings like default locations for menu options and default toolbars (if it adds them). On subsequent loads, they only register the events and the bindings are remembered from the user's profile.
There will need to be ways to export, import, and copy settings between profiles. There should also be a way to choose where the profile information is stored so someone could keep a self-contained workspace on a USB drive for example.
Navigation
[0] Message Index
[#] Next page
Go to full version