At 12:01 PM -0700 4/16/02, Ned Konz wrote:
>On Tuesday 16 April 2002 11:16 am, I wrote:
>
>>  I think there is a bug in gridFormOrigin:grid:background:line: but
>>  haven't had a chance to look at it very far.
>
>No, there was a bug in PasteUpMorph>>drawOn: and I posted a fix.
>
>Anyway, I'm a bit puzzled as to exactly how much gridding support is
>wanted or needed in Squeak.
>
>Very few things actually respect the grid; among these are the drag
>halo, the grow halo, and resizing via resizeMorph: (called from the
>Morph meta-menu). And dragging PolygonMorph vertices but only if the
>PolygonMorph is not curved.
>
>On the other hand, common options like dropping Morphs on the
>playfield don't respect the grid. Except for PolygonMorphs, which do.
>
>SystemWindows arrange their collapsed positions on an 8x8 grid,
>regardless of the prevailing world grid.

>SelectionMorph motion respects the grid.

How about making grid-awareness be part of the LayoutProperties of a 
Morph?  It might take a while to go back over all subclasses and 
retrofit them to recognize it, but at least then we'd have a central 
place for storing the attribute.  Or we could decouple turning the 
grid off/on from controlling grid size, color etc., by putting 
enabling in LayoutPolicy and layout attributes in LayoutProperties.

I'm working on a some enhancements to layout, including a GroupMorph 
class, that will allow easier interactive control of submorph layout. 
My goal is to a model of drawing composites similar to that in 
drawing  and flowchart programs; gridding fits nicely into that 
model.  So I'm in favor of at least some gridding support to all 
morphs.

>
>I find the grid useful when making drawings, and my Connectors objects
>generally respect the grid when dropped. The connectors themselves
>also respect the grid when you drag ends or vertices (though maybe
>the dragging should be smooth and the gridding should just happen on
>the drop.)

I'd vote for smooth dragging, but I'd also recommend that some 
Connectors be able to ignore gridding even when others recognize it. 
You might, for instance, want to put the objects at the vertices of a 
graph (maybe a flowchart) on the grid points, but be able to resize 
them such that the connection vertices are not on the grid.

>
>But I've had to make SketchMorph subclasses that would snap to the
>grid when dropped (I need to make sure that fixed attachment points
>like in schematic symbols line up with the grid).
>
>I'm willing to make other common operations respect the grid, but
>would like to know how far I should go. I could see a per-Project
>Preference that would make dropped Morphs position themselves on the
>grid (perhaps at the center or a corner, depending on which is
>nearest).
>
>What do you think?

If there is a per-Project preference, I'd like to see it be the 
default for all the morphs in the project rather than an absolute 
requirement on them.  In other words, I'd like to be able to change 
the preference for a given morph, or have the value for a morph moved 
in from another project remain the same.

Bruce Cohen

>--
>Ned Konz
>http://bike-nomad.com
>GPG key ID: BEEA7EFE


-- 
"The joke is over when the head falls off." - Scotts' proverb
=========
Bruce Cohen
5908 SW California St.
Portland, OR 97219
brucecohen at qwest.net