[Fluxus] qt port / source code management

[Artem Baguinski]

On Wed, Dec 10, 2008 at 4:03 PM, Jeff Rose <jeff at rosejn.net> wrote:
> This is cool, Qt is a solid framework.  As for mouse coordinates, you can
> get the current position anytime using QCursor::pos(), rather than having to
> attach to mouse move events all the time.

Ah, thanks. Sometimes I can't find my way in Qt Assistant, the search
function there is a bit vague (or may be google spoiled me)

> The entire Qt system includes reflection capabilities because of some code
> generation they do in a pre-processing phase, which means that using the
> QMetaObject protocol you can pretty quickly generate bindings or do dynamic
> method lookup on objects.  I don't know anything about the foreign function
> interface or binding mechanisms in PLT scheme, but this could be an option
> for coding Qt directly in scheme down the line.

I have some (separate from fluxus) experimental bindings of some parts
of QtCore to plt scheme using swig and some voodoo. But every time I
mess with it I end up adding more features to my local branch of swig.
Scary stuff.

> Distributed versioning with git takes a little bit of adjustment, but I
> don't see myself ever going back to svn.  You can't beat the quality of
> merging, the speed of operations, and the ease of sharing code between
> developers while working on feature ideas, bug-fixes and branches.
>
> peace,
> Jeff
>
> P.S. Maybe this is sacrilege, but I've been messing recently with Clojure
> and the jMusic library, which I have to say is a really awesome combination.
>  The power of a freshly designed, next-gen lisp with access to the libraries
> from Java land is pretty compelling.  Not sure how well it could work for
> something like Fluxus though, because I've never done 3D graphics in Java.

ah! something to demonstrate at my "Dynamic Typing Anonymous" meeting,
to them java folks :-) could you elaborate on what's next about its
gen?

> Artem Baguinski wrote:
>>
>> hi all
>>
>> 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.
>>
>> 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.
>> - 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.
>> - Renderer::DrawText (it used glut to draw). this one is tougher to
>> reimplement, but possible. What was it used for?
>>
>> 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.
>>
>>
>
>



-- 
cheers,
artm

http://lab.v2.nl/