Re: Rounded Polyline, and other questions?



Wow, its been a while since I posted this, but I've been super busy with
other stuff.  Anyway, last night I finished a first pass at adding
rounded corners to zigzaglines and polylines, by adding some code to
the diarenderer.  I was developing against the DIA_0_94_DEV tag, should
I post patches against that, or against the HEAD?  Also, I'd be interested
once I post it in knowing whether some of the added functions should make
their way into the geometry.* files.

Anyway, if someone could let me know which is the current tag to submit
patches against I'll post it.

-Anthony

On Wed, Apr 28, 2004 at 10:44:47AM +0200, Cyrille Chepelov wrote:

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

-- 
_______________________________________________
Dia-list mailing list
Dia-list gnome org
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://www.lysator.liu.se/~alla/dia/faq.html
Main page at http://www.lysator.liu.se/~alla/dia


-- 
------------------------------------------------------------------------
Anthony Molinaro                                 <anthonym overture com>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]