Author Topic: compiling cbkeybinder fails on trunk with wxWidgets-3.1 trunk  (Read 1251 times)

Offline blauzahn

  • Multiple posting newcomer
  • *
  • Posts: 101
svn11709 with following error:

Code: [Select]
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.

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2180
Re: compiling cbkeybinder fails on trunk with wxWidgets-3.1 trunk
« Reply #1 on: May 29, 2019, 07:24:31 am »
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

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2180
Re: compiling cbkeybinder fails on trunk with wxWidgets-3.1 trunk
« Reply #2 on: May 29, 2019, 07:36:19 am »
Fixed the spelling for wxstringhash.h for Linux. Head rev 11710 .
« Last Edit: May 29, 2019, 08:26:16 am by Pecan »

Offline blauzahn

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: compiling cbkeybinder fails on trunk with wxWidgets-3.1 trunk
« Reply #3 on: May 29, 2019, 09:09:24 am »
Now with svn11710 it compiles fine again.

Thank you.

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2566
Re: compiling cbkeybinder fails on trunk with wxWidgets-3.1 trunk
« Reply #4 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!

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2180
Re: compiling cbkeybinder fails on trunk with wxWidgets-3.1 trunk
« Reply #5 on: May 29, 2019, 11:26:18 pm »
@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.
« Last Edit: May 29, 2019, 11:43:18 pm by Pecan »

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 2566
Re: compiling cbkeybinder fails on trunk with wxWidgets-3.1 trunk
« Reply #6 on: May 30, 2019, 12:07:19 pm »
great!
Thank you for the work!