[cmake-developers] Future of ccmake and cmake-gui and internationalization
Alan W. Irwin
irwin at beluga.phys.uvic.ca
Thu Aug 17 01:03:55 EDT 2017
On 2017-08-16 09:16-0700 Eric Wing wrote:
> I am not making a strong push for this, but I want to bring it up to
> at least get people thinking about this... I am disturbed by the size
> and complexity of Qt. My past experiences have not been good and I
> find it a massive chore to get an environment setup (especially on Mac
> and Windows...and building Qt on Raspberry Pi is a nightmare). And the
> binary sizes are large. (I do ship CMake to my users and its size with
> the GUI is non-trivial.)
> CMake's actual GUI isn't that complex. Have you considered something
> As one alternative, there is IUP:
> (it's from the same university that created Lua...in fact I think one
> of the original authors of the white paper/project went on to become
> one of the Lua authors.)
> IUP differs from Qt in that is is focused on wrapping native GUI
> widgets (in constrast to Qt which creates its own non-native widgets).
> Hence, the library is really small since it only depends on each
> platform's native libraries. The core library is about 1MB. I just
> ported (rewrote) a simple Qt based app to IUP. The Qt version was
> almost 40MB. The IUP RAM usage is also many times smaller.
> It has native backends for Windows, GTK2, GTK3, Motif, Haiku. Because
> it historically didn't have a Mac OS X backend, most people overlooked
> it. However...I've been implementing a native Mac OS X backend. It's
> not finished, but there is a lot implemented and I'm actually shipping
> a simple app with it this week. Since CMake's GUI usage is also pretty
> simple, I *think* there might already be enough implemented to do the
> CMake-GUI...or it's close enough that I probably could finish those
> needed features.
> Also, I implemented a CMake build system for IUP.
> IUP is MIT licensed.
> Now IUP only does GUI (which is another reason it stays small), so you
> will need to fill in the JSON and Process requirements. But there are
> tons of JSON libraries. Off the top of my head, cJSON is a really
> fast, tiny, and simple to use JSON library. It's a single C file and
> header, so you can drop it right in the project. (Also MIT). It also
> has a CMake build system if you really want it.
> And a cross-platform create process...those I've seen everywhere and
> I've actually written my own too. I think Apache Runtime is only
> measured in hundreds of kilobytes even with all the stuff you don't
> A quick Google search turned up this one C++ (MIT)
> So IUP + some JSON + some Process should be around 1MB-2MB. This is in
> contrast to the Qt frameworks I have right now in my CMake bundle for
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.
However, it is a very strong point that a light-weight API is much
nicer to use than a heavy-weight API. So your post and that
open-source license got me quite interested in IUP (which I had frankly
never heard of before).
One of my fundamental criteria for a graphics library is it must have
complete internationalization support, i.e., the library must support
both unicode (preferably in the utf-8 encoding of unicode) and Complex
Text Layout (CTL). Just for fun, I tested this cmake-gui capability
using a utf-8 encoded Arabic word "ﺳﻼم" (for "Peace" since that is
about the only Arabic word I know) to temporarily document one of the
PLplot cache variables and got good results (e.g., when I hovered over
the "TEST_PEACE" option the "ﺳﻼم" documentation of that option was laid out in the
correct right-to-left order by the current Qt-based cmake-gui because
Qt (as well as at least GTK+, wxWidgets, and GDI/GDI+/Uniscribe,
Direct2D/DirectWrite on Windows and preumably Mac OS X graphics as
well) support both unicode and CTL. I also tried naming the
option itself "ﺳﻼم" rather than TEST_PEACE, and that rendered correctly
Note the above Arabic word for "Peace" may not be rendered correctly
(or at all) by your mailer, but if you dump this e-mail to a file
and look at it with less, or some unicode-aware editor like
emacs or vi (but not jed (!) I just discovered), it will be rendered
correctly just as in the PLplot Peace flag example,
Also, if you use the cmake application instead of cmake-gui, the
resulting cache file CMakeCache.txt has the correct rendering
of "ﺳﻼم" if viewed with the correct unicode-aware application.
So both the cmake and cmake-gui applications currently support unicode
and CTL, but the question on my mind is if cmake-gui is changed to use
IUP rather than Qt will that nice result continue for that application?
So to help answer that question I did a google search for the terms
and it appears from those 10 hits that IUP completely supports the
utf-8 encoding of unicode and since CTL capability is completely in
the domain of the backend libraries, I am virtually positive that IUP
supports both unicode and CTL for at least its GTK+ backend and likely
its Windows backend. However, since those capabilities are so
important (at least in my opinion) to cmake-gui can you please confirm
this positive speculation concerning IUP for these two backends for me
(and also your new Mac OS X backend). That test simply requires you
to modify the first IUP tutorial example to use "ﺳﻼم" to see whether
that Arabic word is rendered in the correct right-to-left order in the
IUP GUI. Also, if the other IUP backends such as Motif and Haiku don't
deal with the CTL issue properly, then I think that would be a fairly
important justification for sticking with Qt instead for cmake-gui.
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.
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
More information about the cmake-developers