User forums > Using Code::Blocks

[Feature Request] keyboard shortcuts for user defined tools

<< < (2/4) > >>

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:

--- Quote from: jamieo on March 24, 2007, 03:38:05 pm ---...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

--- End quote ---

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

Seeking out these bugs and new ideas are most welcome.

jamieo:

--- Quote from: Pecan on March 24, 2007, 08:21:12 pm ---I certainly did not intend to discourage anyone from contributing to the project.

Seeking out these bugs and new ideas are most welcome.
--- End quote ---
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!


--- Quote from: Pecan on March 24, 2007, 01:46:20 pm ---When the Tools menu is modified in the background, it is always rebuilt without its shortcuts. KeyBinder will slowly record this fact.

--- End quote ---
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

Navigation

[0] Message Index

[#] Next page

[*] Previous page