Community
Participate
Working Groups
The nodes are properly colored but not the edges.
I'm going to take this out of current release. It's just not that big of a deal right now as we aren't supporting packages anyway, see bug 357742.
Carsten, I'm wondering if you might have fixed this as part of your support for internal packages?
Miles, again have to check. Will do so until Friday. Although IIRC we did not touch anything color related, just the coordinate translation for hit testing...
Now that I think about it, it is unlikely that you would have. This is actually a fairly significant undertaking; the way that we're making the fade effect work is by faking an alpha channel and interpolating the colour. We'd have to interpolate against the actual background of the current edge, which would mean some fancy GMF footwork just to discover what the backing shape is. Not to mention that there might not actually be a single backing shape, which means that we would have to punt on the whole thing. If there is a single background colour we're matching, that isn't such a big deal. The upshot
Whoops -- bugzilla web ui takes "Return" to mean "Submit".. anyway, as I was in the middle of saying.. The upshot is that we should tackle this as part of a future release plan. I'm setting back to New and unassigning myself.
I've dug around a bit. First, this is an issue for nodes, too. So maybe we should change the description of the bug... (see NodeMaskingFigure constructor and ecoretools diagrams: just filling a rectangle won't work for more complex backgrounds like gradients etc) Second, maybe you've already tried/considered this before implementing the current solution (overlay nodes and changing line colors), so stop me if I'm getting off track here. But couldn't we actually get the nodes that are to be hidden to do just that as part of the decoration process instead of using overlays/colors? I.e. one of 1) hide with setVisible(false), restore with setVisible(true) and setAlpha(xxx) for RevealMouseListener 2) dto but hide with setAlpha(0) 3) I actually played around with the NodeMaskingFigure trying to get the proper background figure to repaint its contents (sans the masked figure) on the NodeMaskingFigure's graphics. Wasn't looking too bad in the simple case, but it's hard to set up the Graphics correctly, esp. when scaling comes into play...
Damn, scratch 1) and 2). Didn't see that setAlpha() was only a method of Shape...
(In reply to comment #7) > Damn, scratch 1) and 2). Didn't see that setAlpha() was only a method of > Shape... Yep! That's why the funky work-around. There were a lot of cases like this where I had to do some major graphics hacking. So we're faking alpha here. That's the reason for a lot of the complexity / weird indirection. Spent an embarrassingly significant amount of time getting this all to work as it does now. Ended up trowing a lot of code out. 3) would be really neat if you could get it to work! But you'd still have the problem of getting the gradations to work, right?
Idealy, the parent figure would just paint itself onto the overlay, gradient and all. I have something mocked up which is looking pretty good, but relies on actually setting the decorated node's figure to visible=false. Are you aware of any issues that might cause (e.g. with some EditParts/EditPolicies)?
(In reply to comment #9) > Idealy, the parent figure would just paint itself onto the overlay, gradient > and all. I have something mocked up which is looking pretty good, but relies on > actually setting the decorated node's figure to visible=false. Are you aware of > any issues that might cause (e.g. with some EditParts/EditPolicies)? So I *think* I explored that approach and discarded it, but I can't be sure, sorry. Perhaps the major issue was that you can't edit it. And since the figure doesn't exist, you won't be able to manage any incoming edges. Also you need some way of setting it to fully visible by the time you get to mouse-over, and IIRC managing that transition smoothly is tricky. So much of this code was trial and error -- I wish that I'd thought to push all of the discarded changes that I'd tried.
Carsten, if you still have a fix to look at, can you push it up to gerrit so I can take a look?
That was the same code I was referring to in my last comment on bug 358489: "When I left this, I had some early version of code that faked true transparency for the reveal mechanism, solving the color issues. However, I made a mess of it in the last experiments I did and I'll need some time to get it into shape to push something for review..." However, I might manage to get a look at things next weekend.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
