chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joerg F. Wittenberger
Subject: Re: [Chicken-users] cross-platform gui toolkit
Date: Fri, 9 Feb 2007 10:34:09 +0100 (CET)

Brandon J. Van Every wrote:
> Crazy Eddie's GUI System
> http://www.cegui.org.uk/wiki/index.php/Main_Page is worth looking at
> in this regard.  It is a C++ toolkit, skinnable, MIT licensed, and has
> survived as the preferred GUI of the Ogre3D engine.  Ogre3D ain't
> small potatoes.  This means CEGUI has community resources that most
> open source projects lack.  When I say "look at it," I mean for design
> inspiration, since it's a successful system.  I think C++ wrapping
> projects are currently hard in Chicken, so I've been leery of chasing
> anyone's C++ development.
 
Not bad!

And give some inspiration.

I'd ignore "C++ wrapping" is currently hard in Chicken.  It could be
solved rather easily for this particular (and simillar) case(s).

What I would do:

1. Nag Felix, the poor guy - until he adds (that is finishes, as I
recall) an interface to call Chicken from POSIX threads.  Maybe that's
even possible already, but I don't think so.  Is it?

2. Start two POSIX threads.  One running Crazy Eddie plus a some C++
"driver" code talking to the other POSIX thread running Chicken, where
it's a different job to dispatch events to whatever chicken thread.

I like CE's XML way of specifying GUI layouts.  Fit's pretty well with
SXML on the Scheme side.  It should not be too hard to deploy the
ResourceProvider mechanism of CE to fetch the XML in core from
Chicken.

Also Input gathering ougth to be done here per default (though for the
sake of game developers optionally).  This must not preclude event
injection from the Scheme side.

3. At the Scheme side, *I* would (I told you in the other mail that
I'm sold already) base the interface at this cell-gtk syntax (with
modifications like dropping "mk-" prefixes.  I'd consider to modify
the language: compare to CE's syntax and unify or alias what maps.

3b. Do these cells very general, Scheme way of doing things.  If this
becomes a SRFI of it's own, not bad but also not nessesary.

4. While doing 2 and 3 in parallel, have a look aside to the cell-gtk
LISP code.  Eventually, that is once 3 is sort of stable (beta), throw
some alternate GTK bindings underneath the syntax of 3.

4b. Having two bindings, some KDE guy will probably sit down and
create an alternative to the CE thread, driving KDE.

5. Write two SRFI's about (1) and (3).  (3) will need some system
support impossible with pure Scheme - the graphics side.  But there
where several bindings at this time already.  And the conversation
between Scheme and the GUI system is by now broken down to a
thread-thread communication, which could be done via ports for the
SRFI, while we don't have an extra interpreter and pipes for the "real
thing" of an implementation.

6. Have a lot fun with the result.  And don't mind if the SRFI takes
years to adoption.

/Joerg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]