[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