This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 78324 - Orthogonal layout should not attach messages to thin side of forks and enlarge the side
Summary: Orthogonal layout should not attach messages to thin side of forks and enlarg...
Status: RESOLVED WONTFIX
Alias: None
Product: uml
Classification: Unclassified
Component: Diagram Activity (show other bugs)
Version: 5.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: issues@uml
URL:
Keywords:
Depends on:
Blocks: 79684
  Show dependency tree
 
Reported: 2006-06-19 21:48 UTC by bugbridge
Modified: 2008-06-12 00:04 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Activity Diagram - Edgesfrom fork to nodes (43.20 KB, application/octet-stream)
2006-08-10 19:21 UTC, Thuy.d Nguyen
Details
Activity diagram - orthogonal layout (53.63 KB, application/octet-stream)
2006-08-10 19:23 UTC, Thuy.d Nguyen
Details
for 3rd step, dotted red is expected result (43.20 KB, image/png)
2006-08-11 09:50 UTC, Sergey Petrov
Details
for 4th step, thin fork side is enlarged and some edges are connected to thin side, expected: all incoming edges on one long side and all outgoing on second (32.15 KB, image/png)
2006-08-11 09:52 UTC, Sergey Petrov
Details
orthogonal layout result (17.35 KB, image/png)
2008-05-23 00:44 UTC, Peter Lam
Details
hierarchical layout (11.50 KB, image/png)
2008-05-23 00:45 UTC, Peter Lam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bugbridge 2006-06-19 21:48:52 UTC
Original submitter: sergeyp

Description
steps to reproduce:
1. create activity diagram
2. add 3 invocation and a fork
3. draw edge from one invocation to the fork and edges from fork to two others
looks bad because links aren't orthogonal to the fork
4. press orthogonal layout toolbar button

BUG: some links are connected to thin side of fork if there are more links thin
side can be enlarged.
Comment 1 Thuy.d Nguyen 2006-08-10 19:21:59 UTC
Created attachment 32776 [details]
Activity Diagram - Edgesfrom fork to nodes
Comment 2 Thuy.d Nguyen 2006-08-10 19:23:02 UTC
Created attachment 32777 [details]
Activity diagram - orthogonal layout
Comment 3 Thuy.d Nguyen 2006-08-10 19:26:39 UTC
I don't see anything bad as described in step 3.  The egdes from the fork to the
invocation nodes look fine to me.  Please see the first attachment. 

Regarding the Orthogonal layout mentioned in step 4, this is how the layout is
made by TomSawyer.  This is not a  defect.  Plus, if there are multiple links
connected to the fork, the layout will arrange the links accordingly wihout
enlarging the fork.  See the second attachment.
Comment 4 Sergey Petrov 2006-08-11 09:49:18 UTC
see UML2.0 specification (superstructure) in most cases edges ortohonal to forks
at list on incoming/outgoing ends, it also looks much better then all links from
center.
see your second attachment right fork, thin side should be used by edges
Comment 5 Sergey Petrov 2006-08-11 09:50:38 UTC
Created attachment 32810 [details]
for 3rd step, dotted red is expected result
Comment 6 Sergey Petrov 2006-08-11 09:52:35 UTC
Created attachment 32811 [details]
for 4th step, thin fork side is enlarged and some edges are connected to thin side, expected: all incoming edges on one long side and all outgoing on second
Comment 7 Trey Spiva 2006-08-11 14:16:02 UTC
You are correct.  However, with the version of Tom Sawyer that we are using, we
are not able to make sure that the nodes are orthogonal while the user is
drawing the diagram.  So, we are not able to fix this issue at this time.
Comment 8 Andrew Korostelev 2006-08-11 16:51:15 UTC
Does TS hav version that provides API to control mountpoints?
Or we have ability to force this feature creation?
Comment 9 Trey Spiva 2006-08-11 17:01:35 UTC
Yes, our current version always you to specify the mount points.  That is not
what you want.  Instead you want automatic edge layout as the user draws the
link and as the user moves nodes connected to the edge ends.  We we specify the
mount point it would be up to us to adjust as the uesr moves nodes around.  Not
an impossible task, however we know we want to move to the NetBeans graph
framework and it already support automatic edge layout.  

Basically when we move to the NetBeans graph component this problem should be
solved.
Comment 10 Andrew Korostelev 2006-08-11 17:23:56 UTC
That's good.

Actually impossibility to change mountpoint manually was mentioned in 79684
(marked as duplicate of this isssue):
"it should be possible to reconnect link to any point on fork".

Comment 11 Peter Lam 2007-03-20 23:15:42 UTC
low use case not currently impacting our installed user base.
Comment 12 George Vasick 2007-05-17 18:48:24 UTC
Planned for drawing area upgrade after NB 6.0.
Comment 13 George Vasick 2007-05-18 00:45:29 UTC
Should not use resolved/later status.
Comment 14 George Vasick 2007-06-28 21:43:06 UTC
Targeted in the drawing area redesign.
Comment 15 George Vasick 2007-07-04 00:43:58 UTC
REstoring the original priority and using the NB 6.0 waiver process.
Comment 16 George Vasick 2008-01-02 16:54:09 UTC
Diagram area bugs waived for 6.0 will also be waived for 6.1.
Comment 17 Peter Lam 2008-05-23 00:42:11 UTC
with the latest 6.5 build, the results are still not looking good with both the available orthogonal and hierarchical
layouts. See attached screenshot for these results.
Comment 18 Peter Lam 2008-05-23 00:44:00 UTC
Created attachment 61791 [details]
orthogonal layout result
Comment 19 Peter Lam 2008-05-23 00:45:48 UTC
Created attachment 61792 [details]
hierarchical layout
Comment 20 George Vasick 2008-06-12 00:04:00 UTC
Orthogonal layout will not be included in 6.5.  It may be reimplemented in a future release.