[UI] Re: "the new big thing" [was: MenuMorph hand weirdness]
Klaus D. Witzel
klaus.witzel at cobss.com
Tue Nov 20 15:06:14 UTC 2007
Forgot to comment a bit on my thoughts about SVG (when used within the UI
framework). I see it [SVG] as a good way to constrain/limit the things
which can possibly addressed by a new UI. Did not mean to implement it,
just use it as a stop condition (i.e. what not to do/address when
developing a framework).
On Tue, 20 Nov 2007 15:37:39 +0100, Gary Chambers wrote:
> Some thoughts on this...
>> Having read the LivelyKernel-SourceCode-0.7, I noticed the
>> following (list
>> not necessarily complete):
>> - orientated towards a possible WebOS
> have a clear separation between ui definition and presentation
>> - resources have URL (basic interoperability of material)
> URIs would be good to adopt, any ui element can be described via a URI
>> - imports, exports to/from other of the same kind
> not sure quite what you mean here Klaus
Was meant to just do enough to export from a system with new UI framework
to another system with same UI framework, but more than just
fileOut/fileIn of source code. Perhaps just enough to make one system
[computer] that can serve components to clients via some connection.
>> - graphical base objects out of the SVG box
> have done a bit with SVG (as far as Balloon could manage, Cairo would
> be a
> nice alternative presentation layer, still use Balloon for fallback (with
> limitations) for platforms that don't support Cairo (pdas etc).
>> - SVG+style is teachable to/learnable by the masses
> and is a standard. would be nice
>> - widgets look easy to use/reuse
> indeed... a better composite model would be nice (wishes I coul plug in
> different fillStyles at the moment... since they go to the lowest level
> is not currently possible to define a new type of fillStyle that is
> composited programatically)
>> - small # of support classes besides the UI framework
> with the right framework there'd probably be no "extra" support classes
>> - worlds, hands, morphs, ticks are shoulders+neck of that Atlas
> or just one kind of head-of-the-hydra
>> - Events / bindings are like a scripter expects them
> when...do... but also asynchronous, like updatingXXMorph - an
>> - no observable restrictions to animations (limited only by SVG, good)
> down to the in-framework support classes
>> - things can be glued together without headaches,
>> within the limitations (good) of SVG
> perhaps no complex interfaces, just individual aspects that can be
Sounds good. But raises questions, what+how. Roles? More general? More
>> For sure some of the concepts of LivelyKernel require that mixIns/traits
>> are supported but, who cares with a dynamic language and living objects.
>> And there is that remarkable comment, "my kingdom for a Smalltalk
> I like that one!
>> So my question is, how about borrowing some things from LivelyKernel?
More information about the UI