Portable C++ GUI framework

[R.A. Nagy]

What I would suggest doing instead is using an MVC design - quite
common among GUI apps - with the model classes written in portable
C++. I'd write the views and controllers using whatever native kit is
appropriate for each platform.

Anyone have any success stories on writing universally portable C++ GUI for
the "big 3"? (Mac, Win32, POSIX?)

((Lots of games use C++ to pwine the MAC / WIN32 GUI target ...))

Here again, why not leverage Java UI components for a baseline... They go
everywhere. JNI could make it work over / under C -> C++ ...

..01 ends

R.A. Nagy
http://Soft9000.com

 

[R.A. Nagy]

I have had some experience with wxWidgets.

Didja ever get a chance to test it all on WIN32, Linux, and OS X?

Thanks,

R.A. Nagy
http://www.Soft9000.com

 

[R.A. Nagy]

He he, what do you think provides the OS glue for the Java GUI classes?

Yes ... I know...

Infuriating, isn't it?

;-)

wxWidgets runs on all three platforms with, I believe, native look & feel.

I have been contemplating using wxWidgets - Just wish we C++ guys had a good
GUI designer for ANY cross-platform widget set - Tired of seeing people fail
to do as well as my ol' faithfull C++Builder ... (And I believe that
C++Builder 6 used Qt to hit the Linux platform (CLX) - Would take SO LITTLE
to make it all work on Mac... but more of a license problem, than a tech
one...)

Maybe I will write a GUI designer in Java, and make it spit out *ONLY* C++?

:-]

Thanks,

R.A. Nagy
http://SaintBook.org

 

[James Kanze]

Yup. But to me the C++ API of GTKmm is a lot cleaner.

I said more popular, not cleaner. I'm not familiar with
other GUI frameworks, and I don't really know the original
poster's needs or desires, so I didn't want to say more. My own
(admittedly limited) contact with wxWidgets left a negative
taste in my mouth---possibly because it was a complete
framework, and not just a library. (I refuse to use anything
which uses a pre-processor to C++, requiring me to write in
another language, and I definitely don't like anything which
takes over main for me.)

For Example, wxWidgets uses some sort of macro processing for
coupling of widgets with callbacks (which somehow reminds me
on MFC), whereas GTKmm uses signals (like libsigc++ or
boost::signal).

And Java's Swing isn't that bad, and doesn't use any of those
solutions. What's wrong with the classical event notification
pattern?

 

[Matthias Buelow]

My own (admittedly limited) contact with wxWidgets
... (I refuse to use anything
which uses a pre-processor to C++, requiring me to write in
another language, and I definitely don't like anything which
takes over main for me.)

You mean Qt? WxWidgets doesn't use a preprocessor (well, apart from cpp,
of course.)

 

[Michael Oswald]

And Java's Swing isn't that bad, and doesn't use any of those
solutions. What's wrong with the classical event notification
pattern?

Well, I can't say much about Java Swing, I haven't programmed with it
(just used some applications with it) and Java itself is far down on my
list of programming languages which I like.

For this event-notification pattern: I don't like macro solutions here.
As said in another post, I often work with ILOG views, which uses some
macro solutions for various tasks. When switching to another (more
standard-conform) compiler, the macros didn't compile in cases with
class templates because of a rather simple syntax error which didn't
bother the old compiler but the new one. I found no solution to fix
these macros so I ended up preprocessing the files with cpp, deleting
the macros in the source and replacing them with the part from the
preprocessed file. And this in about 30 files in a project with a really
shitty build-system which needed some trickery to get the preprocessor
output.

The approach with signals/slots looks more attractive to me and it's
easier to change connections at runtime if needed.



lg,
Michael

 

[Matthias Buelow]

Yes, it uses native widgets. It's got the "look" pretty close. But a
native interface, at least on the Mac, is more than that.

Enough of that Mac snobbery! If you think people are gonna rewrite
everything just for the Mac because you don't quite like a shade of an
icon you can eat your one-button mouse.

Seriously, for many applications cross-platform toolkits are a nice
thing and a Mac user surely prefers a "close enough" GUI to one that
hasn't been ported to the Mac at all.

 

[R.A. Nagy]

I could go on, but this isn't really about C++, so I'll stop here.

Personally I found this *very* enlightening. Mac is on my "to-do" list for
the next set of cross-platform C++ targets.

I wonder if Qt is any more "maceeey"?

Thanks!

R.A. Nagy
http://www.Soft9000.com

 

[James Kanze]

You mean Qt? WxWidgets doesn't use a preprocessor (well,
apart from cpp, of course.)

Yes. Sorry I wasn't clear about that. When I decided to give
things a look, there were two widely used GUI frameworks: Qt and
wxWidgets. I decided to not even bother downloading Qt because
of the preprocessor. I did give wxWidgets a very quick try, but
wasn't happy because it took over main(). Then I didn't have
time to go any further (e.g. to see if there were alternative
ways of using it), so I don't like to sound too negative.

 

[James Kanze]

* James Kanze:

I think you're thinking of QT (from Norwegian Troll, he he),
not wxWidgets.

I think I'm not expressing clearly what I'm thinking. The
comments concerning the pre-processor do concern Qt, and were
meant to explain why I only looked at Wx.

[...]

wxWidgets is not based on preprocessing, and it doesn't take
over main.

First, I want to be very clear: I don't really know it. I
downloaded it with the intent of learning it. The first example
or so in the tutorial did take over main, in some way or another
(I forget the details), and I was then interrupted by my real
work (which doesn't use GUI's), and haven't had time to get back
to it. So all I have is a rather negative first impression, but
for things as complicated as a GUI framework, one really
shouldn't stick with first impressions.

[James:]

And Java's Swing isn't that bad, and doesn't use any of those
solutions. What's wrong with the classical event notification
pattern?

"isn't that bad", hey, it's awful! Looks bad, slow, eats
resources.

It's nicely designed. Back when I was using it, everything in
Java was slow, and since it tended to reimplement all of the
drawing, rather than using native code, it was slow (but not
outrageously so). And whether it looks good or not depends on
whose programming it: you can create ugly and inefficient GUI's
with any tool kit. (Most of what makes a GUI beautiful or ugly
is situated at a level above the tool kit.) It provides the
tools to support well designed GUI's, if that's what you want.

And of course, given my background, I especially liked the fact
that I could have a Motif look and feel.

 

[s0suk3]

You're obviously not a Mac user.

Picking a random screen shot from wxWidgets' own site, at:

<http://www.wxwidgets.org/images/screens/bitwiseim_macosx.jpg>

Yes, it uses native widgets. It's got the "look" pretty close. But a
native interface, at least on the Mac, is more than that.

There are plenty of places in this app where one might want to copy
and/or paste text - but there's no edit menu. The relevant menu items
are either in a non-standard place, or missing entirely.

There are toolbars, but no toolbar hide button at the top-right of the
windows that have them.

The rows of buttons on the message dialogs are centered. Since English
reads left to right, they should be right-aligned, and the default
button should be on the right.

I could go on, but this isn't really about C++, so I'll stop here.

But note that all those issues are the implementation's fault, not
wxWidgets' fault. For example, AFAIK, wxWidgets doesn't provide any
kind of 'default' menu hierarchy; you have to build every menu item
yourself, hence you're in complete control of the menu labels and
their order. You're also responsible for the buttons in the toolbar.

Sebastian

 

[R.A. Nagy]

Apple's Human Interface Guidelines (the HIG I mentioned earlier)
should, IMHO, be required reading for anyone contemplating a Mac port
of their app.

<http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/>

Link is priceless.

Thanks!

R.A. Nagy
http://Soft9000.com

 

[Jerry Coffin]

Enough of that Mac snobbery! If you think people are gonna rewrite
everything just for the Mac because you don't quite like a shade of an
icon you can eat your one-button mouse.

Seriously, for many applications cross-platform toolkits are a nice
thing and a Mac user surely prefers a "close enough" GUI to one that
hasn't been ported to the Mac at all.

[ getting badly off-topic...]

A few years ago I was frustrated with how difficult it was to do
something fairly simple in Photoshop, so I wrote my own little Windows
program to do the job. It was fairly complex internally, but externally
pretty boring -- you opened a graphics file, it did its job, showed you
the result and let you save the filtered file. The only bit of visible
complexity was that it let you do the same transform on an arbitrary
number of files at once, and allowed you some flexibility about how it
dealt with file names.

A friend of mine who uses a Mac watched me use it once, and exclaimed
about how boring and ugly it was. As it happens, at work at the time I
was doing a little bit of Mac development anyway, so I decided to port
this bit of stuff to the Mac -- but with a twist.

Instead of making it boringly simple, I deliberately made everything
stupidly complex -- in fact, I pretty much implemented the same things
that Photoshop had, and then gave a rather complex set of directions for
how to carry out the steps in the right order to do the job. Just for
fun, I also included a few complete wild goose chases -- a few things
that looked like they were supposed to manipulate your picture (with
careful explanations about how they were much more subtle than the
"gross" controls in other programs), but really did nothing, no matter
how you adjusted the controls. OTOH, make no mistake about it: I spent a
ridiculous amount of time making sure those useless controls followed
Apple's Human Interface Guidelines as closely as I possibly could. I
took a process that could be (and was) completely automated, and added
useless human intervention _every_ step of the way -- and even
introduced a couple of steps that had absolutely NO use at all except
for making you do more "stuff" before you were done. As a finishing
touch, I added the automation back in, but only to have it "coach" you
for the optimum setting each step of the way -- if you tried to do
things out of order OR set the controls wrong, it told you so.

The next April 1, I decided to send this piece of crap out to the Mac
users I know (including the one who'd originally commented about the
"boring" Windows version. Apparently none of them realized this was
supposed to be a joke -- I got back about a dozen emails exclaiming
about how wonderful it was to see a former Windows programmer really
"get" the Mac, and go to all the time and effort to design such a user
interface that (according to one of them): "really showed how beauty and
efficiency could be harmonized." Rather than people noticing how I'd
made them waste dozens of steps on things it already knew how to do, I
go praised for such a thoughtful touch of having it help guide you
through the process to produce such superb results.

 

[Ioannis Vranos]

I think I'm not expressing clearly what I'm thinking. The
comments concerning the pre-processor do concern Qt, and were
meant to explain why I only looked at Wx.

*What does QT do with the preprocessor*? I am a concerned because this
is the framework I decided that I will probably learn to use, because of
its support and documentation (books).


The book I have in mind:

[C++ GUI Programming with Qt 4 (2nd Edition)]:
http://trolltech.com/developer/books/cpp-gui-programming-with-qt-4-2nd-edition



All the books they suggest:

http://trolltech.com/developer/books/

 

[Andreas Dehmel]

*What does QT do with the preprocessor*? I am a concerned because this
is the framework I decided that I will probably learn to use, because of
its support and documentation (books).

For the most part, the preprocessor is required to get signals/slots working
for your own classes derived from QObject (the Qt-base class for everything
that can have signals/slots). Essentially it checks for the macro Q_OBJECT
in your class declaration and creates special code for signals and slots. As
long as you only use Qt's classes, you won't need it. There are other uses
of the preprocessor (e.g. Qt-plugins), but you'll probably never need those.

I dislike non-compiler-internal preprocessors almost as much as James, but
the Qt one isn't nearly as bad as some of the ones I've come across (e.g.
Oracle's some yours back). I haven't seen it choke on valid C++ code (at least
not current incarnations), the biggest pain using it is trying to integrate
it into MSVC (don't ask...) because we haven't found a way to automatically
run it à la make-patterns, so we have to define the extra build stage by
hand each time; that's really a MSVC shortcoming, though. The biggest
limitations I'm aware of are that you can't define new signals/slots in a
template class or a subclass (more on that below).

I often wished they'd implemented signals/slots properly within the language,
but ultimately the good easily outweighs the bad IMHO. If you're really unhappy
about the preprocessor, you can always create your own library of intermediate
classes where you define stubs slots as virtual functions, then you have to use
the processor in that library only and everything else can just overload these
functions and forget about the preprocessor (I've done that for some frequenty
used widgets, works fine). That way you can also overcome the two limitations
I mentioned above.

The book I have in mind:

[C++ GUI Programming with Qt 4 (2nd Edition)]:
http://trolltech.com/developer/books/cpp-gui-programming-with-qt-4-2nd-edition

I think that's the one a colleague of mine had a look at before we started
porting a 3 million LOC project from Qt3 to Qt4. He wasn't that impressed
(could have been another book, though). The best way to learn it is probably
simply checking their examples (there are a lot of them) and getting your coding-
fingers dirty



Andreas

 

[Ioannis Vranos]

I have ordered "C++ GUI Programming with Qt 4 (2nd Edition)" and hope
for the best.

 

[f.fracassi]

I have ordered "C++ GUI Programming with Qt 4 (2nd Edition)" and hope
for the best.

It is quite OK as a beginners Guide, though not much more.
Besides there are always the great Documentation pages at
http://doc.trolltech.com/4.4/index.html. The Tutorials get you
started very fast, and I haven't found anything that I couldn't
gasp from the articles under "Core Features" or "Key Technologies".
All in all Qt's Online Doc belongs to the best Tech Docs I ever
used.

And even though I don't like the preprocessing either, it just works,
and even helps to cut some dependencies.
The rest of Qt's design decisions are sound, and the API is very clean
and unsurprising.

HTH

Fabio

 

[f.fracassi]

 And whether it looks good or not depends on
whose programming it: you can create ugly and inefficient GUI's
with any tool kit.  (Most of what makes a GUI beautiful or ugly
is situated at a level above the tool kit.)  It provides the
tools to support well designed GUI's, if that's what you want.

While it is certainly true that you can create ugly GUI's in any
tool kit, some make it much easier than others. In Qt for example
your application is as ugly or beautiful as the rest of your
(or your users) desktop, by default, since it automatically integrates
with the native style. Of course you can use theming to create other
styles.

And of course, given my background, I especially liked the fact
that I could have a Motif look and feel.

Qt also comes with a Motif Theme if that is what you call not ugly

Regards

Fabio

 

[Gernot Frisch]

The next April 1, I decided to send this piece of crap out
[...]
go praised for such a thoughtful touch of having it help guide you
through the process to produce such superb results.

Best story ever! I also get the feeling that you can make more money with a
program to sort your MP3 files by length, date, file size of date of
creation, than with any rogram that migth be of use.

 

[Gernot Frisch]

For the most part, the preprocessor is required to get signals/slots
working
for your own classes derived from QObject

....which could have been made entirely using standart C++ technique, IF one
knows how to program.