Dipping my toes in cross-platform GUI

[Tomás Ó hÉilidhe]

I don't know the first thing about cross-platform GUI programming, so
I'd like to ask a few quick questions.

Which library is best for someone who appreciates portable programming
and correct efficient code, and who'd like the library to fit well with the
C++ Standard Library? Also I'd like the library to work on as many
platforms as possible (Windows, Linux, Mac, and even the new game consoles
such as Playstation 3 and XBox 360 if possible).

I've heard of wxWidgets and Qt, but I haven't a clue what they're like.
I've seen the cross-platform media player, VLAN; it uses wxWidgets and it
looks good. What GUI libraries are all the well-known programs using, such
as Mozilla, Xilinx?

Is there any cross-platform networking library that stands head and
shoulders above the rest?

 

[Victor Bazarov]

I don't know the first thing about cross-platform GUI programming,
so I'd like to ask a few quick questions.

Which library is best for someone who appreciates portable
programming and correct efficient code, and who'd like the library to
fit well with the C++ Standard Library? Also I'd like the library to
work on as many platforms as possible (Windows, Linux, Mac, and even
the new game consoles such as Playstation 3 and XBox 360 if possible).

I've heard of wxWidgets and Qt, but I haven't a clue what they're
like. I've seen the cross-platform media player, VLAN; it uses
wxWidgets and it looks good. What GUI libraries are all the
well-known programs using, such as Mozilla, Xilinx?

Is there any cross-platform networking library that stands head and
shoulders above the rest?

I'll tell you my experience. Take it at its face value.

Any library worth the plastic in the CD it is shipped on is far more
complex than it appears on the surface (even after reading the manual).
To obtain satisfactory results from it would require becoming more or
less proficient if not fluent with it. To achieve desired fluency
with the library you have to spend countless hours designing your
program with and around the concepts implemented in that library. Do
not kid yourself that all libraries that serve similar purpose are
the same. They are close, but the common denominator is the tip of
the iceberg. The differences is what lies beneath. And those are
what will give you trouble and what needs to be comprehended in at
least some detail if you want to learn and use the library properly.

Now, you have your own task at hand -- the application in the problem
domain you're good at. Be it quantum physics or sales order tracking,
you're out to solve that problem, to improve the lives of physicists,
salespeople, accountants, etc. *That* is what you're going to spend
the overwhelming majority of your designing/coding time. Even if it
comes natural to you, you will still need to test, and debug, and to
test again, and document, and plan, and ... You get the picture.

Given that you have your own problem to solve, you simply have NO TIME
to compare several libraries. That's why you've come to Usenet with
your question: what libraries are out there, what's their advantages,
what to look out for, etc. You don't want to try to make the decision
without weighing all the pro and contra. That's wise.

It seems, however, that you think that somebody has done what you do
not have time for, i.e. compared several libraries to arrive at the
conclusion to use a particular one. Nope. Most of us, just like you,
do not have time to compare several of libraries based on *our own*
experience learning and using them. Rarely do we have experience of
programming at the level required for implementing such libraries for
more than one operating system.

Whatever you hope to learn about those libraries is already available
on each libraries' mailing list (trust me, every decent library has
one, and if it doesn't have it, it's not worth spending time reading
about anyway).

Here is what I've seen happen: a young guy without any experience
using any of the popular {UI|Network|WWW|Hardware|...} libraries
comes to a shop where one of them is in use. How did it get chosen?
Somebody might or might not remember. Maybe the guy who convinced
the manager to start using this particular library has already
moved on to new job, who knows... Doesn't really matter. There
are resident experts, from whom the young guy learns the tips and
tricks, the idioms and the quirks. He becomes proficient in using
the library. Then he matures and finds himself wanting to advance
his career. Elsewhere. Where would he look? If he's young
enough, energetic, he might look for something totally different.
He might look for a shop that uses a different library altogether.
He doesn't mind learning another one. Or, maybe he prefers to
keep working in the same problem domain and the other stuff just
doesn't matter much to him.

Will he learn the second library to be able to compare them? Nope.
He'll learn the new library and the first one will fade in his
memory. He could barely remember the names of some classes from
the old library after a couple of years of using the new one. What
is worse, some subtle differences are so subtle (but make sense now
that he's using the library in which they dominate), they make him
think that the other one was organised the same way, thus creating
the illusion that all of them are the same, really. No, really,
they are. Aren't they?...

Here is the advice part of the story. Pick one and learn it. Use
it to the best of your ability; they are all equally capable when
employed properly. If you have doubts about its abilities, you
will have to create an abstraction layer in your own application
to be able to switch to a different library should there be a need
to. That's about twice (or thrice) the work than simply use the
same library without even thinking of switching later. Decide for
yourself, do you have twice or thrice the resources to plan for
a possible switch in the future? Or perhaps it doesn't matter at
all *what* library to use, what matters is that you're using one,
and it provides enough abstraction for your code to carry you over
the troubles of porting your {UI|Network|etc.} functionality to
the next platform.

Of course, if you already know *all* requirements the library has
to meet, then pose the question "does it do <blah>?" to the very
makers of each library to see if it will work for you. If that's
the case, we really can't help you, but folks in the mailing list
(which I may have already mentioned) could.

Good luck!

V

 

[Lionel B]

I'll tell you my experience. Take it at its face value.

[...]

Bravo Victor!

I hereby declare any further discussion on this topic, including future
threads, closed.

 

[Chris Thomasson]

I'll tell you my experience. Take it at its face value.

[...]

Bravo Victor!

I hereby declare any further discussion on this topic, including future
threads, closed.

:^)

 

[James Kanze]

Globally, very well said, and I agree. There is one point,
however:

[...]

Here is the advice part of the story. Pick one and learn it.
Use it to the best of your ability; they are all equally
capable when employed properly.

There are a few particular points which might be relevant, and
that you can learn from a short perusal of the documentation:

-- Qt requires a special pre-processor; you don't write C++,
but something close to C++, which is then pre-processed to
generate the C++. Personally, I find that unacceptable.

-- From what little I've seen of it, wxWidgets seems to take
over main. I don't like that either (but that may be just
one mode of using it---as I said, I've not really learned
it.

From discussion, those two are by far the most widely used (and
being widely used is an advantage in itself). If I needed to do
make a choice rapidly, today, I'd go to the wxWidgets mailing
list, and ask about using it with my own main (in the way I
think a GUI library should be used). I'd also ask about other
things I'm not 100% sure of: support for the standard types, for
example. (wxWidgets pre-dates the ISO standard, and earlier
versions did not use std::string.) Depending on the answers,
I'd either use wxWidgets, or use javax.swing, over Corba.

[...]

Of course, if you already know *all* requirements the library
has to meet, then pose the question "does it do <blah>?" to
the very makers of each library to see if it will work for
you. If that's the case, we really can't help you, but folks
in the mailing list (which I may have already mentioned)
could.

From a pratical point of view, I think you're right. The only
people who know wxWidgets well enough to give detailed answers
are in the wxWidgets mailing list, and not here. The same thing
holds for all of the other libraries.

On the other hand, it's probably worth asking here for
more general recommendations---if, say, all you're really
interested in is usability, and knowing how wide spread the use
is. (A library that is only used in one or two places is likely
to disappear. A library as widely used as wxWidgets or Qt won't
disappear.)

 

[Joe Greer]

I don't know the first thing about cross-platform GUI programming,
so
I'd like to ask a few quick questions.

Which library is best for someone who appreciates portable
programming
and correct efficient code, and who'd like the library to fit well
with the C++ Standard Library? Also I'd like the library to work on as
many platforms as possible (Windows, Linux, Mac, and even the new game
consoles such as Playstation 3 and XBox 360 if possible).

I've heard of wxWidgets and Qt, but I haven't a clue what they're
like.
I've seen the cross-platform media player, VLAN; it uses wxWidgets and
it looks good. What GUI libraries are all the well-known programs
using, such as Mozilla, Xilinx?

Is there any cross-platform networking library that stands head
and
shoulders above the rest?

Victor answered quite well the main thrust of your question, so I
thought I would throw in a few thoughts about portable gui-s in general.
Have you ever noticed that you can generally pick out a java app from a
mile away? The problem is that while they have a wonderful api that is
portable everywhere a compatible JVM exists, they all have a certain
look and feel and that look and feel doesn't quite fit anywhere.

Each of the OS's you mention have certain expectations for the look and
feel of a program. Everything from the location of menu items to how
you browse for files is generally specified in the OS's look and feel
guide. Applications that are targeted toward non-computer people
generally follow the OS's guide unless they have a good reason to
deviate from it.

The mentioned GUI libraries do a wonderful job of making portable
widgets, but are generally less fantastic about whether the actual look
and feel matches the platform the user is running. For certain things,
this is ok, but for others this can be a real pain in the backside of
your users.

So, the advice is that if you really want to do your portability right,
you will strive to separate your business logic from your GUI and
implement things in your GUI such that the look and feel matches user
expectations. Of course, by the time you do this the portable GUI
libraries make less difference. If your application doesn't really have
much of a user interface, then you might get away without this
separation, but at least think about it.

joe

 

[Tomás Ó hÉilidhe]

Here is the advice part of the story. Pick one and learn it. Use
it to the best of your ability; they are all equally capable when
employed properly.

I read what your wrote Victor, and it was helpful. Not to sound naive
though... but could someone just throw a library name at me? I don't need a
review of the library, just even "You'll be on the right track if you go
with X". Right now I'm thinking of going with wxWidgets.

 

[Victor Bazarov]

I read what your wrote Victor, and it was helpful. Not to sound
naive though... but could someone just throw a library name at me? I
don't need a review of the library, just even "You'll be on the right
track if you go with X". Right now I'm thinking of going with
wxWidgets.

James mentioned Qt and wxWidgets. Go to their sites and look at
their capabilities. Perhaps they even list some comparative
advantages of one over the other. I've used Qt, I've not used
wxWidgets. If I were to create another GUI app to target more
than one platform, that's what I'd use. But it's not because Qt
is objectively better, it's because I have some experience with
Qt and it *did the job*. I simply don't want to waste time to
learn another library that does pretty much the same thing.

Again, I am not speaking in favor of one or the other; you've asked
to throw a name at you, so here.

V

 

[Tomás Ó hÉilidhe]

James mentioned Qt and wxWidgets. Go to their sites and look at
their capabilities.

I started using wxWidgets about an hour ago and I'm already making great
progress... the interface couldn't be easier! Plus I love its class
structure, makes it very easy to do stuff :-D

 

[Erik Wikström]

Victor answered quite well the main thrust of your question, so I
thought I would throw in a few thoughts about portable gui-s in general.
Have you ever noticed that you can generally pick out a java app from a
mile away? The problem is that while they have a wonderful api that is
portable everywhere a compatible JVM exists, they all have a certain
look and feel and that look and feel doesn't quite fit anywhere.

Each of the OS's you mention have certain expectations for the look and
feel of a program. Everything from the location of menu items to how
you browse for files is generally specified in the OS's look and feel
guide. Applications that are targeted toward non-computer people
generally follow the OS's guide unless they have a good reason to
deviate from it.

The mentioned GUI libraries do a wonderful job of making portable
widgets, but are generally less fantastic about whether the actual look
and feel matches the platform the user is running. For certain things,
this is ok, but for others this can be a real pain in the backside of
your users.

I would like to disagree, at least with Qt you can make applications
that looks and feels like native applications (at least for Unix and
Windows, I have never targeted Mac). The problem is that since the look
and feel differs between different systems there are some occasions
where it is not enough to have the right look and feel on the individual
widgets, it is a question about overall layout. In these cases you have
to choose one system and let the others be what they become since the
alternative is to have different layouts for each system (which in most
cases is overkill).

 

[Joe Greer]

I would like to disagree, at least with Qt you can make applications
that looks and feels like native applications (at least for Unix and
Windows, I have never targeted Mac). The problem is that since the
look and feel differs between different systems there are some
occasions where it is not enough to have the right look and feel on
the individual widgets, it is a question about overall layout. In
these cases you have to choose one system and let the others be what
they become since the alternative is to have different layouts for
each system (which in most cases is overkill).

You disagree and yet your arguments line up with what I said. I am confused.
To what exactly are you disagreeing?

joe

 

[Erik Wikström]

You disagree and yet your arguments line up with what I said. I am confused.
To what exactly are you disagreeing?

My point was that they can match the look and feel of a platform, but
seldom more than one. It might have been what you were saying but the
way I read your post you were saying that they can not get the look and
feel right on any platform.

 

[Joe Greer]

My point was that they can match the look and feel of a platform, but
seldom more than one. It might have been what you were saying but the
way I read your post you were saying that they can not get the look
and feel right on any platform.

Ahhhh. No, I wasn't trying to say that. What I was trying to say is that it is hard to get
the look and feel right on every platform. Usually the program looks good on the platform
it is developed on, and just a little out of place everywhere else.


joe

 

[Victor Bazarov]

Ahhhh. No, I wasn't trying to say that. What I was trying to say is
that it is hard to get the look and feel right on every platform.
Usually the program looks good on the platform it is developed on,
and just a little out of place everywhere else.

I think you hit very close to the bullseye. IME, the program looks
good on the platform where the portable GUI library originated.

V

 

[suresh]

I don't know the first thing about cross-platform GUI programming, so
I'd like to ask a few quick questions.

Which library is best for someone who appreciates portable programming
and correct efficient code, and who'd like the library to fit well with the
C++ Standard Library? Also I'd like the library to work on as many
platforms as possible (Windows, Linux, Mac, and even the new game consoles
such as Playstation 3 and XBox 360 if possible).

I've heard of wxWidgets and Qt, but I haven't a clue what they're like..
I've seen the cross-platform media player, VLAN; it uses wxWidgets and it
looks good. What GUI libraries are all the well-known programs using, such
as Mozilla, Xilinx?

Is there any cross-platform networking library that stands head and
shoulders above the rest?

Why not Gtkmm (site: http://www.gtkmm.org/ a C++ wrapper over GTK)? It
is purely an GUI library - nothing more, nothing less. Whereas
wxWidgets and Qt are not JUST gui libraries. They have xml parsing
code (it is very basic with SAX and DOM interfaces don't support
Schemas or XSLT - hence I recommend to use Xerces or libxml2 for your
xml code instead of Qt's xml library), networking api, database api
(for Qt) and even Vectors, Lists, Maps their own String classes (like
QString in Qt). Why do you as a these with your gui library. There are
excellent Boost libraries (or open source libraries) to do most of
these in a very better way. No pointing in learning these again. If
you are only interested in GUI application, Gtkmm is a clean api. It
works fine on Windows and excellent on Linux (and UNIX systems like
Solaris, FreeBSD) - I am not sure how it look on Mac.
Glade library (http://glade.gnome.org/) can even make things better.
It generates Glade XML which can be used in C, C++, Python or even in
Java (From their site: By using libglade, Glade XML files can be used
in numerous programming languages including C, C++, Java, Perl,
Python, C#, Pike, Ruby, Haskell, Objective Caml and Scheme. Adding
support for other languages is easy too.), making Gtk not only a cross-
platform UI library but even language independent.
Tomorrow if you want to migrate your C++ project to Java (or Python),
no need to do anything with your Glade XML UI - it is already
portable.

I recommend to have a look at Gtkmm and Glade.