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

[Justin Berger]

I think asio being on track to be included in the standard library is a
strong point in its favor, but in my opinion there are two strong reasons
to prefer libuv:

- libuv is entirely a C library. I don't think this is a hard requirement
but most of kwsys is C and I suspect there is a reason for this; although
maybe it's entirely historical.
- asio is header only; and a lot of headers at that. With essentially
identical functionality, I don't think it makes sense to take the build
time hit; which as far as I can tell is substantial.

If/when ASIO gets into the standard, I think it'd make sense to re-evaluate
that, but we are a long time away from that, and even when it gets into the
standard it'll take a maddeningly long time for that standard to be
properly supported for all the supported platforms for cmake.

- Justin

On Thu, Aug 17, 2017 at 6:46 AM, Ben Boeckel 
wrote:

> On Wed, Aug 16, 2017 at 23:02:52 +0200, Jean-Michaël Celerier wrote:
> > @Ben Boeckel :
> > > The idea for process creation is to migrate to libuv once all of the
> > dependencies are supported.
> > Quick question : why not asio instead ? it's bound to end up in the
> > standard library at some point (e.g.
> > https://github.com/chriskohlhoff/networking-ts-impl) and already has an
> > event loop.
>
> CMake uses curl for networking (all sync), but libuv was added for the
> server mode's event loop. It also comes with process execution, some
> filesystem helpers and other things that kwsys does today that we can
> drop once we move to it. AFAICT, asio looks like it's mostly a
> networking library and doesn't overlap well with libuv and CMake's
> requirements.
>
> > Or even Qt's event loop since it's already here.
>
> Qt isn't required by core CMake, just cmake-gui.
>
> --Ben
> --
>
> 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
>
-- 

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

[Ben Boeckel]

On Wed, Aug 16, 2017 at 23:02:52 +0200, Jean-Michaël Celerier wrote:
> @Ben Boeckel :
> > The idea for process creation is to migrate to libuv once all of the
> dependencies are supported.
> Quick question : why not asio instead ? it's bound to end up in the
> standard library at some point (e.g.
> https://github.com/chriskohlhoff/networking-ts-impl) and already has an
> event loop.

CMake uses curl for networking (all sync), but libuv was added for the
server mode's event loop. It also comes with process execution, some
filesystem helpers and other things that kwsys does today that we can
drop once we move to it. AFAICT, asio looks like it's mostly a
networking library and doesn't overlap well with libuv and CMake's
requirements.

> Or even Qt's event loop since it's already here.

Qt isn't required by core CMake, just cmake-gui.

--Ben
-- 

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

[Simon Lees]

On 17/08/17 19:53, Alan W. Irwin wrote:
> On 2017-08-17 19:29+0930 Simon Lees wrote:
> 
>>
>>
>> On 17/08/17 19:01, Jean-Michaël Celerier wrote:
 And Mac doesn't have configure/autotools by defaul.
>>>
>>> but... "configure" has nothing to do with autotools.
>>> It's just a shell script (which is sometimes generated *from* autotools;
>>> this is not the case with Qt AFAIK).
>>>
>>
>> Yes Qt's configure is a stand alone script unrelated to autotools. Qt
>> uses its own build system thats shipped with it.
> 
> I can confirm that.  Also, I have built Qt5 a couple of times, and I
> was not particularly happy with the regidity of their build system
> when attempting to drop components I was not using.  And I was also
> not happy with how the options for that configuration script changed
> so drastically from one Qt5 version to the next. So it is always a
> big disappointment to me that Qt5 does not have a flexible,
> user-friendly CMake-based build system following what the KDE
> developers have done for years.
> 
> So this is another "minor" project for Alex.  :-)
> 
The way we tended to handle that at my previous job was to build almost
everything (except the slow stuff like web) then only ship to our
customers the libs we actually used.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
-- 

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

[Alan W. Irwin]

On 2017-08-17 19:29+0930 Simon Lees wrote:




On 17/08/17 19:01, Jean-Michaël Celerier wrote:

And Mac doesn't have configure/autotools by defaul.


but... "configure" has nothing to do with autotools.
It's just a shell script (which is sometimes generated *from* autotools;
this is not the case with Qt AFAIK).



Yes Qt's configure is a stand alone script unrelated to autotools. Qt
uses its own build system thats shipped with it.


I can confirm that.  Also, I have built Qt5 a couple of times, and I
was not particularly happy with the regidity of their build system
when attempting to drop components I was not using.  And I was also
not happy with how the options for that configuration script changed
so drastically from one Qt5 version to the next. So it is always a
big disappointment to me that Qt5 does not have a flexible,
user-friendly CMake-based build system following what the KDE
developers have done for years.

So this is another "minor" project for Alex.  :-)

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

[Simon Lees]

On 17/08/17 19:01, Jean-Michaël Celerier wrote:
>> And Mac doesn't have configure/autotools by defaul.
> 
> but... "configure" has nothing to do with autotools.
> It's just a shell script (which is sometimes generated *from* autotools;
> this is not the case with Qt AFAIK).
> 

Yes Qt's configure is a stand alone script unrelated to autotools. Qt
uses its own build system thats shipped with it.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
-- 

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

[Jean-Michaël Celerier]

> For example, I've seen way too many
projects screw up with Brew because they fail to ship a binary that
can work on a clean user system who is not going to install Brew.

I must be lucky then, because just using macdeployqt copies all the
dependencies for me and
updates all the install paths correctly whether I use Qt's own build or
brew's.

> It pulls a new version of gcc instead of using Xcode/clang on
your system and builds an entire dependency chain based on GNU tools.

this is false. brew uses xcode & clang on your system.

> Similar problem for Windows...Visual Studio is the requirement.

I don't know if you are talking about Chocolatey or Qt but neither require
Visual Studio on windows.
Qt even comes with MinGW if you wish.

> And Mac doesn't have configure/autotools by defaul.

but... "configure" has nothing to do with autotools.
It's just a shell script (which is sometimes generated *from* autotools;
this is not the case with Qt AFAIK).

> and I never figured why Qt's RAM consumption footprint is so high...based
on all the DLL binary code it
has to load, or something more intrinsic to its implementation.

science can help us here :p two tools are very nice for this :

* bloaty mcbloatface for binary bloat

for file in /usr/lib/libQt5*.so ; do (echo $file; bloaty $file| grep
-A3 'text') ; done

tells us stuff like

/usr/lib/libQt5Core.so
  55.4%  2.75Mi .text  2.75Mi  55.5%
  23.5%  1.16Mi .rodata1.16Mi  23.5%
   7.3%   372Ki .eh_frame   372Ki   7.4%
   4.1%   210Ki .dynstr 210Ki   4.2%
/usr/lib/libQt5Gui.so
  70.0%  3.82Mi .text   3.82Mi  70.2%
   7.8%   438Ki .eh_frame438Ki   7.9%
   6.1%   342Ki .dynstr  342Ki   6.1%
   5.1%   286Ki .rodata  286Ki   5.1%

A bit surprising to see .eh_frame; I thought Qt was compiled with
-fno-exceptions but maybe that's just my distro.
Quite a bunch of .rodata in Qt5Core too, I wonder why.
Further examination through
readelf -x .rodata /usr/lib/libQt5Core.so | less
seems to show up a lot of locale-specific calendar text & such, e.g. names
of the months in twenty languages, currencies, time zones, etc

* And then, runtime examination: for this I tried making a minimal gui
program:
#include 
#include 
int main(int argc, char**argv)
{
  QApplication app(argc, argv);
  QMainWindow w;
  w.show();
  return app.exec();
}

compiled with
g++ -DQT_NO_DEBUG -fPIC -I/usr/include/qt/ -I/usr/include/qt/QtCore
-I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui main.cpp -lQt5Core
-lQt5Widgets

and then use the wonderful Heaptrack (https://github.com/KDE/heaptrack) :

heaptrack ./a.out

which then greets us with http://imgur.com/a/eYjaL

As you can see, "peak heap memory consumption" is at a bit less than 400
*kilobytes*. So the Qt memory usage that you see is clearly due only to
binary bloat.
And indeed (sorry for shitty bash skills):

$ ldd a.out | cut -d '=' -f1 | awk '{print "/usr/lib/" $1;}'  | xargs
readlink |  awk '{print "/usr/lib/" $1;}'  | xargs du -csh  | sort -h
16K/usr/lib/libdl-2.25.so
16K/usr/lib/libXau.so.6.0.0
24K/usr/lib/libXdmcp.so.6.0.0
32K/usr/lib/librt-2.25.so
64K/usr/lib/libdouble-conversion.so.1.0.0
68K/usr/lib/libbz2.so.1.0.6
72K/usr/lib/libGLX.so.0.0.0
72K/usr/lib/libXext.so.6.4.0
80K/usr/lib/liblz4.so.1.7.5
84K/usr/lib/libgpg-error.so.0.22.0
92K/usr/lib/libz.so.1.2.11
144K/usr/lib/libpthread-2.25.so
152K/usr/lib/liblzma.so.5.2.3
164K/usr/lib/libxcb.so.1.1.0
176K/usr/lib/libgraphite2.so.3.0.1
216K/usr/lib/libpng16.so.16.31.0
444K/usr/lib/libpcre2-16.so.0.5.0
460K/usr/lib/libpcre.so.1.2.9
536K/usr/lib/libsystemd.so.0.19.0
548K/usr/lib/libharfbuzz.so.0.10400.5
552K/usr/lib/libGL.so.1.0.0
600K/usr/lib/libGLdispatch.so.0.0.0
796K/usr/lib/libfreetype.so.6.14.0
1,1M/usr/lib/libglib-2.0.so.0.5200.3
1,1M/usr/lib/libm-2.25.so
1,2M/usr/lib/libgcrypt.so.20.2.0
1,3M/usr/lib/libX11.so.6.3.0
1,7M/usr/lib/libicuuc.so.59.1
1,9M/usr/lib/libc-2.25.so
2,5M/usr/lib/libicui18n.so.59.1
5,0M/usr/lib/libQt5Core.so.5.9.1
5,5M/usr/lib/libQt5Gui.so.5.9.1
6,4M/usr/lib/libQt5Widgets.so.5.9.1
12M/usr/lib/libstdc++.so.6.0.24
26M/usr/lib/libicudata.so.59.1
69Mtotal

So there's 17 megabytes of Qt in here; hopefully the rest would already be
loaded by your system.

Best,
Jean-Michaël

On Thu, Aug 17, 2017 at 3:34 AM, Eric Wing  wrote:

> On 8/16/17, Jean-Michaël Celerier  wrote:
> > @Eric Wing
> >> 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).
> >
> > Really ? On mac it's just brew install qt. On windows 

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 

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

[Eric Wing]

> How easy is it to ship binaries which work on any platform without also
> shipping all of the necessary platform backends as well?

So on Windows and Mac, there is only one backend, the native one. And
so there is nothing to manage.

On the remaining Unix's with IUP you pick one when you build it.
Usually GTK3 or GTK2. As far as I know, the GTK ABI itself is stable
(everything is C which also helps), so on something like Linux, the
only issue is the usual how do you deal glibc and your own
dependencies. My typical approach is build on old distro like Ubuntu
12.04LTS, though I've been moving to Steam-Runtime since they actually
care about ABI stability.


> There's already a JSON library in CMake: jsoncpp.

Even better.

> The idea for process creation is to migrate to libuv once all of the
> dependencies are supported. Looking at the implementation here it
> is…naïve at best. It uses `sh -c` instead of `exec` to do its work which
> means that CMake would need to do manual pipe management anyways.

As I've said, there are tons of different ones. And I've even written
my own. Wrapping Unix fork/exec and Windows CreateProcess is a known
quantity so I'm just suggesting it doesn't need a massive library
dependency to accomplish.

-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

[Eric Wing]

On 8/16/17, Jean-Michaël Celerier  wrote:
> @Eric Wing
>> 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).
>
> Really ? On mac it's just brew install qt. On windows choco install qt-sdk
> (and it even comes with mingw so that you don't necessarily have to install
> visual studio).
> On Raspberry sudo apt-get install qtbase5-dev.
>

So 3rd party package systems are banned for me. They cause too many
dependency problems themselves. For example, I've seen way too many
projects screw up with Brew because they fail to ship a binary that
can work on a clean user system who is not going to install Brew.
Also, it causes needless redundancy and changes the toolset if I
recall. It pulls a new version of gcc instead of using Xcode/clang on
your system and builds an entire dependency chain based on GNU tools.
Similar problem for Windows...Visual Studio is the requirement.

As for Pi, I think the problem I had was the Qt available in the repo
at the time was too old for me. (Typical Debian long release cycle
problem.)

But I still consider it a problem if these things are too hard to
build because (especially for me) there is always a new platform that
needs to be ported to.


> Building qt itself is a matter of doing (cue errors from typing in a mail
> without checking)
>
> git clone https://github.com/qt/qt5
> cd qt5 ; git submodule update --init qtbase ... # whatever submodules you
> need
> ./configure -open-source -confirm-license -nomake tests -nomake examples
> -prefix /opt/my-qt
> make -j8 && make install
>

My last experience was that there were critical bugs in the Qt Mac
release at the time (and this was the official binary release). And
Mac doesn't have configure/autotools by defaul. Again...no brew for
various reasons like above.

>
> Maybe consider a LTCG build (-ltcg) if this really matters ? This way I can
> get a moderately complex GUI app that uses gui, widgets, network, qml,
> etc...
> under ten megabytes, so something like cmake-gui should be way smaller...
> (this also removes any problem related to DLLs).

I wouldn't be able to say. And I never figured why Qt's RAM
consumption footprint is so high...based on all the DLL binary code it
has to load, or something more intrinsic to its implementation.


-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

[David Cole via cmake-developers]

This is great to see CMake continuing to evolve like this!

What's next, a web page CMake UI connected to cmake server instances
on multiple platforms? ;-)



On Wed, Aug 16, 2017 at 6:05 PM, Daniel Pfeifer  wrote:
> On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing  wrote:
>>
>> On 8/15/17, Daniel Pfeifer  wrote:
>> > Hi,
>> >
>> > With !977 merged, it is possible to base ccmake and cmake-gui on top of
>> > the
>> > cmake server.
>> > For demonstration, I copied the contents of the Source/CursesDialog
>> > directory and added a proxy implementation of the classes `cmake` and
>> > `cmState`. The result is 100% compatible with `ccmake`. The same would
>> > be
>> > possible with cmake-gui.
>> >
>> > Shall we proceed in this direction?
>> >
>> > To make the server available everywhere, we should backport the code
>> > from
>> > C++14 to C++11. I think this is limited to replacing `std::make_shared`.
>> >
>> > For cmake-gui, the proxies could use Qt functionality (QProcess,
>> > QJsonDocument, etc.). As a result, cmake-gui would not have any build
>> > dependencies apart from Qt.
>> >
>> > It might be worth considering to move ccmake and cmake-gui to their own
>> > repositories.
>> >
>> > Cheers, Daniel
>> >
>>
>> If this is a new rewrite...
>
>
> It is not. Both ccmake and cmake-gui use the use the `cmake` class as a
> facade to the cmakelib.
> In my prototype I re-implemented the `cmake` class as a client to the
> cmake-server using json-cpp and libuv.
> This allows separating ccmake and cmake-gui from the cmakelib without
> further changes to the rest of the code.
>
> The same client implementation might be used for ccmake and cmake-gui, but
> cmake-gui might as well use Qt facilities instead.
>
>> 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.
>
>
> Sounds interesting.
>
>> 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
>
>
> That would not be necessary. A cache editor build on IUP could use the same
> cmake client implementation as ccmake.
>
>> 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.
>>
>>
>> Anyway, I know this is going to be outside peoples' comfort-zone which
>> is why I'm not going to push hard on it. But in general, I would like
>> something smaller, easier to build, and lighter on system resources
>> (and real native GUIs generally provide a better user experience). So
>> I'm hoping 

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

[Ben Boeckel]

On Wed, Aug 16, 2017 at 09:16:24 -0700, Eric Wing wrote:
> 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.

How easy is it to ship binaries which work on any platform without also
shipping all of the necessary platform backends as well?

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

There's already a JSON library in CMake: jsoncpp.

> 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

The idea for process creation is to migrate to libuv once all of the
dependencies are supported. Looking at the implementation here it
is…naïve at best. It uses `sh -c` instead of `exec` to do its work which
means that CMake would need to do manual pipe management anyways.

--Ben
-- 

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

[Eric Wing]

On 8/15/17, Daniel Pfeifer  wrote:
> Hi,
>
> With !977 merged, it is possible to base ccmake and cmake-gui on top of the
> cmake server.
> For demonstration, I copied the contents of the Source/CursesDialog
> directory and added a proxy implementation of the classes `cmake` and
> `cmState`. The result is 100% compatible with `ccmake`. The same would be
> possible with cmake-gui.
>
> Shall we proceed in this direction?
>
> To make the server available everywhere, we should backport the code from
> C++14 to C++11. I think this is limited to replacing `std::make_shared`.
>
> For cmake-gui, the proxies could use Qt functionality (QProcess,
> QJsonDocument, etc.). As a result, cmake-gui would not have any build
> dependencies apart from Qt.
>
> It might be worth considering to move ccmake and cmake-gui to their own
> repositories.
>
> Cheers, Daniel
>

If this is a new rewrite...
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.


Anyway, I know this is going to be outside peoples' comfort-zone which
is why I'm not going to push hard on it. But in general, I would like
something smaller, easier to build, and lighter on system resources
(and real native GUIs generally provide a better user experience). So
I'm hoping to at least get you thinking about that irrespective of any
particular framework. And if there is interest in IUP, I'm happy to
discuss more or help.

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

[Brad King]

On 08/15/2017 04:33 PM, Daniel Pfeifer wrote:
> With !977 merged, it is possible to base ccmake and cmake-gui on top
> of the cmake serverShall we proceed in this direction?

Yes!  That will be a nice separation.  It will also reduce the number
of places we have to set up `class cmake` instances in the code.

Thanks,
-Brad
-- 

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

[Ben Boeckel]

On Tue, Aug 15, 2017 at 22:33:04 +0200, Daniel Pfeifer wrote:
> With !977 merged, it is possible to base ccmake and cmake-gui on top of the
> cmake server.
> For demonstration, I copied the contents of the Source/CursesDialog
> directory and added a proxy implementation of the classes `cmake` and
> `cmState`. The result is 100% compatible with `ccmake`. The same would be
> possible with cmake-gui.

Well, not sure that I want *100%* compatible with ccmake if we're
rewriting bits of it; there are lots of improvements that could be made
;) .

> To make the server available everywhere, we should backport the code from
> C++14 to C++11. I think this is limited to replacing `std::make_shared`.

The make_shared function is there, but make_unique is missing in C++11.

--Ben
-- 

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

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

[Daniel Pfeifer]

Hi,

With !977 merged, it is possible to base ccmake and cmake-gui on top of the
cmake server.
For demonstration, I copied the contents of the Source/CursesDialog
directory and added a proxy implementation of the classes `cmake` and
`cmState`. The result is 100% compatible with `ccmake`. The same would be
possible with cmake-gui.

Shall we proceed in this direction?

To make the server available everywhere, we should backport the code from
C++14 to C++11. I think this is limited to replacing `std::make_shared`.

For cmake-gui, the proxies could use Qt functionality (QProcess,
QJsonDocument, etc.). As a result, cmake-gui would not have any build
dependencies apart from Qt.

It might be worth considering to move ccmake and cmake-gui to their own
repositories.

Cheers, Daniel
-- 

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