[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
> it
> 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
> independent
> observer
Sure.
>> - 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
> combined
Sounds good. But raises questions, what+how. Roles? More general? More
specific?
>>
>> 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
>> block!"
>
> I like that one!
>
>>
>> So my question is, how about borrowing some things from LivelyKernel?
>
> indeed...
More information about the UI
mailing list