[Cuis] Direct interfaces and HyperCard (Was Re: Grow Button [WAS Re: New updates: Reference Finder..])

[Casey Ransberger]

If only Self was popular. Direct user interface construction is one of my favorite ideas. Sadly no one in the Smalltalk community seems to have thought all that hard about how to do it. Every time I bring up the Self object transporter, it seems like there's a rack of people saying "don't." It works in Self?

I've been looking very seriously at Ted Kaehler's DynaBook Junior spec and thinking about doing an implementation in Cuis, which is at least a start. A HyperCard analogue. 

Of course there's a mostly unloved implementation sitting in Squeak thanks to Ted K. But it won't work in Cuis. We need a new implementation. 

It's just it seems like no one wants even that. 

Damned fools,

--C

> On Dec 31, 2013, at 2:08 PM, Ken Dickey <Ken.Dickey at whidbey.com> wrote:
> 
> On Tue, 31 Dec 2013 08:40:54 -0800
> Casey Ransberger <casey.obrien.r at gmail.com> wrote:
> 
>> #toggleFullBounds sounds great. Either that or #thanksKen.
> 
> Shorter than #youAreWelcomeCasey  ;^)
> 
>> Interesting that your solution uses the properties mechanism. I've never
>> touched that. I'd have probably given SystemWindow a couple of instance
>> variables to cache location and extent.
> 
> My model is that Classes use messages/methods/iVars 
> but individual instances use events/handlers/properties.
> 
> In particular, part of my list of past sins includes writing code in and for  MultiMedia authoring environments.  MM authoring -- particularly for media centric people who are not programmers -- tends to be more prototype based than class based.
> 
> One starts with a bunch of media pallets and explorers, splats media on the stage, adds behaviors, ...  Authoring tends to me more graphical by nature. [See mTropolis UI examples below].
> 
> One of the things I am thinking about is pushing Morphic toward a more direct/graphic style of authoring.
> 
> One change to think about is making some tests more instance based.
> 
> Why have an entire class of instances respond to some message when only a few instances need to?  An extra subclass with just a few methods.
> 
> Simple (possibly useless) example.
> 
> We could change some methods to look for properties.
> 
> Say 
> 
> Morph>>allowsSubmorphDrag
>  ^ self hasProperty: #allowsSubMorphDrag
> 
> So a class can still short-circuit this by
> 
> SomeSubclassOfMorph>>>>allowsSubmorphDrag
>  ^true
> 
> With no bad effects -- all the current code still works!  ;^)
> 
> But now one can have various instances support dragging submorphs without having to create a special subclass just to do this.  Just dynamically add (or remove!) a property.
> 
> Anyway, this is the kind of stuff I am playing with in the background.
> 
> Cheers,
> -KenD
> <Logic+Extras-Palettes.png>
> <Logic+Extras-Palettes.png>
> <MouseMessage-When.png>
> <Messenger-dialog.png>
> <ImageEffect-dialog.png>
> <Behavior-score3.png>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org