[cmake-developers] Future of ccmake and cmake-gui and internationalization

[Eric Wing]

> Hi Eric:
>
> My opinion is your point about size is weak because IUP normally depends on
> a big suite of graphical libraries in the GTK+ case or a big set of
> system libraries such as GDI/GDI+/Uniscribe or Direct2D/DirectWrite in
> the Windows case.
>

On systems the provide first class native GUIs, I would disagree with
this point because the system libraries are typically already loaded
by everything. Furthermore, even non-native frameworks like Qt need to
link into the native frameworks even though they may not be using much
from it. So you take a double hit because you get both the system
frameworks and the non-native implementation. This is very apparent on
Mac, where everything links to Foundation and AppKit as a baseline.

I do cede that GTK is not small. However, almost all the distros I see
today ship at least GTK2, with a lot of forks UI forks in protest of
GTK3 and Gnome, and intentionally kept GTK2 alive because it was much
smaller than GTK3. So there is probably something already on your
system using it. But if you really need something smaller, Motif is
always an option. (Also, somebody is experimenting with my Cocoa
backend and has a prototype working in GNUStep on Linux though I
wouldn't necessarily consider that small either and few systems
install it.)



> <off topic>
> Thanks to your post the possibility now exists that I or one of my
> PLplot colleagues will develop an IUP-based device driver in the
> intermediate future. So if that occurs I would plan to download and
> build IUP for myself on Linux.  And that would put me in a position to
> do the above simple test myself. But that is in the speculative
> future and only for the GTK+ backend case.  So your test results now
> on this unicode and CTL question for as many of the IUP backends as
> possible would be much appreciated.
> </off topic>

I'll be honest, string encodings are not my strong suit. What I can
say is that IUP is developed in Brazil where they speak Portuguese. So
I know being able to at least support their language is important to
them, so I hope that means they got a lot of the string encoding stuff
right. For the Cocoa implementation, IUP has a mode called UTF8 mode
and I am basically enforcing that it is on for Mac. For every C string
I have to bridge, I hand it to the native Cocoa UTF8 APIs that convert
back and forth between C strings and NSStrings (native Cocoa string
type). I did have some fellow Cocoa devs review my code and run a few
tests, and they believed it was correct. Though it was not exhaustive.
If the implementation is wrong, I would like to correct it.

-Eric