cbKeyBinder Plugin for HEAD

[Pecan]

@mandrav et al.

Please find attached cbKeyBndr0401.zip for HEAD

It is a much more efficient (and faster) version than
virgin wxKeyBinder. It attaches only to the first C::B frame
and any SCIwindow frames.

It avoids fooling around with disappearing wxMenuItems and
skips over menu items with file names (since c::b handles those
and keybinder shouldn't be replacing them from storage anyway).

Currently it stores the keys in %HOME% as:
 "cbKeyBinder{pluginversion}{cbMajorMinor}.ini"
because I dont know where the proper place for a plugin to store
its data should be.

One problem. The main c::b frame has no recognizable name.
So cbKeyBinder is stuffing one in as "cbMainWindow" so that
it can recognize it in keyBinder.h::wxKeyBinder::Attach().

At least one window has to be attached to allow keyBinder to
activate when no SCIwindows are open. So I chose the first one.
If you would name the first frame, I'll yank out the frame naming
code.

Note that you do not have to close windows to add keys in
cbKeyBinder.

I'm open to any and all suggestions. I hope this helps out
with the project.

thanks
pecan







[attachment deleted by admin]

[Pecan]

RE: cbKeyBinder

Another problem: it's loading the keys on a one shot timer.
As soon as I read some more of the HEAD code, I'll take
out the timer and replace it with a proper cbEVT....

thanks
pecan

[mandrav]

Pecan,

Currently it stores the keys in %HOME% as:
 "cbKeyBinder{pluginversion}{cbMajorMinor}.ini"
because I dont know where the proper place for a plugin to store
its data should be.

In Manager::Get()->GetConfigManager(_T("app"))->GetConfigFolder() ConfigManager::GetConfigFolder()

After I perform the mandatory tests, I suggest it is added in SVN (and the core wxKeyBinder be removed). Would you become its maintainer?

[mandrav]

RE: cbKeyBinder

Another problem: it's loading the keys on a one shot timer.
As soon as I read some more of the HEAD code, I'll take
out the timer and replace it with a proper cbEVT....

You might want to listen for EVT_APP_STARTUP_DONE

[Pecan]

@mandrav

Acknowledged.

I'd be happy to maintain it AND work on its replacement.

Will now go test with EVT_APP_STARTUP_DONE

thanks
pecan

[mandrav]

I was wrong on how to get the config folder above. It's a static function so you just call ConfigManager::GetConfigFolder()...

Anyway, I 'll fix this before adding it to SVN (which will be in a little while)...

[Pecan]

Acknowledged

thanks
pecan

[mandrav]

I 've put it in SVN and sent you a PM...

[Der Meister]

It seems that there is no makefile for the new plugin. At least configure complains about some missing Makefile.in:

config.status: creating src/plugins/contrib/keybinder/Makefile
config.status: error: cannot find input file: src/plugins/contrib/keybinder/Makefile.in

I think there should be a src/plugins/contrib/keybinder/Makefile.am but 'svn update' did not show one. Am I right?

[mandrav]

It seems that there is no makefile for the new plugin. At least configure complains about some missing Makefile.in:

Added.

[tiwag]

yesterday i started using the cbKeyBinder plugin and at the first look it worked ok.

but after i started modifying my shortcut-assignments and did a few restarts of CB, the keys got messed up .
there suddenly was an offset of -2 in my keybindings

let me explain by a table for the Edit menu:

menu entry            my assignment          messed up state
Undo                     Ctrl-Z                       Ctrl-X
Redo                     Ctrl-Shift-Z                Ctrl-C
Cut                       Ctrl-X                        Ctrl-V
Copy                     Ctrl-C                        F11
Paste                    Ctrl-V                        Ctrl-B
...



btw- does keybinder plugin assist personalities ?

[thomas]

btw- does keybinder plugin assist personalities ?

If it uses ConfigManager, it has no choice. Personalitites are transparent.

[tiwag]

btw- does keybinder plugin assist personalities ?

If it uses ConfigManager, it has no choice. Personalitites are transparent.

what i wanted to ask is - can you use different key-bindings for different personalities ?
i did'nt study the code but keybinder plugin doesn't store the key assignments in the *.conf file - which is unique to each personality -
but uses another file. so i am in doubt about.

another approach would be to make it possible to select between different key mapping files but my first thought was to use the already existing personalty feature for it.

[thomas]

Hmmm.... I see, it uses wxFileConfig. Well, that is not precisely optimal.
This does of course not support personalities.

[mandrav]

It could use personalities though, by appending the current personality name to the INI filename...
Hint: Manager::Get()->GetPersonalityManager()->GetPersonality()

[Der Meister]

I was wrong on how to get the config folder above. It's a static function so you just call ConfigManager::GetConfigFolder()...

Well, it seems as if '#include <configmanager.h>' is missing in either 'cbkeybinder.cpp' or 'cbkeybinder.h'. Without this include my compiler (gcc 3.4.4) complains about an incomplete type at the line you were talking about because he only knows 'ConfigManager' from a forward declaration in 'manager.h'. Adding this include-directive to one of the stated files seems to fix this problem.

[Pecan]

@tiwag

yes, I too have experienced this "shifty" key assisgnment state.
I'm looking at it. You can solve the problem temporarily by
simply re-saving the key def., ie. invoke keybinder then just click
on apply. At least for me,  it re-reads the menuItems and reassigns
to the correct menuItem id.

However, this temp solution does not correct the problem entirely.
The menu item descriptions in the .ini file will be incorrect.

I'll find a solution to this problem. It requires another fix to the
wxKeyBinder code.

thanks
pecan

[Pecan]

Re: multiple keybinder personalities.

wxKeyBinder DOES have the ability to store multiple
key "profiles". I turned it off so debugging with GDB was
simpler.

I will re-instate the multi-profile capability as soon as I'm
sure wxKeyBinder code interaction with C::B is stable.

thanks
pecan

[takeshimiya]

@Pecan: I hope you'll send the necessary patches to the wxKeyBinder autor

[tiwag]

@tiwag
yes, I too have experienced this "shifty" key assisgnment state.
I'm looking at it. You can solve the problem...

no problem 

i could solve it easily, but i think the real problem behind the scenes is, that
you obviously have no synchronization between the actual menu-layout and
the saved one in the keybinder.ini file (only sequence).
This time it was triggered, because the src/resources/main_menu.xrc was
changed (rev 1498) in SVN HEAD.

But i think this could be a general problem...
as far as i remember, any plugin can add menu items here and there
what when my plugin adds a menu item and keybinder saved the ini file
when this particular plugin wasn't loaded ? (--> shifted )

Maybe your actual implementation can handle this situation already ?
( i don't know - didn't look into the sources)

i only wanted to make attentive to such situations !

[tiwag]

Re: multiple keybinder personalities.

wxKeyBinder DOES have the ability to store multiple
key "profiles". I turned it off so debugging ...

the proposal of Yiannis, to change the filename according to the personality, sounds good !

then we could have something like


personality       config-file        keybinder-file     

tiwag             tiwag.conf         tiwag.keyb     
pecan             pecan.conf         pecan.keyb     
default           default.conf       default.keyb     

i think this looks good

[takeshimiya]

It is too much hassle to save them right in the personality .conf?

[tiwag]

It is too much hassle to save them right in the personality .conf?

for some reasons i would prefer to split them

[takeshimiya]

What is the rationale?

I rather would preffer to have every configuration inside the default.conf.
And because it's an xml, is rather simple to export/import certain things appart (in this case the keybinder settings or any other).

It just doesn't make sense of why the key config will be separated when for example, the editor colors not.

[thomas]

The advantage of the configuration model that we have now is that everything is in once place, and you can copy one file if you have to migrate. By storing plugin configuration exernally, you give up that advantage.

[Pecan]

@tiwag

any plugin can add menu items here and there
what when my plugin adds a menu item and keybinder saved the ini file
when this particular plugin wasn't loaded ? (--> shifted )

Inserting/deleteing menu items while c::b is running
is nolonger a keybinder problem. It used to crash tho.

On loading the .ini file, keyBinder needs to verify it's entries from the
.ini file against the real world Menu. Currently it thinks
its file copy IS the real world.

I believe that would fix it.


thanks,
pecan

[Pecan]

HEAD KeyBinder updated 12/14/2005 4PM

Fixed shifty key bindings

Re-Fixed activation when no editors open. Will now activate
even if all editors closed. (Attachs to "notebook")

The menuItem Id in the .ini file may be wrong, but it doesnt matter.
We nolonger depend on them. C::B has it's own "vays vit id's".

Note: still having problems with some key combinations. Ctrl+Alt+} and
Ctrl+Alt+{ et.al. end up as Ctrl+Alt+BLANK on reload. Will go after
this soon.

thanks
pecan

[Pecan]

I am aware there are some problems with keybinder for HEAD after
the conversion to unicode.

It can't find its old profiile file, and it isnt honoring event.Skip()
in OnAppStartupDone().

I'll have it fixed tomorrow day time (12/31/2005).

thanks
pecan

[Pecan]

12/31/2005 10:44 AM

Commited a fixed "unicode" version of KeyBinder.

Fixed missing event.Skip() in OnAppStartupDone() which caused other
plugins to miss EVT_APP_STARTUP_DONE.

Fixed unicode Filename creation. Guess you can't do:
 

Code

"wxString mystring = mystring << SDK_PLUGIN_MAJOR << SDK_PLUGIN_MAJOR;"

like operation anymore. Compiler doesn't complain
but the string ends up empty. wouldn't even work with int(s) rather than
defines. Too bad. I liked doing that.

Enabled multi-profile storage. It was always there. I'd disabled it for
debugging convenience.

thanks
pecan

[thomas]

And once again, macros are the source of all problems...

SDK_PLUGIN_MAJOR and SDK_PLUGIN_MINOR are not const ints but are indeed macros (though they are converted to ints during compilation). The problem is that this happens behind your back...