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

[Joerg F. Wittenberger]

Brandon Van Every wrote:

> Matthew Welland wrote:
> > I'd suggest going one step further and striving to keep the scheme
> > portion not too chicken specific. Other schemes would only have to
> > provide the interface layer and the bulk of the code could be
> > reused.
> >   
> 
> From a support and community growth standpoint, I see no value in
> projects that try to be all things to all Schemes.  Doing things
> well on Chicken is what's important.  Also, reuse doesn't mean
> anything without people and interest.

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.  So adding one more ship will extends the set of options
I'm *not* taking anyway.  For me this boild down to accepting strange
restrictions (besides coding R5RS(subset) whenever possible):

I, for one, arrived at a certain user interface methodology.  At model
level I insist not to add anything UI specific.  But I allow some
generic call back registry for update events (the well known MVC model
approach).

At the edit level, either give me a graphical editor to try out, or
some declarative syntax, be it Scheme or whatever.  No more than 20
pages documentation.

For persistant storage and data exchange I insist at some automatic
transformation between hand written source and XML (both ways, round
trip safe at source level) at least for the model data, preferably for
the call back registry too.  Why?  I want to care about structure;
rendering the structure to valid HTML/XML/SVG/PDF etc. should be
negotiated and performed by some magic in my programming environment.
I just don't want to see it in my code.  Also, nobody likes XML, but
still that's the least common denominator to stay for long, long
time.  And it's well known how to programmatically modify it without
resorting to characterwise processing.

For display, push some kind of update description from model towards
the renderer.  There's probably some stack of backend specific layers
between the model and the actual renderer.  Preferably: put a network
connection somewhere in this stack.  This network transparency is
often handy.  If it comes into the way (say for games), just bypass it
in memory.

If this sound like HTML/XML/JavaScript and gecko, it's not too far
off.  That's how we do it most of the time.  Just a little less of
footprint would be great!  And maybe a nicer syntax.  But the latter
is about taste and I don't want to argue about that one.
Also http://haxe.org/ is on my radar in this context.

Furthermore: this path readily allows for terminal based alternative
user interfaces, e.g. for disabled people or small devices.  All
without changing the toolkit.

However a JavaScript dependancy might look strange to people, who
value security.  (At CCC, we just got demonstrated for how long we'll
expect man-in-the-middle holes) So I don't want to see JS in the
source code.  It's ok, if generated (so an alternative solution can
replace it entirely whithout me touching my code).

Still there ought to be the mentioned alternative.  The fast path is
"web 1.5" - a term I coined for "web 2.0 sans JavaScript": full page
update, all POST's redirected back to the sending page (keeps the
backbutton working), all state at the server.  Again: hide these
aspects from my UI source code.  Advantages: works immediately als
terminal alternative.  Works with same usability for JS-disabled
browsers (root users).  Disadvantage[*]: just close to a GUI but it
isn't.

The GUI alternative: hm, there've been Matthew's and other good
proposals.  End goal: SRFI, not less!  Render, say SVG (or subset)
[great, we get graphical GUI editors for free] plus some additional
basic widgets, about the Java AWT set, but if possible, more
declarative.  Automatic element positioning.  Allow to attach
callbacks (closures) to events.  React to update events.  Period.
No-no's: convey internal data from renderer to controler; "turtle
graphic" where you (...define a font, a brush, a second brush, a
cursor shape a cursor bit mask, select them into the drawing context,
remember to do so in the correct order, strike a path, close it, fill
it...).

I guess, the best thing to start with, was to agree on some "least
common denominator" GUI description syntax.  This would allow to
exchange the underlying implementation.  Looks like a Schemeish way to
me.  ;-)

Just my two cent.

/Joerg

Footnote:

[*] you may wonder why I did not mention "network load" under those
disadvantages.  After all AJAX was conceived because of that bottle
neck.

I did not, because "web 1.5" was invented a context like X Windows,
where is a "deployment mistake" to put WAN connections between server
and client.  Said context replaces servers of traditional web setups
alltogether with peer to peer networks.  Hence most work of the
applications workload is moved to the client, only things you don't
want to move (for legal or administrative or whatever reason) are
fetched remotely and transparently (from peers where they belong).

Now, if you think "this crazy guy, first he's talking about security
considerations, than replicating my servers, so anybody can deface
them": trust me on this one.  To brag a little bit: there's a lawyers
expertise in the works, which finds that Askemos (which is my context,
while the reference implementation follows my UI methodology - short
of having the gui alternative, yet) provides guaranties hard to argue
in (at least german's) court: we model the legal system, where peers
watch each other not to break rules/contracts (e.g., security
policies, fraudulently using DRM systems, administrative account power
or simillar, local backdoors).  Therefore we can provide location
independant, tamper proofed processes (execute according to contract)
on top of unreliable hardware in the face of hostile peers - with the
added benefit, that backups are for free and all system specific ties
are broken.

Not there yet: we are not at SRFI level.  Not even fully ported to
chicken.  (And "heterogenous" network of peers still is a theoretical
requirement - which brings us back, why I condiser it important not to
write chicken specific code, except for low level code.)