Community
Participate
Working Groups
Currently the modeling bridge does not support hiding elements that are inside another element (compartment?) See bug 357742. This isn't actually that common a usage case for many diagram types, but it will certainly come up, and we need to support it. (There are some complexities that make this task a little more involved than it might first appear.)
Carsten, again just wondering if you might have already addressed this?
Miles, that could very well be. I'll have to check. Unfortunately I'll be out of office until friday... (but if my conference wlan doesn't suck too badly, I'll try and take a look before that...)
Miles, sorry for taking so long that this doesn't make it into Juno anymore... Unfortunately, this wasn't fixed by the other change. But I pushed a fix to Gerrit now, that should address the remaining coordinate related issues: https://git.eclipse.org/r/#change,6378 I had to remove the special logic for ShapeNodeEditParts in NodeDecorator, because this heuristic doesn't work properly in many cases (e.g. it messes up classes in nested packages in ecoretools). Also, I noticed the commented out color logic in NodeDecorator. I restored that because I didn't see it causing any problems and it looked a lot better (but still ugly) on darker backgrounds (again, like packages).
Created attachment 217446 [details] mylyn/context/zip
(In reply to comment #3) > Miles, sorry for taking so long that this doesn't make it into Juno anymore... > > Unfortunately, this wasn't fixed by the other change. But I pushed a fix to > Gerrit now, that should address the remaining coordinate related issues: > https://git.eclipse.org/r/#change,6378 > > I had to remove the special logic for ShapeNodeEditParts in NodeDecorator, > because this heuristic doesn't work properly in many cases (e.g. it messes up > classes in nested packages in ecoretools). Yes, much less ugly. See code review. > Also, I noticed the commented out color logic in NodeDecorator. I restored that > because I didn't see it causing any problems and it looked a lot better (but > still ugly) on darker backgrounds (again, like packages). I think the color issue might be one of those that isn't that obvious to begin with. I actually went so far as to mock up a number of different options, see attached png that should have been on a bugzilla but didn't end up there..
Created attachment 217509 [details] Poetnetial issue. OK, this was the issue I was seeing when I had the background color as non-white. Let's jsut check that this works properly for all fading and selection cases.
The screenshot actually shows two issues. 1) The "tearing" at the right side of list elements - this is caused by the removed code. I'll see if I can find something based on the parent's LayoutManager that works properly for list elements as well as for nested nodes 2) The dark yellow color: In this special case, with a white diagram background and a relatively light node gradient, white looks better. With other combinations it looks pretty strange though. See attached screenshots.
Created attachment 217513 [details] Issue with white overlay This shows the white overlay on a nested package
Created attachment 217514 [details] Overlay in background color And here's the overlay in background color (with an additional fix for partially revealed elements). Not really pretty, but a bit nicer than white maybe (esp. in cases without a gradient).
(In reply to comment #9) > Created attachment 217514 [details] > Overlay in background color > > And here's the overlay in background color (with an additional fix for > partially revealed elements). Not really pretty, but a bit nicer than white > maybe (esp. in cases without a gradient). Yea, I don't think we can do anything about the gradients. I a way, if we can't hide the stuff completely, it really makes the usefulness of the whole thing. The way I saw this when I was first building it was as balancing a tradeoff between covering all cases pretty well, and covering the common case as well as possible, and sort of punting on the the other issues. Obviously, I went for the latter strategy, aka "make the demos look as pretty as possible". :) (To be clear, the image I included was not how it is currently functioning, but one option that we discarded.) But yeah, the problem is that the non-white background cases end up looking really yucky. Your solution does look a lot better for the package case, but it isn't the common case. (That was my justification for putting it to back of priority list.) And this actually reminds me of why I had that other special cased code in there. The hand changed pixel counts were meant to get the text boxes all the way to each end. That's key, because its what prevents the missing lines form being obvious. Perhaps we could make the changes you suggest and then still manually adjust the edges for the common case? All of this makes me wonder.. about the possibility of rethinking the approach for colored items altogether, by actually getting rid of the issue entirely. Here's the (radical) idea: When we're in Task-Focussed mode, we simply turn off all background coloring! At the least this could be a really good way to go with getting rid of the gradient for the decorated figure.
You know, I think not hiding contained elements is fine. After playing with the revleaing behavior for nested figures, I think it looks good to revealthe whole contained package, and it would actually be sort of confusing to try to hide individual items. It's somewhat analagous to the behavior for classes. So I'm thinking of closing as a "won't fix". +1 or -1?
In terms of consistency, the Java bridge tracks interest for fields and methods separate from the container class. This is used for folding for instance where we show the class but methods and fields are folded unless interesting. Diagrams might be different but unless there are clear reasons why we can't support this I would just mark it P4 and put it on the backlog.
(In reply to comment #12) > In terms of consistency, the Java bridge tracks interest for fields and > methods separate from the container class. This is used for folding for > instance where we show the class but methods and fields are folded unless > interesting. Diagrams might be different but unless there are clear reasons > why we can't support this I would just mark it P4 and put it on the backlog. No, it's not an issue of "we don't want this" so much as "we can live without it". Note that this is in diagram display only and only when you are looking at a deeper level. It isn't really analogous to a tree presentation. What does Mylyn mean by "WONTFIX"? I had an interesting back and forth with Platform about a bug they had marked as WONTFIX. My interpretation was "this will never happen". Their interpretation was "we aren't going to do this anytime soon".
Wontfix usually indicates that a bug is not considered to be in scope of the project or that based on the discussion it was decided that the bug wouldn't be resolved (e.g. due to privacy concerns, UI consistency, etc.). In the past we have leaned towards keeping bugs open that we weren't going to actively work on to encourage further discussion, voting or community involvement. Over the years this resulted in a huge backlog with hundreds of bugs which requires quite a bit of maintenance effort. These days, I close bugs as wontfix when I feel that that the requested feature would only be valuable to a very small number of consumers. That's obviously a subjective judgement and I have been wrong and of course we reopen bugs if anyone objects with a meaningful argument. I'm fine with triaging the bug either way. I guess the MFT backlog is still reasonably small and it's good to have a few enhancement requests around for people to look at but please feel free to close the bug based on your judgement.
In the sense of "we can live without it" I'm fine either way, too. 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...
(In reply to comment #15) > In the sense of "we can live without it" I'm fine either way, too. > > 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... Don't get me wrong. If we can fix it that would be great. :) I'm really not sure how we can "ever" solve the edge reveal issues short of a lot of crazy complex hacking along the lines of what we'd need to do to solve the visual glitches from overlap of edges now. That's all just due to having to fake alpha. So I guess I'd say that my general philosophy here has been to not let the enemy of the good be the perfect. The ultimate aim of course is to reduce visual clutter and complexity. I like how the entire package is reveled at once, and I think regardless we might want to juice the contained items when we select. Steffen, in a way I think a better visual analogy might be when you open a tree using the option-click in Mylyn. There is opens all of the items so you can see the set of things you want to select from. In that case, it might be better to dynamically reveal everything, but simply show the focussed items only on mouse exit. That might simplify the coding.
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
