Re: Question about handles

[Don Blaheta <blahedo blahedo org>]

Quoth Hans Breuer:
> Am 31.07.2008 04:30, Sameer Sahasrabuddhe schrieb:
> > On Tue, Jul 29, 2008 at 12:42 PM, Hans Breuer <hans breuer org> wrote:
> >
> > > No. There are handles on every object. They are represented by the little
> > > squares. Some of them are connectable (see lib/handle.h:HandleConnectType)
> > > and some of them are non-movable (lib/handle.h:HandleType).
> > >
> > > Non-movable handles - as in "UML - Class" - drawn in (almost) black.
> > > Movable, not connected handles are drawn in green. Connected handles are
> > > drawn in red.
> >
> > That's still not unambiguous enough. Here's what I understand. There
> > are two properties to a Handle: connectable, and movable. One would
> > assume these two are orthogonal, so that there can be four types of
> > handles such as "connectable and non-movable" and so on. From your
> > description, it _seems_ that if a Handle is non-movable, then the
> > "connectable" property does not matter. 
>
> I think it is exactly this way in all the objects Dia has. Connecting a 
> handle somewhat requires to move it, doesn't it?

Not in the sense you mean: while connecting a handle does require moving
it around the diagram, that movement can be of the whole object.  A
"non-movable" handle just can't be used to resize/reshape the object.

The real question is, what would it mean to have a non-movable handle
that you could connect to a ConnectionPoint when the CP's object moves
around.  With (say) a Line, that end of the line drags; with a
hypothetical ConnectibleBox the box corner or side could drag itself
along.  But with something that is not resizable via handles, this would
have to end up being essentially a grouping operator---dragging the
object along with it.

That's not impossible to imagine, but it's pretty different from the
current paradigm.

> (-: ... still I fail to see the reason to discuss this particular source 
> codes explaination in this length. For me it seems to be enough when the 
> source code is non-ambiguous. It is the "final truth" no matter how well or 
> bad the explainations are...

That's true, but the "final truth" need not be the only truth (though it
may be the only *complete* truth).  This is a trap that a lot of
experienced programmers fall into, I think, being so good at reading
code and holding whole designs and hierarchies in their head that they
don't need to make use of intermediate analogies.  But when you're
reading code (or anything else technical, really), it becomes much
easier if you can get some general intuitions about the data flow and
the control flow before trying to understand the "final truth" about
them.

I have a bias towards self-documenting code, which is why my
contribution elsewhere in this thread is of the form "this is what I'd
name the classes and variables", but that's obviously not the only way
to go.  The real goal is to put together documentation, if only a thread
on the mailing list, that gives a code-reader some intuitions about how
the data interacts, so that when they go back and reread it, they can
actually make sense of it this time.

-- 
-=-Don Blaheta-=-=-blahedo blahedo org-=-=-=-<http://www.blahedo.org/>-=-
"I may---and don't hold me to this---shout "Woo"."      --Tycho