cbKeyBinder Plugin for HEAD

[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...