[Feature Request] keyboard shortcuts for user defined tools

[dierk]

Keyboard shortcuts for user defined tools is a must working on different compilers like AVR GCC for using the programs on microcontrollers etc.
After building the code it have to be transfered to the controller. For this step you have to start an additional program like AVR Dude. Working only with menus sucks.

[Pecan]

Keyboard shortcuts for user defined tools is a must working on different compilers like AVR GCC for using the programs on microcontrollers etc.
After building the code it have to be transfered to the controller. For this step you have to start an additional program like AVR Dude. Working only with menus sucks.

Unfortunately, adding hotkeys to the Tools menu will not work since that menu is rebuilt at every startup and every tool change. It does not honor the menu accelerators.

However, a little know plugin will work. Called KeyMacs. Say your tool is sixth in the list on the Tools menu. A KeyMac of "!T{DOWN 6}{ENTER}"
with a command key of, say, "Alt-Ctrl-T" will execute that tool.

   //-- KeyMacs
    KeyMacros Plugin

      KeyMacs Thread

[Commodore64]

Are you sure of this? With the KeyBinder plugin (Settings -> Editor -> Keyboard shorcuts) I was able to associate a shortcut to every layout defined by me (the ones in View -> Layouts). These menu items are dynamically generated, so I don't see why the same should apply to items in the tool menu.

[jamieo]

I've just been playing with this earlier today and now I see this topic...

You can set keyboard shortcuts and they work nicely.  However, when you restart some of them will be lost.  Then, when you restart some more will be lost.  I can confirm that it should work as pasting the missing items back into the ini file (from the backup) before restarting will restore your menu items....   until you shut down.

Notice, I said you can paste them in from the backup... here in lies the problem:

• I create some shortcuts in the tools menu using Ctrl-Alt-1 to 5 for simplicity.
  
  
• Shutdown codeblocks and compare the cbKeyBinder10.ini.bak and cbKeyBinder10.ini files
  
     cbKeyBinder10.ini contains 1 and 4 while cbKeyBinder10.ini.bak contains 2, 3 and 5.... 
  
  All shortcuts have been saved but 3 of them to the wrong file!   :shock:
  
  
• Restart Codeblocks, 1 and 4 have been retained.
  
  
• Shutdown and recompare, 1 and 4 are now in the backup.
  
  

I've done this with many shortcuts and you loose a few each time you shut down until after a few restarts they are all gone.  I think it's obvious the code that saves the shortcuts is incorrectly writing some of them to the backup file - why it should even have the backup open is a mystery...  Note, I've have also lost shortcuts that are not in the tools menu but it is not often so I have not confirmed what happens as above. 

With the steps above I think an experienced codeblocks developer should be able to fix this without much hassle.  If not, I will try to look into it myself (not now, it's 3.30am!) but an experienced codeblocks developer I am not. 

Jamie

[Pecan]

As I stated earlier, shortcuts cannot be preserved when applied to the Tools menu.

The Tools menu is dynamically rebuilt in many magic ways that are unknown and unseen by the KeyBinder plugin.

KeyBinder scans and memorized the shortcuts every 15 seconds. If a plugin or core module has modified a menu item in the background, KeyBinder will see the change, backup up the current keybinding, then rewrite the new bindings .ini file.

When the Tools menu is modified in the background, it is always rebuilt without its shortcuts. KeyBinder will slowly record this fact.

When a menu item is created/changed/destroyed there may be a delay in the way that wxWidgets executes the change. Some menu items may be mirrored in the .ini while others arn't until wxWidgets gets around to updating the UI menus.

Thus, the backup file and the .ini can mirror different menu system transition states.

Until a means is provided for KeyBinder to recognized the change, KeyMacs can provide a solution.

KeyMacs shortcuts for the Tools items are applied from the KeyMacs menu, not the Tools menu. KeyMacs is not dependent on KeyBinder.

    //-- KeyMacs
    KeyMacros Plugin
    KeyMacs Thread

[jamieo]

The point is that all the shortcuts can (and are) recognised.  Also, when present in the ini file they are restored correctly.  For whatever reason some shortcuts are first saved, and then lost, even though they still exist.  The mechanisms to both save and restore these shortcuts have been proven above so it should be obvious that the possibility exists to make this work. 

Thanks for your post, although you've dismissed my observations (a feeling that's becoming familiar here), you have at least given me some insight into the source and where to start looking.  However, the resistance I've met so far trying to contribute to this so called "open source" project (CodeBlocks - not just this plugin), makes me wonder if it's even worth looking into the source...

I have a number of ideas for fixes and improvements, along with some patches already being worked on.  Regretfully, I feel my contribution would likely be ignored or dismissed (and my time wasted).  This is unfortunate and makes me doubtful even using CodeBlocks as my IDE is a good idea, a project so unwelcoming to new blood and fresh insight cannot progress well - despite it's potential.  Codeblocks has a user base that consists entirely of developers - it should be capitalising on that fact!

Jamie

[Pecan]

...Regretfully, I feel my contribution would likely be ignored or dismissed (and my time wasted).  This is unfortunate and makes me doubtful even using CodeBlocks as my IDE is a good idea, a project so unwelcoming to new blood and fresh insight cannot progress well - despite it's potential.  Codeblocks has a user base that consists entirely of developers - it should be capitalising on that fact!

Jamie

I certainly did not intend to discourage anyone from contributing to the project.

Seeking out these bugs and new ideas are most welcome.

[jamieo]

I certainly did not intend to discourage anyone from contributing to the project.

Seeking out these bugs and new ideas are most welcome.

That's good to hear, although it has not been my experience so far and reading posts elsewhere in the forum I am not alone.  Note, I am talking about this forum as a whole, as previously noted.  Therefore, as I do have other things I need to get on with, I hope the time I've taken to write up the following has not been wasted. 

There are three events I found to trigger a save of the keyboard shortcuts:- User Configuration Dialogue, Shutdown of Codeblocks and some external change that can only be detected by the 15sec timer (see post above by Pecan).  I have tested each of these triggers and compared the resulting files for differences and found the only time the tools items configuration is written incorrectly is when shutting down codeblocks.. I believe the reason for this is the operation to scan through and parse every menu item takes a long time and codeblocks starts to delete it's tools menu before keybinder has finished enumerating it - in other words, codeblocks does not seem to wait for it's plugins to exit before it starts to shut itself down (although it may well wait before actually terminating, that's not the issue here).

Removing the save within cbKeyBinder::OnRelease makes for a tools menu that is fully saved and restored - every time.  Although not ideal it is a good enough workaround as most changes are done through the configuration, those that aren't will be caught by the timer so I guess the only danger is something unknown adding a shortcut just before shutting down.  However, that'll likely be a plugin so it'll restore it on it's own when reloaded?  Stop me if I'm completely wrong but it seems to work well here and I've changed a lot of the standard, plugin and tools shortcut items.

Anyway, based on the above I hope we can see this is a timing issue and will most likely require a change in the CodeBlocks source to rectify properly.  I'm sure there is some 'hacky' workaround that forces codeblocks to wait but that would be unpleasant and not too useful to other plugins this could potentially effect.  I hope someone familiar with the guts of CodeBlocks will check this issue and confirm either way.

Btw, it's not just the tools items that are affected.  The following entries are potentially lost along with the tools items when saving on exit.  The second item would suggest it's not just the tools menu being removed prematurely...

• bind121-type4660=Configure tools...|Add/remove user-defined tools|
• bind925-type4660=Complete code||Ctrl-SPACE|

Also, a similar problem unrelated to the above...  The entries below are lost when a save is triggered at the same time as their parent menu, 'Select Target..' is greyed out.  Neither can you configure these shortcuts when their parent menu is disabled.  This behaviour is inconsistent with other parent menus and their children such as those under the 'Edit' menu ('Folding', 'Special Commands' etc.).  I think it's just some special processing needed that's been overlooked for this one.

• bind1481-type4660=All|Build target 'All' in current project|
• bind1482-type4660=default|Build target 'default' in current project|

 

One more thing I've noticed (before I get thrown out!) is that the context menu for the 'Projects' tab is never updated to reflect current keyboard shortcuts (move project up/down etc.), although they work and the same items in the main menu are correct.

PS: it's taken me (much) longer to write this than it took to test it all out - so when my (or anybody else's) effort is dismissed without proper consideration it's understandably discouraging, as well as frustrating!

When the Tools menu is modified in the background, it is always rebuilt without its shortcuts. KeyBinder will slowly record this fact.

This is a separate and less annoying issue to the one I first posted about as it can at least be worked around.  There are two solutions to it though:  detect the 'Configure Tools' dialog and perform a restore of the items that still match (I notice keybinder already detects new windows so it shouldn't be hard), this would be a bit of a hack though.   The preferred solution is codeblocks should only need to delete/insert/modify items as needed and can check if a shortcut is assigned beforehand and restore it (eg. if a caption is being changed).  This is certainly the case on windows anyway - there is no need to rebuild from scratch each time.  I'd look into creating a patch to do this if I had any faith it would be accepted and my effort wouldn't be wasted.

If you want to progress with any of the above then I am willing to help.

Jamie

[Pecan]

When KeyBinder initializes, it scans the "visable" menu items, grabs the menu items' id and tries to match the id to one in the .ini file. Most of the time this is successful because the menu items have the same id they had when last KeyBinder saved its .ini file.

In some cases, such as the Tools menu (among others) the menu ids have been dynamically assigned during CB initialization and the menu ids have no matching ids in the .ini file. The menu "text" may match text in the file, but the ids don't match.

So KeyBinder skips the menu item. This is historical. The way wxKeyBinder was designed did not allow for dynamically assigned menu ids, or dynamic menu items for that matter.

CB KeyBinder *must* record new menu items and ids created by the core  CB and other plugins. Else the situation gets worse. Thus the 15sec scans.

Unfortunately, the result of that scan, is to write out the unmatched menu items without their cmdkeys. The cmdkey is thus lost.

KeyBinder, at one time, once failing to match ids, attempted to match menu "text". That failed, because, at the time, CB had duplicate menu "text" items. Assigning by "text" caused KeyBinder to assign the wrong cmdkey to the wrong menu item. The cmdkey would float around willy nilly, sometimes matching ids, somethimes matching whatever "text" it could hang its hat on.

I have noticed in the last few months, that the duplicate menu items have disappeared. It might be time to kick the tires on that old code again.
 

 

[jamieo]

Hmm.. you haven't read my post - or at least, you've not responded to any of the points I've submitted within it.

Unfortunately, this is the second time I've wasted significant time looking into a problem in order to make a proper, informed report to a developer on this site - only to see my effort mostly ignored, so please forgive my frustration.  I've also developed and hosted very popular software (not OS) so I know both sides of the keyboard and the constant request for fixes, features and new releases.  Therefore, I've tried to be understanding and do most of the grunt work for you - all you have to do is read my post and test it for yourself!  IMO it's inefficient (and apparently ineffective) to manage keyboard shortcuts with a plugin - it should be within the core functionality!  However, that's the way it's done and I tried to help make it work.  No doubt the plugin was originally written because of an unwillingness to implement the code within the IDE.

Anyway, I can see that there is a very defeatist, 'can't do' attitude to the developers on here and you are willing to leave significant features only partially implemented because it's too much effort to complete. What's most puzzling is you're happy working this way and you don't appreciate it when others try to help resolve those glaring omissions.

It's clear I should not continue to waste my efforts on a project that does not want to progress.

Jamie

[Pecan]

...It's clear I should not continue to waste my efforts on a project that does not want to progress.

Jamie

Yes, you're most welcome to go waste your time somewhere else.

[jamieo]

Yes, you're most welcome to go waste your time somewhere else.

Can't say that surprises me - it's the very attitude I've described! 

One last thing before I pack up my toys and play elsewhere..  here's a patch that allows you to have separators in the tools menu to help organise things a bit.  It's only a simple little thing a few lines long but I was surprised not to have this functionality so here it is.  I know it has nothing to do with keybinder but the OP might benefit from it if nothing else.  I'm not going to waste any more effort trying to submit it but anybody else is welcome to do so.

There are other patches I've been working on (as well as some I've submitted for 'ThreadSearch' to dje, a developer who does welcome feedback) but they're not quite finished and it's become clear that spending more time trying to make an ide work than actually using it is counter productive!

Code

Index: trunk/src/sdk/toolsmanager.cpp
===================================================================
--- trunk/src/sdk/toolsmanager.cpp	(revision 3738)
+++ trunk/src/sdk/toolsmanager.cpp	(working copy)
@@ -328,10 +328,16 @@
         {
             tool->SetMenuId(wxNewId());
         }
-        m_ItemsManager.Add(menu, tool->GetMenuId(), tool->GetName(), tool->GetName());
-        Connect(tool->GetMenuId(), -1, wxEVT_COMMAND_MENU_SELECTED,
-                (wxObjectEventFunction) (wxEventFunction) (wxCommandEventFunction)
-                &ToolsManager::OnToolClick);
+
+		if (tool->GetName() == wxT("-"))
+			m_ItemsManager.Add(menu, wxID_SEPARATOR, _T(""), _T(""));
+		else
+		{
+			m_ItemsManager.Add(menu, tool->GetMenuId(), tool->GetName(), tool->GetName());
+			Connect(tool->GetMenuId(), -1, wxEVT_COMMAND_MENU_SELECTED,
+					(wxObjectEventFunction) (wxEventFunction) (wxCommandEventFunction)
+					&ToolsManager::OnToolClick);
+		}
     }
 
     if (m_Tools.GetCount() > 0)

[Ceniza]

There's actually a way to add a shortcut to the Tools, but it's tricky.

When adding or editing a tool, at the end of the "Name" of the tool add a "tab" and the key accelerator. To add the "tab", open a text editor, press tab, select it, copy it and paste it.



That should work with the help plugin too

[Pecan]

With the new fixes from this "week of fixes" (2007/03/31), KeyBinder will soon be able to maintain shortcuts on the Tools menu.

@Ceniza, very clever. Wish I'd thought of that.

[jamieo]

KeyBinder will soon be able to maintain shortcuts on the Tools menu.

I see you finally implemented the change I suggested above. :shock: :roll:

I can confirm with the latest nightly that KeyBinder does already maintain shortcuts on the Tools menu.

Good thinking Ceniza, I wonder if that works with normal win32 menus or if it's just a wx thing..

Jamie