Portable library to create GUI intefaces ?

[Timothy Madden]

Hello

What would be a good library to create a graphical user interface
application ?

I would like a portable free library (to run on Windows and Linux), and I
would like to provide a native interface on each OS (I mean on Win32 the
application looks like an Win32 application, and on Linux it looks like an X
application)


I know about GTK and wxWidgets, and maybe Qt, but I am not sure they will
meet my needs (free, portable, native), and I guess they need some C++
wrapper library, and also I find them not-so-easy to install. GTK has many
dependencies, and Qt might not be really free on Windows.

Sorry if this is off-topic, a suggestion for a better newsgroup would be
welcome.

Thank you,
Timothy Madden

 

[Jorgen Grahn]

I've yet to see a portable library that looks and feels native on all
supported platforms.

But I bet you have, like me, heard people cry for them for 15 years or
more. (And heard others announce that they have made one and that it
will surely Take Over The World.)

Even the ones that use native widgets tend to
feel a bit "off."

Yes. Even small details like a brief flickering during screen refresh
or a 0.1s extra input latency will make an application feel alien or
odd.

A better idea IMHO is to use an MVC design, with portable Model and
Model Controller classes, and a set of platform-specific View and View
Controller classes for each supported platform.

I think I'd concentrate on one of them first and release my program
there, and /then/ think about further directions. I have the feeling
that many people who say they want to run on "Windows and Linux" mean
they're really primarily interested in one of them, but would like the
other if they can get it virtually for free.

(Not that have any experience of this. I have the luxury of supporting
Unix exclusively, and I have never had to include a GUI in my
designs.)

/Jorgen

 

[Jonathan Lee]

What would be a good library to create a graphical user interface
application ?

I'd vote for Qt. I use it on Windows and Linux in C++.

I would like a portable free library (to run on Windows and Linux),

Qt has GPL and LGPL: http://qt.nokia.com/products/licensing/

and I would like to provide a native interface on each OS
http://doc.qt.nokia.com/4.6/gallery.html

I guess they need some C++ wrapper library

Qt doesn't.

and also I find them not-so-easy to install.

Grab the SDK and Qt-Creator. Not much more difficult than
Visual Studio to install.

--Jonathan

 

[Alf P. Steinbach /Usenet]

* Jorgen Grahn, on 17.07.2010 21:26:

But I bet you have, like me, heard people cry for them for 15 years or
more. (And heard others announce that they have made one and that it
will surely Take Over The World.)


Yes. Even small details like a brief flickering during screen refresh
or a 0.1s extra input latency will make an application feel alien or
odd.

This applies to Windows Explorer, Microsoft's GUI shell for Windows. ;-)

But I agree, it shouldn't be there.

One shouldn't have to pay such abstraction costs.


[snip]

Cheers,

- Alf

 

[Balog Pal]

I've yet to see a portable library that looks and feels native on all
supported platforms. Even the ones that use native widgets tend to
feel a bit "off."

A better idea IMHO is to use an MVC design, with portable Model and
Model Controller classes, and a set of platform-specific View and View
Controller classes for each supported platform.

Yeah, I'd probably walk that route. With good MVC separation the interface
can be created in the most native ways using the same model code. Then on
windows you can use any of the proven frameworks (you can even write it in
..NET/C# or something instead of C++...). And use some native unix library.

From the original list, definitely avoid GTK like a plague.

 

[Öö Tiib]

What would be a good library to create a graphical user interface
application ?

Most important is to create application logic that does at least one
useful operation better than anything else (better is subjective, so
better for at least one person on our planet). Best first user
interface is command line and if graphics are part of output, then
portable forms like .png are good first choice.

I would like a portable free library (to run on Windows and Linux), and I
would like to provide a native interface on each OS (I mean on Win32 the
application looks like an Win32 application, and on Linux it looks like an X
application)

That is worth to consider when you have command line application
working. Command line application is most easy to enhance with any GUI
front end.

I know about GTK and wxWidgets, and maybe Qt, but I am not sure they will
meet my needs (free, portable, native), and I guess they need some C++
wrapper library, and also I find them not-so-easy to install. GTK has many
dependencies, and Qt might not be really free on Windows.

With every one of these there are some trouble and you never know when
something new and groundbreaking jumps out. Keep your application
logic separate from any GUI. Keep command line always useful in
parallel. It makes your modules testable by script. If nothing else
then someone may want such well-separated piece as part of their
larger application.

At the moment i would pick QT (simple and robust and looks ok,
slightly slow at places). It may change. If you have enough funds then
make GUI separately for each platform using developers who are fans of
the platforms. Having web service (so user interface is web browser)
is also very nice option but part of it has to be javascripted then.

 

[Jorgen Grahn]

.

From the original list, definitely avoid GTK like a plague.

It's hard to consider such advice without a motivation. Why?

/Jorgen

 

[Öö Tiib]

On Sun, 2010-07-18, Balog Pal wrote:

...


It's hard to consider such advice without a motivation. Why?

GTK/Glib is C GUI and somewhat intrusive with its C style
objectorientedness. It is written with GIMP as target product. If what
you write is not GIMP-like it may produce seriously inefficient
results too. I do not agree with "like plague" assessment however ...
it works, it may be used commercially and it is well tested.

 

[Balog Pal]

It's hard to consider such advice without a motivation. Why?

Well, I used mainly MFC in the past, starting with its very first version.
Probably common knowledge that it has a long list of problems and dislikes.
(Most picked up as legacy from 1.0 that unfortunately was not just
replaced...)

In the current project we use GTK. In comparision it is like a nightmare.

I would think if someone starts a new framework at least takes a few moments
to learn about existion ones and select the good elements -- and avoiding
the known pitfalls. It is not so.

On top of that it is done the wrong way around -- a C fabriation that
imitates C++, and then that monster is wrapped in C++ classes, certainly
leaking all around, and injecting surprizes like you can't send an exception
from frame #100 in your backtrace to frame #50, as between are some C parts
swallowing it...

 

[Jorgen Grahn]

Well, I used mainly MFC in the past, starting with its very first version.
Probably common knowledge that it has a long list of problems and dislikes.
(Most picked up as legacy from 1.0 that unfortunately was not just
replaced...)

In the current project we use GTK. In comparision it is like a nightmare.

Not a motivation -- but at least a testimony.

I would think if someone starts a new framework at least takes a few moments
to learn about existion ones and select the good elements -- and avoiding
the known pitfalls. It is not so.

As I understand it, GTK was written because the GIMP developers were
frustrated with Motif. But GUI toolkits seem extremely hard to do
right. I'm happy I rarely have to touch them.

On top of that it is done the wrong way around -- a C fabriation that
imitates C++, and then that monster is wrapped in C++ classes,

It depends on what it imitates (I really hate C frameworks which
implement run-time polymorphism, heap allocation of everything and
weak typing, and try to patch it up with macros) but you cannot expect
a major Unix GUI toolkit to be written in C++. To survive there you
need to have a C API as the main API.

certainly
leaking all around, and injecting surprizes like you can't send an exception
from frame #100 in your backtrace to frame #50, as between are some C parts
swallowing it...

Sounds as a direct consequence of the preceding point.

(I'm not defending GTK, or saying what you write isn't useful -- but
the motivation is still not there. Of course, you have a right to say
"I use Foo and find it horrible" without following up with a detailed
and fair analysis.)

/Jorgen

 

[Miles Bader]

(I'm not defending GTK, or saying what you write isn't useful -- but
the motivation is still not there. Of course, you have a right to say
"I use Foo and find it horrible" without following up with a detailed
and fair analysis.)

The original whine seems kind of overwrought...

I've done a bit of GTK programming (in C), and it seemed reasonable
enough. Maybe there are subtle annoyances that show up with heavy use,
but it's hardly the complete train-wreck he seems to be suggesting.

I suppose the "OO-in-plain-C" goop is likely to rub the more extreme C++
partisans the wrong way, but it's hardly the worst thing in the world,
and there are good reasons for it.

-Miles