[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
> lighter-weight?
>
> As one alternative, there is IUP:
> http://webserver2.tecgraf.puc-rio.br/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
> need.
> A quick Google search turned up this one C++ (MIT)
> https://github.com/eidheim/tiny-process-library
>
> 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
> Mac.

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.

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
as well.

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,
<http://plplot.sourceforge.net/examples-data/demo24/x24.01.png>.

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

unicode site:http://webserver2.tecgraf.puc-rio.br/iup/

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.

<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>

Alan
__________________________
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).
__________________________

Linux-powered Science
__________________________


More information about the cmake-developers mailing list