Hi Jan,
Thanks! I recently contacted Brad about what the progress will be to
make it work. The unicode issue is probably not applied because I did
not work on it for quite a while. I had other things to do, and the
need for it did not really exist back then. But now that we have a
fresh user base (the KDE crew) and CMake is really taking a flight, I
asked Brad if it was needed to look at it again. He'll mail me back
about that sometime soon I hope.
So, as far as I can recall the 'unfinished' parts are;
- Command line params for auto testing and adding paths on the fly, or
start the app automatically for generation and close automatically too
- Unicode
- A better way to specify paths with a [...] button. I am using wxGrid
and that does not allow drawing of buttons in a cell. I could try to
draw a semi browse image that when pressed pops up a browse dialog
I'll be happy to contribute these changes if it's needed.
With regards,
- Jorgen
On 7/5/06, Jan Woetzel <[EMAIL PROTECTED]> wrote:
Hi,
I am running into troubles compiling WXDialog against a WX compiled as
UNICODE build.
Using
- CMake CVS from yesterday,
- wx UNICODE build on Linux (because the defalt Suse 10.1 supplied binary
rpms are build with unicode)
- wx non-Unicode "ansi" on Windows makes no problem (compiled by me),
- wx 2.6.3
With UNICODE build there are lots of errors regarding conversions between
non-std:.string, char* and wxString, wxChar because of missing ""
The errors can be solved using
- wx underscore macro, e.g. _("foo")
- explicit wxString contructors, e.g. wxString(std::string.c_str(),
wxConvUTF8)
- explcit Ascii conversion, e.g. wxString.ToAscii()
See http://www.wxwindows.org/manuals/2.6.3/wx_unicode.html
I started fixing them, then noticed Mathieu already fixed some of them and
submitted a patch:
http://public.kitware.com/pipermail/cmake/2005-August/007058.html
(1) However, the patch was not applied to CMake CVS, right? Why not?
(2) The patch does not fix all problems in yesterdays cvs - at least some
argv conversions (char** / wxChar**) need a fix.
(3) Has anybody solved the issue and can submit a patch that will be
included in CVS ?
WXDialog is using the CMakeLib through its char* interfaces.
(4) Will Cmake always use ascii or are there future plans to switch CMake
to UNICODE wchar ?
The explicit wxUTF8 conversion will only work, if Cmake itself is build as
unicode/wchar.
Thus I have a feeling to avoid unicode in CMakeLib interfaces.
I like WXDialog more than than MFCDialog/Cursesdialog because
- running the same gui on Windows and Linux is great,
- WXDialog does not jump to beginning of list after deleting a single cache
entry.
To conclude:
Great work , Jorgen!
We just need 1% more coding to make it useable with Unicode builds which
seem to be default at least on Linux, now.
Best,
Jan
--
Dipl.-Ing. Jan Woetzel
--------------------------------------------------
University of Kiel
Institute of Computer Science and Applied Mathematics
Hermann-Rodewald-Str. 3 [room 310]
24098 Kiel/Germany
--------------------------------------------------
Phone +49-431-880-4477
Fax +49-431-880-4054
Mob. +49-179-2937346
--------------------------------------------------
Url www.mip.informatik.uni-kiel.de/~jw
Email [EMAIL PROTECTED]
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
