Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 357895

Summary: [modeling] Support Attributes and Operations inside of Class Parts
Product: z_Archived Reporter: Miles Parker <milesparker>
Component: MylynAssignee: Miles Parker <milesparker>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: b.muskalla
Version: unspecified   
Target Milestone: 0.9   
Hardware: Macintosh   
OS: Mac OS X   
Whiteboard:
Bug Depends on:    
Bug Blocks: 351889, 357766    
Attachments:
Description Flags
Demonstrates potential solution
none
Mask with Diagram Background
none
Mask with figure Background
none
Ecore example diagram
none
Ecore sample diagram file
none
overlapping edges none

Description Miles Parker CLA 2011-09-15 20:15:27 EDT
We'd like to be able to have individual class members masked by default. This would be a nice, fairly simple addition, and I think good to have in the initial deliverable.
Comment 1 Miles Parker CLA 2011-09-15 21:12:27 EDT
Created attachment 203463 [details]
Demonstrates potential solution

OK, I experimented with one approach to handling this. This might also help with the package issue. But I'm a little hesitant about it — because the background is gradiated and the lables are not full width, I think it looks kind of cheesy.. thoughts?
Comment 2 Miles Parker CLA 2011-09-15 21:59:11 EDT
Created attachment 203464 [details]
Mask with Diagram Background
Comment 3 Miles Parker CLA 2011-09-15 21:59:39 EDT
Created attachment 203465 [details]
Mask with figure Background
Comment 4 Miles Parker CLA 2011-09-15 22:01:48 EDT
OK, I think I've found two approaches that work pretty well and that are probably worth doing. Of the two last ones, does anyone have a preference?
Comment 5 Steffen Pingel CLA 2011-09-16 05:27:55 EDT
I like the last screenshot best.
Comment 6 Miles Parker CLA 2011-09-16 13:39:18 EDT
Yeah, so did I -- but after asking this I spent some more time playing with it and the second one works much better in terms of interface and transition. The gradiant fill that is being used by the GMF nodes makes things look pretty odd otherwise. you might try it on the ecore model and let me know what you think.
Comment 7 Miles Parker CLA 2011-09-16 13:41:02 EDT
Created attachment 203507 [details]
Ecore example diagram
Comment 8 Miles Parker CLA 2011-09-16 13:41:42 EDT
Created attachment 203508 [details]
Ecore sample diagram file
Comment 9 Miles Parker CLA 2011-09-16 13:42:19 EDT
I've attached the ecore files (actually mangled, but that shouldn't matter) for better usage testing.
Comment 10 Steffen Pingel CLA 2011-09-16 16:58:40 EDT
Created attachment 203533 [details]
overlapping edges
Comment 11 Steffen Pingel CLA 2011-09-16 17:01:40 EDT
Looks pretty cool! I just noticed an oddity when edges overlap.

I would suggest removing the decoration when the mouse leaves the diagram editor. I find that the half faded elements looks a bit odd when I navigate to the toolbar or other elements in the workbench.
Comment 12 Miles Parker CLA 2011-09-16 17:30:28 EDT
(In reply to comment #11)
> Looks pretty cool! I just noticed an oddity when edges overlap.

Thanks. Yeah, that's an oddity that I'm hoping that not too many people notice, because there isn't much we can do about it without even more fiddling -- and there was a lot of fiddling to get to this point. :) Without getting into all the details :) and after much experimentation, this is the workable strategy I found.

First some background..

1. GEF consumes mouse events, which means that we need to get an SWT mouse listener into the picture. This is an "engineer-around" approach that I discovered a while back.
2. To do this we can't use the built-in GEF figure mouse detect anymore.
3. We still ned to attach these to figures on the diagram, so we create dummy figures that can then be referred to from the mouse to determine distance from the line.
4. Because of the way GMF handles points for connections -- they're sort of faked -- and the way decorations work, we can't attach those figures to the points, we have to use just the end-points. But this ended up being better anyway because it means that stray lines that happen by items aren't shown, instead we end up basing distance on the minimum distance to the endpoints/anchors. It also looks cool because you get that kind of ray effect under movement. 
5. We can't change Z-order for components including the connections without monster GEF/GMF hacking.

All that ends up causing the whited out edges under the following scenario:

1. Orthogonal edge layout so that edges are either vertical or horizontal.
2. Edges that connect distinct nodes overlap.
3. The edge farthest away happens to be the top-most.

Then the top-most edge is furthest away and (in the case of a white background) is thus lightest, obscuring the darker edge below.

> I would suggest removing the decoration when the mouse leaves the diagram
> editor. I find that the half faded elements looks a bit odd when I navigate to
> the toolbar or other elements in the workbench.

Yes, agreed. We'll go to all masked when we leave the editor.
Comment 13 Miles Parker CLA 2011-09-20 13:07:10 EDT
(In reply to comment #11)

> I would suggest removing the decoration when the mouse leaves the diagram
> editor. I find that the half faded elements looks a bit odd when I navigate to
> the toolbar or other elements in the workbench.

See bug 358276
Comment 14 Miles Parker CLA 2011-09-20 13:33:46 EDT
Closing. Don't know if it worth opening another bug to track the fact that we can't / won't fix the edge overlap issue at least for now.