News:

The new Release 25.03 is out! You can download binaries for Windows and many major Linux distros here .

Main Menu

compiling cbkeybinder fails on trunk with wxWidgets-3.1 trunk

Started by blauzahn, May 29, 2019, 06:21:04 AM

Previous topic - Next topic

blauzahn

svn11709 with following error:


libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../../../trunk/src/plugins/contrib/keybinder -I../../../../src/include -I/usr/local/lib/wx/include/gtk2-unicode-3.1 -I/usr/local/include/wx-3.1 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../../../../trunk/src/include -I../../../../../trunk/src/sdk/wxscintilla/include -DCB_AUTOCONF -DCB_PRECOMP -DPIC -I../../../../../trunk/src/include/tinyxml -DTIXML_USE_STL=YES -O2 -ffast-math -Winvalid-pch -fPIC -fexceptions -MT cbkeybinder.lo -MD -MP -MF .deps/cbkeybinder.Tpo -c ../../../../../trunk/src/plugins/contrib/keybinder/cbkeybinder.cpp  -fPIC -DPIC -o .libs/cbkeybinder.o
In file included from ../../../../../trunk/src/plugins/contrib/keybinder/cbkeybinder.h:27,
                 from ../../../../../trunk/src/plugins/contrib/keybinder/cbkeybinder.cpp:50:
../../../../../trunk/src/plugins/contrib/keybinder/clKeyboardManager.h:30:10: fatal error: wxStringHash.h: No such file or directory
#include "wxStringHash.h"   //required for wxWidgets < wx3100
          ^~~~~~~~~~~~~~~~
compilation terminated.
make[5]: *** [Makefile:617: cbkeybinder.lo] Error 1


Breaking change must have been put into trunk during the last 24 hours, likely svn11705, 11708 or 11709.

commenting out the #include line in files json_node.h and clKeyboardManager.h helps.

OS arch x86_64 GNU/Linux, g++ (GCC) 8.3.0

@pecanh: Please, can you have a look into this?

Thank you.

Pecan

To get around this quickly, please change the spelling of wxStringHash.h to all lower case on Linux.

I'll correct it as soon as SourceForge comes back online for me.

Thanks

Pecan

Fixed the spelling for wxstringhash.h for Linux. Head rev 11710 .

blauzahn


BlueHazzard

@Pecan:
Can you give some more information what the rework can do and how it works? Thank you!

Pecan

Quote from: BlueHazzard on May 29, 2019, 09:41:07 AM
@Pecan:
Can you give some more information what the rework can do and how it works? Thank you!

The old cbKeybinder 1.0 was created 14 years ago using wxCode
(http://wxcode.sourceforge.net/components/keybinder) as a model.
wxCode KeyBinder used a bazillion OnChar wxEvtHandlers to intercept and interpret keyboard input.[4]

It worked satisfactorily until about a year ago, when it could no longer re-toggle a check menu item after the first toggle.

This was caused by changes in wxUpdateUI usage. I was never able to find a good work-around that didn't require issuing wxUpdateUI just before every toggle.[2]

I noted that CodeLite did not have the problem. It doesn't use the wxEvtHander model and therefore does not have to manage wxEvtHandlers on every window. [1]

CodeLite sets menu items directly at app initialization, does not have to interpret OnChar event key codes, and even allows users to ask/for and set global accelerators as well as menu items.
It's a much more efficient and safer model.

Amazingly, it makes all app accelerators usable to wxAUI frames by managing the wxAccelerator table.

I have not implemented all features allowed by the CodeLite model. My purpose for
cbKeyBinder 2.0 was to implement the base features of the model while preserving
user KeyBindings from version 1.0 .[3]



[1] For each window, KeyBinder ver-1 had to assure it's event hander parented any other, else it could have missed keyboard accerators. Not so reliable.
[2] For some reason, wxWidgets (or CodeBlocks) stopped updating the state of check menu items such that when fetched by a plugin it always showed the old setting until the menu item was reactivated by the user (which caused a wxUpdateUI event).
And it could not be programatically set without issuing a wxUpdateUI event. That would have been seen by every task connected to UpdateUI events. That made me uneasy. Issuing unwarranted wxUpdateUI events could have broken too much code.
[3] In particular I have not yet implemented wxAUI support or allowing users to set global accelerators.
[4] wxCode also used a raw Matryoshka doll array structure incredibly hard to understand and maintain. I'm happy to be out from under that nest of dolls.

BlueHazzard