Re: Rounded Polyline, and other questions?
- From: anthonym overture com
- To: dia-list gnome org
- Subject: Re: Rounded Polyline, and other questions?
- Date: Tue, 22 Jun 2004 14:59:39 -0700
Just curious if there are any comments about the patch I submitted?
Thanks for any feedback.
-Anthony
On Wed, Jun 16, 2004 at 02:23:51PM -0700, anthonym overture com wrote:
Okay, here's the patch against the HEAD. Let me know if there are any
changes people might like. As for moving some things to geometry,
specifically I'm talking about the somewhat general point_cross, dot2,
line_coef, line_to_point, and point_perp. Although the fillet function
could also arguably be there or not.
The algorithm was taken from one of the Graphics Gems books, all of
whose code is in the public domain (as stated in the book), you can
find all the code from the books here
http://www.acm.org/tog/GraphicsGems/
There are lots of 2D algorithms for all sorts of interesting geometrical
problems in the series, some of which may be useful to others. I've
definately found it useful.
Anyway, let me know if some changes should be made to the patch. Also
let me know if I missed anything in it.
-Anthony
On Wed, Jun 16, 2004 at 07:00:23AM +0200, Cyrille Chepelov wrote:
Le Tue, Jun 15, 2004, Ã 10:50:36AM -0700, anthonym overture com a écrit:
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.
geometry.* ? Oh. Probably, let's have a look at the code!
Anyway, if someone could let me know which is the current tag to submit
patches against I'll post it.
HEAD.
-- Cyrille
-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>
_______________________________________________
Dia-list mailing list
Dia-list gnome org
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://www.gnome.org/projects/dia/faq.html
Main page at http://www.gnome.org/projects/dia
--
_______________________________________________
Dia-list mailing list
Dia-list gnome org
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://www.gnome.org/projects/dia/faq.html
Main page at http://www.gnome.org/projects/dia
--
------------------------------------------------------------------------
Anthony Molinaro <anthonym overture com>
--
------------------------------------------------------------------------
Anthony Molinaro <anthonym overture com>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]