[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 should elaborate here, the application can get access to the renderer,
but only through calling scheme code in the interpreter - this is how the
gl editor gets the preferences set by boot.scm, for instance.

I can see a Qt based replacement for the scratchpad application working
quite well in the current setup by doing similar things, as long as
libfluxus was kept free of Qt code, so it could still work in DrScheme.

cheers,

dave