[Plib-users] Middle of a conversation between Steve Baker and myself.

[dave <da...@mi...>]

I am posting this because Steve mentioned we should move to a listserv.
First time I tried Mozilla crashed upon sending, so if you see it twice, my apologies.

-Dave Clounch


dave writes >I suppose I used qt 2.3.0 because it was the free X11 version and it is also the version
> of the microsoft non-commercial version. Looks like they upgraded
> the former to 3.X but didnt upgrade the windows version.


Ah - could be.
 

>> > > OK...it would be nice if there was a **really** simple program that just did the minimum
>> > > necessary to get PLIB running in a QT environment
> 
> > Hmmmm...OK, I will restructure to one file that contains all code, and will try to build
> > a version that has as few panels as possible, maybe even none. It would have just 3 buttons
> > and an opengl widget on the one main widget. Qt seems to not have a concept analogous to
> > the JPanel of swing, but a QWidget with a layout manager is the equivalent, which is what
> > I was trying to show.


Yes - that would work.
 

> > - then something more interesting
> 
>> > > that showed off some reasons why you might want to integrate the two.
>> > >
> 
> > I have assumed all along that Qt is a rich GUI framework that would save
> > on the development of all those other frameworks (PUI?) that aim to provide
> > similar capabilities.


PUI occupies a very special niche that QT cannot help with.  PUI is implemented
on top of OpenGL - which means that all PUI widgets are rendered using the 3D hardware.

Most other libraries (GTK, QT, etc) use X to do their rendering - and that's VERY SLOW
compared to the lightning speed at which PUI draws things.

That's significant because it allows you to render the GUI elements on top of the 3D
scene at full graphics frame rate.  For games, that's VERY important.

However, I never recommend that people use PUI for a major GUI-based project because it's
rather ill-suited to those kinds of application and doesn't have a graphical GUI-builder
program for designing all of your widgets.

That's why programs like PPE (our 3D modeller) uses FLTK (it could have used QT or GTK or
some other GUI library) - but TuxKart uses PUI.


>> > > Anyway, I grabbed your tarball (via HTTP - that worked just fine)...
>> > >
>> > > I tried to build it and got:
>> 
>>> > > >   qtux/qtux> make
>> 
> > 
> > Oops. I was afraid of this. I didnt mean to cause you excessive work.


No - that's OK - this is what OpenSource development is all about!  You contribute
code that **seems** to be working OK on your system.  We find the problems - and either
fix them for you or report them back.  It's all part of the give-and-take that makes
OpenSource benefit everyone.


> > Looks like I am going to get bogged down for a bit as I learn the autoconf way of life.


Yep.  It's **very** hard and painful to learn - but it's worth it.

In this case, if we are going to make it be one of the PLIB examples, you only need to
build a 'Makefile.am' - which should be very simple.  Then we need to get someone on the
mailing list to change the main PLIB 'configure.in' file to check for QT and turn off
the building of your program if it's not installed.

I can't help much with that - but someone will be able to.  (We need to take this
discussion over to the mailing list - doing it privately like this doesn't work well!)


> > Tell you what:  how about if I try to build some more sophisticated applications
> > Qt/SSG first just to see if the ends justify the means?


Yes.  That's a good idea.

I've finished downloading QT 3.0.1 - I'll try installing it later on today when I have
more time.


> > Maybe Qt is too problematical for the actual capability it provides?


Well, it's never something I've been interested in.  I currently use FLTK for
most things - more out of familiarity than anything.  If I had the time to learn
something else, I'd learn GTK because I think that's the way of the future.

QT's ongoing licensing issues make it unacceptable to too many people.
 

> > An alternative I am curious about is gcj.


Never heard of it.


> > As the creators of the clean-room and opensource "kaffe" project move into more robust
> > gui work it may be possible to build truly open java interfaces to openGL that perform
> > really well if compiled. Maybe someone has even started doing that?  I suspect its a year
> > away though. When it does happen I suspect a java version of SSG will be the cat's meow.


I **really** dislike Java - it's not that it's a bad language - but it's disasterously slow
for serious games and interactive applications such as I like to work on.  Nothing but C++
will cut it for me right now.


> > Meanwhile, I just want to learn about scene programming. So much to learn, so little time.


Yep - I know what you mean.