On Tue, 2008-11-18 at 10:09 -0500, Kenny wrote:
> otoh, the only GUI that matters any more is the Web, I recommend
> qooxdoo. (Thx for the tip, Lars!) Once I have it fully figured out we
> can do Xello or some other Lispy wrapper such as SymbolicWeb. And this
> aint just the Web with AIR/WebKit.
Cool, keep me posted on this; I've had to dive back into using "Plain
Old HTML" as widgets for a while now. It works in simple contexts, and
my current task is simple (doesn't require fancy widgets) -- at least
for now.
So in other words I _still_ haven't settled on one of the higher-level
widget frameworks out there. It's surprisingly hard to decide; much
harder and more timeconsuming than I thought it would be.
The good thing is that (most of) the really hard problems I deal with
will be useful when I settle on a higher-level framework later.
Hooking things together using Cells should be possible; I'd like to keep
things optional or separate though, same as with the messy MVC-stuff I'm
trying to figure out atm.(#1). I'm not forcing users to use it, but
instead implementing it as a component or layer "outside" the "plain
direct manipulation of widgets" stuff(#2). Seems it'll take a couple of
iterations or tries to get right though ..
I'm not even forcing users to use the widgets SW provide; one can just
comment out all the widget stuff in the .asd-file, then build a
widget-framework on the basic low-level stuff like APPLICATION (a
session), VIEWPORT (a browser tab/window), ADDRESS-BAR (the URL really)
and RUN (send JS to the client) etc.
..so yeah, I'm trying to keep things, everything, separate.
Someone on IRC has taken an interest in the new HTTP backend(#3) btw..
I've had to work on other stuff for a while now, so this part of "the
plan" has been lagging behind also.
#1: Progress is good here btw. I've found a couple of much much simpler
solutions than what I had when I started.
#2: I'm working on a way that'll enable on to manipulate the "Model" of
a (any) container widget as a plain Lisp list:
http://groups.google.com/group/comp.lang.lisp/msg/6bbe8acb99707aa4 ..
it's very cool. I should convert some more of this stuff to methods so
one can do the same with different "backends" than a Lisp list. Working
on it ...
#3: The one that scales like crazy (20000+ concurrent sessions) and has
potential wrt. portability (to, say, CLISP (read; small install size) on
Win32) or these "AIR" or Google Gears offline concepts).
Lars Rune N�stdal wrote:
> On Tue, 2008-11-18 at 10:09 -0500, Kenny wrote:
>
>>otoh, the only GUI that matters any more is the Web, I recommend
>>qooxdoo. (Thx for the tip, Lars!) Once I have it fully figured out we
>>can do Xello or some other Lispy wrapper such as SymbolicWeb. And this
>>aint just the Web with AIR/WebKit.
>
>
> Cool, keep me posted on this; I've had to dive back into using "Plain
> Old HTML" as widgets for a while now. It works in simple contexts, and
> my current task is simple (doesn't require fancy widgets) -- at least
> for now.
Nothing wrong with that, except browser variability if one pushes things
too far. major claim to fame of these frameworks is handling browser
variability.
>
> So in other words I _still_ haven't settled on one of the higher-level
> widget frameworks out there. It's surprisingly hard to decide; much
> harder and more timeconsuming than I thought it would be.
Frickin exhausting. I will probably write up my results eventually. I
think Dojo (just awful documentation) or qooxdoo are the way to go.
Qooxdoo tosses markup and with it the declarative thing which is fine by
us since we intend our own declarative thing on the Lisp side, but if
one is worried about being a thin wrapper qooxdoo is a major decision:
one is really committing to being a qooxdoo add-on. I am just trying to
get one client's screens up so not an issue. qooxdoo not only hides
browser variability it also hides html and css, so it takes those off
the learning curve for interwebby noobs such as Moi.
>
> The good thing is that (most of) the really hard problems I deal with
> will be useful when I settle on a higher-level framework later.
Yes, this is what we must tell ourselves as we bang our heads against
the wall.
>
> Hooking things together using Cells should be possible; I'd like to keep
> things optional or separate though, same as with the messy MVC-stuff I'm
> trying to figure out atm.(#1).
I detect a slippery slope of Premature Perfection leading to Never
Shipping derived from forgetting Lisp code is Easily Refactorable. Just
plunge in!
> I'm not forcing users to use it, but
> instead implementing it as a component or layer "outside" the "plain
> direct manipulation of widgets" stuff(#2). Seems it'll take a couple of
> iterations or tries to get right though ..
Later. Just Ship(tm).
>
> I'm not even forcing users to use the widgets SW provide; one can just
> comment out all the widget stuff in the .asd-file, then build a
> widget-framework on the basic low-level stuff like APPLICATION (a
> session), VIEWPORT (a browser tab/window), ADDRESS-BAR (the URL really)
> and RUN (send JS to the client) etc.
Cool, maybe Xello can sit on that layer.
kt
>
> ..so yeah, I'm trying to keep things, everything, separate.
>
> Someone on IRC has taken an interest in the new HTTP backend(#3) btw..
> I've had to work on other stuff for a while now, so this part of "the
> plan" has been lagging behind also.
>
>
> #1: Progress is good here btw. I've found a couple of much much simpler
> solutions than what I had when I started.
>
> #2: I'm working on a way that'll enable on to manipulate the "Model" of
> a (any) container widget as a plain Lisp list:
> http://groups.google.com/group/comp.lang.lisp/msg/6bbe8acb99707aa4 ..
> it's very cool. I should convert some more of this stuff to methods so
> one can do the same with different "backends" than a Lisp list. Working
> on it ...
>
> #3: The one that scales like crazy (20000+ concurrent sessions) and has
> potential wrt. portability (to, say, CLISP (read; small install size) on
> Win32) or these "AIR" or Google Gears offline concepts).
>