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 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
