links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
I wish Morphic could do ...
Last updated at 5:08 am UTC on 25 January 2009


Here is a place to tell short stories about what Morphic could do if it did all it should.

Storys might start with variations of:

Sunday, 25 January 2009, 5:08:58 am, squeak
I wish morphic has a slider morph consisting of a movable ball on a line with the limits of the slider clearly displayed at each end.

For example: [4] ——o——–[44]

The endpoints might have clickble arrow <> for incrementing or decremented. Or a drop down menu of possible values.
And /or the simple ability to edit the number directly.
Clicking of double clicking on the ball would change its color to indicate that truncation is on.
Some other gesture possibly holding the mouse down on the ball long enough
would allow you to change the selector
Similarly, the selectors arguments
and something else like bringing up the halo would allow you to site a new target for the slider.
Basically do all that is necessary without have to go halo select menu select menu item blah blah blah.
We want to augment the user here.

Saturday, 24 January 2009, 11:26:59 pm, squeak
I wish I could get textual bindings into a workspace more easily and more safely.

Problem: Workspaces are large and is is easy to drag and drop things on top w/o wanting to make big changes in the workspace.
In particular, without wiping out the most recent selected text. Often times that texts is a large doit you want preserved.

Currently the only way to get contextual edits into a workspace it to set a flag to allow dragging and dropping to mean "replace the selection with the text bound to my morph".

The target for the drop is the intire text holder of the workspace. Once dropped the flag remains set so a subsequent move of a morph that
winds up over the workspace will also leave its mark often at the worst possible time.

1) have setting the drop flag act as a one shot. I.E. it turns itself off once a single morph has been dropped.
2) have a smaller target act as an inbox for dropped morphs. A simple inbox icon on the system window header could be the target.
3) have a confirmation dialog if the text of the binding would replace a large selection of code.


Saturday, 24 January 2009, 11:17:54 pm, squeak
When I accept text in a workspace I would like that to save the text to a file of an appropriate name.
I would like the workspace label to endup with that name.

Problem: When you edit a workspace it flags itself as having unaccepted edits. When unchanged windows are closed this prevents the workspace from disappearing and the information to be lost.
However, when you press accept (cmd-s or via them menu.) then the flag is reset. So an unchanged window sweep will close the workspace. It is a burden on the programmer to remember to save the text first lest it be lost.

Solution: Let the closing of the workspace first do a save on the textual contents. Then the workspace data can be retrieved.

Tuesday, 19 June 2007, 9:16:36 pm, squeak

Polygons (and MixedCurveMorphs) should be able to imitate rectangles, ovals and round rectangles.

Polygons are the most morphable of Morphs and that power should be exploitable to the User of Morphic.
Easy ways to change shapes should be available thru the red halo menu or in other ways.


Tuesday, 19 June 2007, 9:13:01 pm, squeak

Star handles should work on other morphs

Stars have a center and and outer handle.
Leaveaside the up, down, left and right arrow now around the center handle.

The outer handle allows the starmorph to be scaled and rotated around the center handle.
When the shift key is also pressed. The morph will stretch with the center handle as its reference point.

These behaviors would be benificial to most other morphs.
Also there should be someway a polygon or mixed morph could have star handles for a while and gain shapes like a star
then switch back to the more general vertex and midpoint handles. In other words start out in star shape and then revert to polygon.
At that point you wouldn't strictly need a StarMorph. And polygon could serve as a star.

Tuesday, 19 June 2007, 9:04:03 pm, squeak

Heading should equal forward direction plus rotation degrees.

Heading is the direction that a morph moves in when told to go forward.
Rotation degrees describes the amount of tilt a morph has from its normal orientation.
Forward directions describes the direction a morph will move in when it is in its normal orientation.

Presently a Forward direction of 0 means the morph move off to the right.
When they are rotated polygons don't remember that they are now tilted.
When polygons have submorphs the wrongness of this becomes obvious. -wiz

Tuesday, 19 June 2007, 8:56:15 pm, squeak

All morphs should behave similarly when turned or stretched.

Presently the growth handle works differently for rectangles and ellipses than they do for polygons.
The dissimilarity should not exist. –wiz

Tuesday, 19 June 2007, 8:53:06 pm, squeak
The center handle should not wobble.
When turning a morph the center handle representing the reference point wobbles all over the place while the morph is turning.
It should remain in one position thru out all turning and stretching operations. -wiz

Tuesday, 19 June 2007, 8:50:19 pm, squeak

In Morphic Halos should act more like menu's.

Currently HaloMorphs both present halos and provide actions for the halo's. This should be sparated so that the responsibilities for the actions are left to the halo handles themselves. And the actions should be delegated so that the target morphs have the major say in how they are carried out.