Re: [Chicken-users] cross-platform gui toolkit

[Joerg F. Wittenberger]

Brandon Van Every wrote:

> > Chicken wouldn't have half the eggs it does if the non-Chicken
> > Scheme community had taken that position.  Fortunately for us,
> > they did not.
>
> Which half?  My world is OpenGL and C FFIs.  I don't see any
> interloper eggs helping out here.  It's one thing if your task is pure
> Scheme, quite another if your task is OS interfacing.

Brandon, please don't take things personal.  Don't downplay others
contributions just because you don't know yet where you might need
them.

> > I'm not sure you are right here, Brandon.  The people and interest are
> > there.  Just some of them will not jump on the chicken/gui ship when
> > it's chicken specific - as they refuse to jump on those other PLT or
> > whatever specific ships even though they seriously lack an viable
> > alternative.  
> > 
> You can of course post an abstract GUI project to comp.lang.scheme and
> see what takers you get.  But from a practical standpoint, you're in
> serious danger of design by committee.

:-) If I would bother so much, maybe I would do.

> Or a bunch of people talking and no action.

But I'm not doing this for the fun of it.  I'm forced to think
economical too.  There's a project, a design, a market need,
obstacles, challenges, actual and potential resources.  I'm on action
for several years now.  Slowly, sure, but eventually not without
success.  (I just hired a first employee for Scheme programming - ok
wrt. "no action", thank you.)

A good GUI toolkit is such a resource.

But I don't have the time or money to write something up, just to see
what I can eventually use it for.

So let me tell you something: a chicken specific gui toolkit, which
somehow wraps opengl and that it - that's something I don't have time
for.

> It would make a lot more sense to get it done in Chicken with a few
> people, show it to the world, and show that it's actually good.
> Then refactor whatever is Chicken specific about it, if you can
> draft up the labor for ports.

However I still have so much time for it, that I might spend half an
hour or more to write up my requirement for those, who might pick the
project up anyway.  Not because I'm ready to fight with them over
their design.  They might care or ignore my notes entirely.

If they ignore my requirements however, there is little chance that,
once they show their work to world, they will meet my needs.  If it
fails, like those toolkits before, I'll ignore their work as much as
they ignored my requirements.  (Hey, I can live without M$-Windows -
because it fails my requirements - I'll come over yet another gui
toolkit to forget.)

However I've got the feeling that there where some persons, who
listened, who - at least partially - agreed with my concerns.

Look, Brandon: long ago, when there was no chicken Scheme, I choose a
pretty nice Scheme for the feature set it had: multithreaded,
asynchronous i/o, persistant data, compile to C.  (Before than, I used
bigloo for my work.)  Then I went on to actually read the source and
had a look at it's community to find out how good I could support my
compiler without the original author (hey, he could be run over by a
bus the next day), before I based a business case on it.  A little
more community would have been a plus, but as things where, it was ok.
The I coded.  I tried to abstain from anything not looking like
R5RS+SRFI (except when there was real - i.e. economic - pressure).  I
ignored a nice object system.  I reimplemented few features to avoid
dependancies.  I ignored a huge amount of code (DNS, PDF, database
integration, font metrics, X11 integration spring to mind), which all
where very tempting to just reuse (and add sexy features).  All
because - by design - I'm not going to produce a rscheme specific
result.  Nevertheless - as I said economic pressure - a few things
crept in, like FFI related code, few finalization issues, and
eval/sandbox API questions, SSL etc. which keep the result system
specific for the moment.  (Currently the incompatibilities with
chicken+eggs appear to boil down mostly to API differences, not
feature sets anymore; some changes to our code base are just motivated
to use chicken's APIs.)

See: been there, done that.  For economical reasons, we'll be able to
shell out money for porting Askemos to Java.  Otherwise I'll take the
freedom to wait and help for more and more pieces of the work we have
put into Askemos beeing doublicated for other Schemes.  I'm not agry
about that.  Maybe a bit sad, because it's taking longer that way.
The advantage for me: there'll be others who will be asked to fix
their bugs.  ;-) I'm desperately *and* paitiently waiting for the
moment, when, eventually, there will be enough eggs to port Askemos in
a few days, cutting off most of my code.  Zero code sharing between
hosts is what I call a "heterogenous network" and that's what Askemos
is going to become - by definition.



     Schemers don't share code!
                                   (Except if doing so buys them time.)



I wish you all the success with the gui toolkit.  If you are
interested, I might take some time to review you design.  Just post it
to the chicken list when you feel ready to take discuss questions.
I'll comment on if I feel it's not wasting my time.

regards

/Joerg