[Fluxus] qt port / source code management

[Dave Griffiths]

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

That sounds bad. I haven't experienced that, but I've only used MrEd a
little bit in the past. The main problem I've heard about it is that it's
out of date and a bit unmaintained.

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

Well, the rest of fluxus depends on PLT scheme.

Another approach - one that I really like, and I've taken with scheme
bricks, is to write the gui in fluxus. It's what I'd do anyway :)

FWIW I've used it to write normal fluxus scripts too, with the gfx in the
background as usual.

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

The glut application just embeds a scheme interpreter and provides the
livecoding editor which sends it bits of text. The renderer is a PLT
extension which is loaded into the interpreter's environment by the scheme
code when boot.scm calls (require "fluxus-engine.so"). There is no way to
get direct access from the application.

I see what you are thinking about though, and I do like it. I'm all for
changing the structure of how it fits together, but in general I'd like to
see more separation from the application rather than coupling them more
tightly, I'd like to keep libfluxus as 'just' a game engine. One reason is
so we can implement the livecoding editor in fluxus. Another is so that we
can easily have more than one front end for fluxus, eg. DrScheme. Or use
libfluxus as 'just' a game engine :)

I think if I were to do this (not using fluxus itself) I'd do it by using
a PLT extension to a gui toolkit (maybe not MrEd) and writing the
application in scheme. This means it's completely separate from the
renderer, and the application uses the scheme interface just like every
other fluxus script.

The reason for all the separation is scalability and managing the code.
The GUI, especially if it's going to be doing all sorts of pluggable
stuff, is going to get big - probably bigger than libfluxus, and involve
new dependancies (eg Qt). There is also the possibility that if it was
done in a more general way it could be used for other things too.

I need to have a bit of a think about all this...

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

Ahah, must read more docs :) Thanks.

cheers,

dave