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.) _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users