You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ECCE compiles an ASCII only version of wxWidgets 2.8 while CentOS and Ubuntu/Debian ship with the unicode version of 2.8 which is incompatible. Because ECCE subclasses and extends much of wxWidgets (demarcated with the "ewx" prefix), updating the wx 2.8 code to be unicode compliant will be very time consuming.
We could
Bite the bullet and fix the hundreds of unicode incompatibilities.
Strip out as much ewx code as possible. The main reason cited for this code in the header files is "styling", though some of it does other things like field validation and selecting correct bitmap paths.
Try compiling against wx 3.0 which is more forgiving for unicode use but may also be incompatible with ewx.
This will probably be a major project and I'm leaning towards a combination 2 and 3.
The text was updated successfully, but these errors were encountered:
The most trivial example are raw strings which must be wrapped in wxT() and I was able to fix this with regex find a replace. ECCE treats wxStrings and regular strings as equivalent which is not true in unicode mode. There is a lot of code like:
where wxStrings and normal strings are mixed together (Ecce::ecceDataPath() returns a string) and its a matter converting the right variable, but would probably be difficult to script. In some cases, wxStrings must be converted to char* which is fairly involved.
I know Julia will attempt a type conversion automatically if there is one defined. Do you know if there is similar functionality in C++?
ECCE compiles an ASCII only version of wxWidgets 2.8 while CentOS and Ubuntu/Debian ship with the unicode version of 2.8 which is incompatible. Because ECCE subclasses and extends much of wxWidgets (demarcated with the "ewx" prefix), updating the wx 2.8 code to be unicode compliant will be very time consuming.
We could
This will probably be a major project and I'm leaning towards a combination 2 and 3.
The text was updated successfully, but these errors were encountered: