[Fluxus] qt port / source code management

[Dave Griffiths]

Hi Artem,

> In my local branch i've ported most of the windowing / input
> functionality from glut to qt. is anybody interested in seeing /
> testing that? My long term plan for the Qt port is to have GUI
> tweakables next to opengl window (in a split view or separate window),
> which will dynamically reflect what is in the engine, so that you
> could for example populate the scene graph from a script, then browse
> it in a gui, watch primitive state and tweak it from gui.

Interesting... Why not implement this in MrEd? It has a lot of GUI code in
it already, and drflux.ss contains the start of something like this. I
expect qt is better, just playing devils advocate - it might turn out to
be a lot less work, and you could write scheme instead of c++ :)

I like the idea though, and although I thought I'd always want a small
glut front end (I'm thinking about that now :) I'd like to have a
situation where we can many front ends, it's built to support that, after
all.

One thing is that you can't/shouldn't directly access the renderer from
the application, everything has to go through scheme. The main implication
of this is that you are going to need a lot more feedback from the engine
about the scenegraph, graphics state, and pdata.

This was something I've been waiting to do - it would be nice to be able
to navigate the scenegraph from scheme, after all.

> Now I tried to port as much as I could of current functionality
> provided by glut to qt. I also made it possible to select the
> "backend" (or is it a "frontend"?) at compile time with END=qt or
> END=glut argument to scons, glut is the default. In code I check for
> FLX_QT_END or FLX_GLUT_END preprocessor symbols. The most painfull to
> deal with is the keyboard code, which even under glut alone is
> platform specific... So i've reorganized it quite a bit, so that you
> never have to use GLUT_KEY_* symbols or plain numbers as before - all
> keys and modifiers are GLEDITOR_* constants now which expand into some
> appropriate code depending on END/platoform. This makes code somewhat
> neater, but doesn't solve e.g. recorder problem.
>
> Most useful functionality works under Qt for me, with the following bits
> broken:
>
> - mouse coordinates reporting in keypress/release events. Qt doesn't
> report them at all, I could listen to mouse motion events and save the
> mouse position all the time, but I just didn't get around to it yet
> and I'm wondering if that's useful at all.

One of my big problems with glut is that I don't think you can get mouse
motion without a keyboard or mouse button event, so you can't do
mouse-over type stuff. I'd call the event update every frame that the
mouse moves.

> - events record / playback is broken. it wasn't a high priority for
> me, especially since qt version is incompatible with existing records
> anyway. But it's on my list of things to fix after the next gig.

We need to come up with a cross platform way to do this anyway.

> - Renderer::DrawText (it used glut to draw). this one is tougher to
> reimplement, but possible. What was it used for?

Only drawing the fps :) Not important.

> Plus it has two bugs i've postponed until now:
> - the main loop doesn't exit on window close, i have to ctrl+c it in
> shell window
> - open gl widget has thick (like 10 pixels) grey border.
>
> I'll fix these two later today.
>
> This is a pretty large patch already and I use git to deal with it.
> It's highly experimental, so I wouldn't like to merge it into cvs head
> yet, but I really don't like to deal with branches in CVS. Dave, could
> you enable git or bazaar repositories on savannah? as far as i know it
> is possible to have several source code management systems there in
> parallel. Or you could make me co-admin and I'll set that up myself.

I'd like to move the whole project to git, but I haven't got into looking
how to do that. git is now 'turned on' in savannah.

cheers,

dave