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

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

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

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

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

> 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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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`

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

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`

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

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

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

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