Re: Rounded Polyline, and other questions?

[Cyrille Chepelov <cyrille chepelov org>]

Le Mon, Apr 26, 2004, Ã  02:32:28PM -0700, anthonym overture com a écrit:

>   Now I'm working on the sequence and message flows which are essentially
> zigzaglines with a certain subset of arrows.  One difference however is
> that in the BPMN docs, the flows use orthogonal connections with rounded
> corners, and I would like to mimic this.
>
>   I've looked the the current crop of programmed objects and found that
> the SADT arrow does this, but this object seems to rely on a new orth
> connection object which is claimed to be a short term object.
> The SADT arrow also seems to not include some of the code in the
> zigzagline which pushes the line behind the arrow point (behavior I like
> because it makes the arrow heads look nicer).

Indeed. SADT was one of my first dips into dia, and it hasn't
benefited from some subsequent waves of refactoring. In particular, not
only it does not push the line end behind the arrow point like most
other objects do, but I think it also lacks autorouting and
autodirection.

The approach you outlined seems like a good plan (especially with the
default renderer in place), and I'm looking forwards to seeing it. If
you have the time to refactor and port SADT arrow over to the new code
(beware the automatic colouring), my gratitude will be proportional to
the number of SADT-specific line you delete, at constant feature set ;-)



>   Now I have a couple of questions.  Is the above a feasible approach?
> Are there any recommendations on different approaches?  Should I
> implement a rounded corner dialog into the zigzagline, such that
> the corner rounding works the way it does with the box (ie, you have
> an option to set a corner radius, if it's zero don't round and use
> the old functions if it is greater than zero use the rounded methods)?

It could be a simple extra property (for poly_conn and orth_conn). In
fact, that was my original approach, which Alex shot down in favour of
diagram type-specific objects (and with the experience since then, I'd
say he was totally right with respect to user-visible objects, though
I'd say the question of whether to make PolyConn and OrthConn aware of
the concept of corner radii, or to extract RoundedPolyConn and
RoundedOrthConn out of a blend of Poly/OrthConn and "SADT - Arrow" could
be a subject to debate. I'd say that the former approach may be better
today, if it can be done without creating a lot of mess in the code. As
this seems to affect only the rendering and perhaps the mouse hit code
in the case corner_radius > 1e-3, it may be a good thing to add a
(hidden, unsaved) corner_radius field to these base classes, which can
be declared as the storage place for properties in your new objects if
they need (and statically reinitialised to SADT's current corner
radius). Later if users want it in the generic zig-zag and ortho line
objects, the property can be exposed there.

>   I'm really new to the code so could be completely off on all of the
> above, please correct me if I am.

I think I agree with Lars' reply to this paragraph: welcome on board!

        -- Cyrille

--