«

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

> 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

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

On Jun 26, 11:58 am, Michael Oswald <muell...@gmx.net> wrote:
> James Kanze wrote:
> > From what little I've seen, wxWidgets seems to be one of the
> > more popular frameworks.

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

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze wrote:

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

James Kanze wrote:

> 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

Sherman Pendley wrote:

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

> 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

On Jun 27, 2:07 pm, Matthias Buelow <m...@incubus.de> wrote:
> James Kanze wrote:
> > 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.)

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 (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jun 27, 4:13 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * James Kanze:
> > On Jun 26, 11:58 am, Michael Oswald <muell...@gmx.net> wrote:
> >> James Kanze wrote:
> >>> From what little I've seen, wxWidgets seems to be one of the
> >>> more popular frameworks.

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

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

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34