[Fluxus] qt port / source code management

[Artem Baguinski]

On Wed, Dec 10, 2008 at 11:20 AM, Dave Griffiths <dave at pawfal.org> wrote:
> 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++ :)

1. Every time I used mred or drscheme i quickly ran into garbage
collection taking like 5 seconds to finish. I thought if I constantly
create / destroy the GUI on the fly it will only get worse.

2. More importantly I don't want to depend on plt scheme too much. I'd
like to add pluggable scripting part as well, at some point.

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

why can't / shouldn't I? If renderer changes it's scheme interface
changes as well, so what do I gain by going around?

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

and what about glutPassiveMotionFunc?

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

right. maybe just pass keystrokes as standardized strings ("C-a" for
control a etc)

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

Ah, thought so. I'll reimplement it later with qt 2d painting stuff.

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

Ah, thanks. I'll look into exporting CVS into git and then making a
branch for the qt port.

-- 
cheers,
artm

http://lab.v2.nl/