Re: [Quest-ed-devel] Status?

[Malmberg <mal...@ma...>]

> -> Development is now on the GTK-based Quest v3, which has yet to have support
> -> for various game added. I think it is currently only available via CVS.
> 
>         This is something I'd like to scrutinize.
> 
>         I've seen the beta of the GTK+ version that Alexander released
> many months ago.  It still had much work to be done.  The Windows version
> promptly crashed on me :)

The win32 port of gtk+ wasn't that great, at the time. I don't know if
it's better now.

>         If litte/no development work has gone into that tree since the
> beta (as indicated by the website), I'd like to consider some other
> options:

There has been a fair amount of work on it since the beta. Most of the
necessary code is there. However, Quest v3 is supposed to be able to
have many frontends, and this seems to work (I've been using a pure text
frontend for easy testing), so it should be fairly easy to add more of
them.

> 1. GLUT.  It's easier to maintain, less code, and more popular than GTK+,
> i.e., more 3D/game developers are already familiar with it.

It would work, but you'd have to write your own OpenGL-based GUI. Might
not be too bad. Does glut support multiple windows?

> 2. GLUI.  Based on (and requiring) glut, GLUI is a complete (fancy!)
> widget set that renders directly to OpenGL.  I've never used it, but it
> looks very cool.  Like GTK+, it looks the same everywhere--and it's OpenGL
> accellerated!  (Unfortunately it's C++ code.)

c++ in the frontend shouldn't be a problem.

> 3. Pure OpenGL for the GUI, and something like SDL for system-independence
> and portability.  The 2.4 line did its own menus and GUI rendering,
> avoiding all special widget libraries altogether.  Personally, I find that
> to be very cool.  Blender is this way, as was Gig3D before it.  The nice
> thing is that we could make non-X windows SVGAlib binaries, which really
> appeals to me (and now SDL supports PlayStation 2, whoop!).  Also, it
> avoids all the Window Manager and MDI bullshit that comes with a prefab
> widget set.

True, custom GUI:s have always been better, and the v2.4 GUI will remain
as a frontend, if only for the DOS/svgalib version. Supporting extra
'frontend-backends' like SDL shouldn't be too hard. Last I checked, SDL
didn't support multiple windows, which is annoying. I would like to
support dragging popup windows out of the way.

> 4. Of course, I really love GTK+, so we shouldn't forget about that, too
> :)  (I have no real interest in Qt.)

gtk+ is really nice for the dialogs. Maybe a hybrid would be useful, one
big OpenGL window for all the viewports, and gtk+ for the GUI in
dialogs?

>         I'd like to look at all of these options, but if Alexander is
> still actively involved I'd like to hear what he has to say.  Perhaps it's
> too late to think about these again.

Certainly not. Now is probably a good time to experiment with different
frontends, and the OpenGL renderer is supposed to be easy to reuse.
Anyway, I'll upload my latest version somewhere tomorrow, and I suppose
I'll import it as a new cvs module as well (and hope I don't decide to
rename all the files again).

>         FYI, Quest is about to become very important to me.  I have 11,000
> lines of code in a [Linux compatible] game engine I've written, and I want
> Quest to be the de facto editor for my SDK (with Blender being the
> modeller).  So I'm willing to put the time and effort into one of the
> above, at least for the next few months.
> 
> Thanks,
> Derek Simkowiak
> de...@re...

- Alexander Malmberg