A cleaner Morphic for 3.5 (was: Re: Re-doing Morphic ( Was:
Re:Traits prototype image ))
daniel.a.joyce at att.net
daniel.a.joyce at att.net
Tue Feb 11 22:18:41 UTC 2003
Trivial things are trivially easy in eToys. But what about HARD things.
Using eToys, how does one make a tree widget? A scrollpane? A List?
What about a single button class that doesn't take colors, but shows images?
What about making a button flip over in 3D as in the old IRIX system? Can I do
that? Can eToys script those funky 3D-button-menu-flipper things?
Hard things are DAMN NEAR IMPOSSIBLE in eToys. Give them a widget that works,
and you won't even need to script them in eToys.
( Has anyone written anything NON-TRIVIAL in eToys? )
eToys is for scripting things together. It's for cutting kids teeth in programs.
Tell me how one can script a windowed FFT algorithm in eToys?
I'd much rather prefer to drag out a buttonmorph, tell it how I want it to
render itself (we got menus, and introspection, why not build the menus from
looking at the morphs methods, like Morphic Wrappers?), and go.
Or even just say something like..
button -> new Buttonmorph
button render: someCostume on: #MouseUp
button render: someCostume on: #MouseDown
Where someCostume could be any sort of thing we'd like. This is just an off the
cuff example. ( NB, render could do anything, I mean, it could cause it to play
a sound too, if we send the appropiate messages).
button render: sqwakSound on: #MouseUp
button render: niftySvgIcon on: #MouseUp
Now, while yer dragging and dropping from the tilelist, and looking for the
proper tiles ( some of which don't seem to work right, and adding/deleting tiles
can be glitchy at times, it's why I don't mess with eToys much ), I'll have a
new button ready to go, and I can clone and play with it with handles now.
Then it's 100% simpler than eToys.
I'm a programmer, not a 10 year old. And there are some things that are best
done at the eToy level, and some things best done at the Smalltalk level.
If we provide a set of consistent morphs, and protocols, then everything will
work faster, and better. Plus a consistent set of protocols would make scripting
via eToys easier too.
Right now, I'm working on a project in PHP. But PHP is not fast enough, nor
perfect for everything. DB stuff is done on Oracle with PL/SQL ( Oh wait, I
could implement a simple flatfile DB in PHP!), the rendering is done with HTML
PHP is simple, but I'm not going to write a DB with it.
I just had some ideas today, and I'll lay them out tonight. TRAITS may prove
essential to creating a new flexible framework for Morphic.
> Nothing personal, but as of now, this is the most frustating message I have
> seen in this thread. Don't you realize that the Morphic that is perfect for
> eToys *is* the one that is perfect for programmers?
> I'll give you just one example: If I want to make a button in eToys, here is
> what I do. I go to the supplies flap, grab a rectangle, open its viewer,
> drag out the "color <- <...>" tile, set the color I want, set the trigger to
> "mouse down", grab a second "color <- <...>" tile, change it to "mouse up"
> and done.
> - Andreas
More information about the Squeak-dev