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

[Bill Hoffman]

On 8/17/2017 12:11 PM, Eric Wing wrote:

Oddly, I don't have any direct experience with FLTK even though I've
known about it for years. The projects I get involved with usually
need a lot more native UI integration, so FLTK is never on the list.
And I personally prefer native UI experience.  But for something small
like the CMake GUI, it wouldn't bother me as much. That said, it
sounds like this is not a rewrite, so I guess the conversation is
moot.
CMake originally had an FLTK GUI it was dropped for the Qt one.  :) 
This happened around the time Qt changed licenses.  I am not that 
interested in dropping Qt for something else at this point.  Computers 
have big disks/memory so the bloat does not bother me that much.  There 
are folks maintaining the Qt cmake-gui and there seems to be enough Qt 
knowledge around to keep that going.


-Bill
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Alan W. Irwin]

On 2017-08-17 08:55-0700 Eric Wing wrote:


On 8/17/17, Alan W. Irwin  wrote:

On 2017-08-17 04:15-0700 Eric Wing wrote:


I hope I'm doing this right...but the resulting program I think looks
correct testing on my Mac. Attached are two pictures.

The first is a simple label in a window.
The second is from your MessageBox line.


Yes, I confirm those two PNG images have that Arabic Peace word rendered
in the correct right-to-left order.

So that settles the question for what I assume is your Mac OS X native
graphics back end.  Can you (or some other IUP developer) do that same
simple test for Linux native graphics (probably GTK+) backend and
native Windows graphics backend?

Alan
___


I think it works.
Attached are screenshots from Ubuntu 12.04LTS with the GTK2 backend,
and Windows.


I confirm that (rho-like character rendered on the left, omega-like
character rendered on the right) which should put this CTL concern to rest.

Thanks for your help answering this critical question (from my
perspective) for the three separate platforms.

By the way, could you let me know if/when your CMake-based build
system is completed to your satisfaction and ideally accepted into
official IUP?  I am prejudiced toward using CMake-based build system
alternatives whenever possible so official acceptance by IUP
developers of your build-system work will likely be the occasion when
I first give an IUP build a try.

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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

> If small and self-reliant are the criteria, how does FLTK
> (http://www.fltk.org/index.php) stack up?  For something like
> cmake-gui it would probably work just fine, and AFAIK it doesn't
> require GTK...  it uses LGPLv2 with a static linking exception, so
> it's probably as good/better than the current Qt requirement in that
> department.

Oddly, I don't have any direct experience with FLTK even though I've
known about it for years. The projects I get involved with usually
need a lot more native UI integration, so FLTK is never on the list.
And I personally prefer native UI experience.  But for something small
like the CMake GUI, it wouldn't bother me as much. That said, it
sounds like this is not a rewrite, so I guess the conversation is
moot.

Thanks,
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Alan W. Irwin]

On 2017-08-17 04:15-0700 Eric Wing wrote:


I hope I'm doing this right...but the resulting program I think looks
correct testing on my Mac. Attached are two pictures.

The first is a simple label in a window.
The second is from your MessageBox line.


Yes, I confirm those two PNG images have that Arabic Peace word rendered
in the correct right-to-left order.

So that settles the question for what I assume is your Mac OS X native
graphics back end.  Can you (or some other IUP developer) do that same
simple test for Linux native graphics (probably GTK+) backend and
native Windows graphics backend?

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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Clifford Yapp]

On Thu, Aug 17, 2017 at 2:27 AM, Eric Wing  wrote:
>> 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.)

If small and self-reliant are the criteria, how does FLTK
(http://www.fltk.org/index.php) stack up?  For something like
cmake-gui it would probably work just fine, and AFAIK it doesn't
require GTK...  it uses LGPLv2 with a static linking exception, so
it's probably as good/better than the current Qt requirement in that
department.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

I hope I'm doing this right...but the resulting program I think looks
correct testing on my Mac. Attached are two pictures.

The first is a simple label in a window.
The second is from your MessageBox line.


Thanks,
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Alan W. Irwin]

On 2017-08-16 23:27-0700 Eric Wing wrote:



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.



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.


Hi Eric:

I knew nothing about UTF-8 and unicode ~10 years ago, but it is
essential developer knowledge that is well worth having (even if you
only have knowledge of one human language, which is my case). 
Furthermore, it is actually quite simple to pick up this unicode and

CTL knowledge these days (compared to a decade ago).  The reason for
that simplicity is for any decent editor such as emacs or vi you can
cut and paste any UTF-8 string right from any website directly into
your source code, and it normally "just works".

So my advice to test your Mac OS backend for CTL capability is instead of the 
simple test case
given at


use instead

#include 
#include 

int main(int argc, char **argv)
{
  IupOpen(, );

  IupMessage("Hello World 1 ﺳﻼم", "Hello world from IUP ﺳﻼم.");

  IupClose();
  return EXIT_SUCCESS;
}

where the only change I have made to the original is I have appended the utf-8 encoded 
"ﺳﻼم" to each of those
IupMessage string arguments.

If your mailer is not unicode or CTL aware so you cannot see that
utf-8 encoded Arabic Peace word in this e-mail, cut and paste that
word from the third word in the line that starts with "Pace" in
 into the two IupMessage string
arguments.

Then build that modified app and see whether the GUI renders that word
in the same character order that word is rendered by your browser for 
.  (Browsers such as firefox and

konqueror are typically the gold standard for being CTL-aware.)

If that rendering is in the correct order (right-to-left) as given by
firefox you have passed this simple CTL support test for
whichever backend you are using.

Also, you can test the CTL capability of cmake-gui (as well as the
cmake application) by using

option("ﺳﻼم" "ﺳﻼم" ON)

in a simple test project where those two utf-8 strings are cut and
pasted from the above "pace" website.  The result of that test here is
the letters in those words are rendered in the same order as in the
above "pace" website both in the GUI (for the cmake-gui case) and in
CMakeCache.txt (for both the cmake and cmake-gui cases).  And, of
course, if/when an IUP-based cmake-gui is developed, the same CTL test
should be applied to that result as well.

Note also, you don't have to limit your tests just to the word
for Peace in Arabic.  For example, there are some good test
words in  that
can be cut and pasted.

Finally, in my last post I stated that it would be bad news for IUP if
any of its backends failed the CTL test, but in retrospect that is too
strong a statement.  For example, if the CTL capabilities of IUP are
fine for GTK+, Windows, and Mac OS X backends, but the Motif backend
(used on commercial Unices) is not capable of CTL, then that only
affects the internationalization capabilities of cmake-gui for a
minority platform (Commercial Unices).  And given that the only bad
result if CTL fails is the characters are rendered in the wrong order
in the cmake-gui GUI display (with the CMakeCache.txt result
completely unaffected), I think that rendering failure in that Motif
corner case would be completely acceptable.  Of course, CTL rendering
failure is a more serious problem if it occurs for any of the majority
platforms (i.e., Linux GTK+, Windows, or Mac OS X). However, I am
pretty sure that CTL should be well supported by IUP on each of those
3 platforms, and if you can confirm that it should be sufficient to
put this CTL support question for IUP immediately to rest.

Alan
__
Alan W. Irwin

Re: [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.)



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

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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Alan W. Irwin]

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

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