Re: chickenpox: dia in LWN (again)

[Alan Horkan <horkana maths tcd ie>]

On Fri, 19 Mar 2004, Cyrille Chepelov wrote:

> Date: Fri, 19 Mar 2004 09:01:06 +0100
> From: Cyrille Chepelov <cyrille chepelov org>
> Reply-To: dia-list gnome org
> To: dia-list gnome org
> Cc: lwn lwn net
> Subject: chickenpox: dia in LWN (again)
>
> Hi folks, hopefully $SUBJECT won't trigger or poison bayesian filters.
>
> I just noticed this great article http://lwn.net/Articles/75198/, which
> obviously uses dia for its schemas (OK, I know Jonathan Corbet is using
> dia; keep up the awesome work, Jon!).

Those are really pretty graphs.

Mine are usually just black and kinda chunky looking, I guess I need to
try harder.

> Look at the filled-circle end of the brown arrows. Notice how they are
> unaligned? Yes, we're lacking connection points in most of our objects.

He could have lined up the dots in that diagram by producing a vertical
line and making it white/hidden and then connecting the dots along the
connection points of that line.  It isn't great but it works.  (Which
reminds me, connection points on the ends of lines allow us to join lines
to lines is something I forgot to file a bug report about).

> Well, not always, sometimes we have too many of them, but here's my point:
> we frequently end up in a scenario where we don't have an adequate number or
> placement of connection points.

I'd certainly like to see at least a centre point automatically added to
everything as it would make it easier to use imported SVGs and Images
directly as reusable shapes without needing to provide additional markup
or a shape file to wrap them in.

> Enter "chickenpox-mode", the thing I'd like to implement. In a nutshell,
> this would be the ability to dynamically create connection points anywhere
> within an object (or shape -- anything here would apply to the base
> classe(s)) instance when one finds the existing CP's are inadequate, and
> later delete them (when they're no longer useful).

I'm wondering if perhaps you have considered making this
available/representing it as an extra special layer?

> I think from the UI point of view, it needs to be close to the "snap to
> grid" switch; except that it should be a three-way switch:
>       1. No dynamic CP creation (current behaviour, default)

>       2. Add CP on edges (this, in effect, would snap on the intersection

If this is the same as "Snap to Objects" *(lines and objects snap to the
circumferance/outline of an object) would be great as it allows you to do
nice things like snap a hexagon right beside another hexagon or snap
images beside each other and made crude jigsaws or quickly draw tiled
drawings.

* I think it was Visio that has 'Snap to Objects' but it may be
remembering it from Adobe or Corel or all of the above.  I can try and
gather some data on these kinds of Snapping Connecting behaviours if you
want.  As always I encourage you to look at existing sofware as much as
possible for ideas.

> of the snap grid and any lines (straight or otherwise) from the object: drop
> a connector end on an object's line, and it will add a dynamic CP to that
> object and bind the connector; the exact placement of the object will be
> guaranteed to be on an edge, and if the snap grid is applicable, on the snap
> grid as well)


>       3. Add CP on body: anywhere within the object's shape or edge (*NOT*
> bounding box -- if we're talking about an ellipse, only the fillable area
> applies), and subject to "snap to grid".

>       (add CP on body would be, of course, synonymous to add CP on edges
> for "matchstick-like" objects).

> Once a dynamic CP has been created, it is unmovable, and keeps its relative
> position when the object is resized (the grid applies only during the
> initial CP creation). dynamic CPs will have to be deletable (probably some
> "CP eraser" tool, which you'd use to point and click at each unwanted CP,
> and the default, old-style CPs will need to become invisible (this way, we
> can conceal the UI inconsistency between old-style CP and new-style) (it may
> be that once created, a dynamic CP exists forever and can just be concealed,
> I wonder if it's a big deal from the memory point of view, if that brings
> about a real implementation simplification).

> A menu entry "remove all unused connection points" (which will actually hide
> unused old-style CPs) will complete the design.

I would think that when you save would be a good time to purge any orphan
connection points but depening on how you do it you will probably need to
have this functionality somewhere else.
This all soonds a little complex to stick in the menus, and adding a Panel
to preferences might not be a bad idea depending on configurable you
make the system.

> Finally, to ease the transition, ConnPoint_Line will become effectively
> dead-wood code, as I don't see who would want to use this style of dynamic
> CP addition-removal anymore, but I'm afraid we won't be able to get rid of

The nice thing about the connection points at the moment is that they are
evenly spaced on the line, I'm not sure it would be easy to layout
things as neatly in this one specific ase with the new dynamic system you
propose.  It isn't very important but I thought it worth mentioning that
the current system does have at least some nice points.

> all of it: we need to support reloading older diagrams, and I guess the
> easiest way to do this is to dispose of the middle-click menu entries and
> support routines (actual "dynamic addition/removal"), while keeping the
> load/save capabilities.
>
> From an implementation point of view, I think I'll use a custom renderer to
> ask objects where their edges and bodies are; this way all existing and
> future objects should be able to take advantage of this in a reasonably
> generic way (I think).


> Now, the questions:
>       1. Does this make any sense from a user interface and user
> expectation point of view?

I hope I've given you some idea of my user expectation.
You really should try Visio as that is what a lot of user expectations
will be based on but I'm sure you can do something better than what I've
seen.

> Does this solve a real problem, and does it
> appear to solve it in a desirable way?

I believe it does, I think you have the fundamentals right.

>       2. From the few implementation details I gave, does this sound
> reasonable?

>       3. Lars, do you feel this is the right time frame for me to commit
> stuff if I get something running (or at least, non-dangerous intermediary
> patches), or do you prefer that I stick to either a branch or a floating
> patch for the moment? (I'm concerned with the release schedule you have in
> mind).

This sounds like it would be good post 0.93 and before 1.0 (whenever that
might be) but I wouldn't presume to know what Lars has in mind.

Hope my comments and suggestions are of some use.

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/