On 12/31/2013 7:23 PM, Casey Ransberger wrote:
> 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
I would really like to have such a thing in Cuis. But I think we need to
do a few things before that. We need a good set of morphs, including
Beziers and other curves. We need zooming and rotating. I guess we also
need a way end users to specify behavior (stepping), or at least
constraints (and a constraints system).
And we need something Dan Ingalls talked about maybe fifteen years ago:
Some way to cross the bridge between morphs made with code and morphs
made with manual construction (menus, halos, etc). This would make
direct construction a useful way to build Smalltalk applications.
Something like WindowBuilder, but for general morphs.
We would also need the kind of dynamic state (properties) that Ken is
suggesting in this thread. But that's not a problem, we have Ken with us!
I think a good intermediate objective could be to build a DynaBook Jr.
for smalltalkers, meaning that it is ok to require some Smalltalk code
sometimes. And that environment (let's call it Cuis) could be a good
base to build an end user construction application.
Let's do it, one step at a time! Change will not happen instantly. So,
please keep discussing, and making it real with code.
Cheers,
Juan Vuletich
>> On Dec 31, 2013, at 2:08 PM, Ken Dickey<
[hidden email]> wrote:
>>
>> On Tue, 31 Dec 2013 08:40:54 -0800
>> Casey Ransberger<
[hidden email]> 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
>>
[hidden email]
>>
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> _______________________________________________
> Cuis mailing list
>
[hidden email]
>
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Locked
1911-CuisMediaAuthor-KenD-2013Dec31-14h23m-KenD.1.cs.st (8K) Download Attachment