Community
Participate
Working Groups
I have a tool which generates warnings, such as methods without JavaDoc. The warning is at the method declaration. It only appears in the ruler. Whenever I want to find out what the warning is, I hover over the warning. But instead of seeing the tooltip, I get this annoying popup box with a breakpoint button and the warning beside it. So, I have to move mouse a little more, then wait for another hover event. It requires more mouse movements and time than the 2.1 version. Get rid of the popup box on mouse hover please. Especially if there is just one marker for that whole line.
Simply disable Preferences > Java > Editor, Hovers tab [] Enable annotation roll-overs to get the old behavior back. Tom, do you already have a bug report which describes the waiting for the hover? Once I have waited two times the hovers are immediate. Couldn't you pre-compute them so that I have to wait at least only once for the roll-over?
No, there's no PR about the waiting. It is the standard behaviour for tooltips: the first one has a timeout (to avoid flickering), after that, they will appear immediately. The real problem IMO is that the roll-over already has a delay, making it two timeouts to wait for. As we've discussed, the roll-over propably should pop up immediately. Whether the breakpoint affordance is the right thing to do is another issue.
I shouldn't have to go hunting through preferences to get things back to a happy state. I actually *like* the ability to see multiple markers at a given line, but I don't like the agressiveness of the toggle-breakpoint part of it. Again, switching the order may solve the problem.
Removing target milestone, no further action for 3.0.
It would be great if there were three ways to see markers instead of two: both current ones (only one marker column, with or witout rollover), and a new one in which the user could specify the space he wants to allow to the gutter, thus allowing to display multiple markers simultaneously. Shall I enter a new bug report for this enhancement request, or is it fine to discuss it here?
please file another bug report.
That bug report already exists: bug 17557
Moving back to inbox.
(In reply to comment #2) I'd like to revive this side-issue: > Whether the breakpoint affordance is the right thing to do is another issue. After years of not knowing about the option to expand icons in the ruler (it _is_ deeply hidden at a place that I didn't even find after I knew it is there - why is it not on the Annotations page?), I started using it but I dislike the behavior when only one icon is present in the ruler: why does the icon "expand" to two icons, showing the add breakpoint icon? I don't need a hover for that action -- I'll just double click if I want a breakpoint. When hovering over a single icon I want to see the icon's hover (e.g., details of a warning). That's completely different from seeing a mess of icons and moving the mouse over it to untangle. just my 2c.
(In reply to Stephan Herrmann from comment #9) > (In reply to comment #2) > > I'd like to revive this side-issue: > > > Whether the breakpoint affordance is the right thing to do is another issue. > > After years of not knowing about the option to expand icons in the ruler > (it _is_ deeply hidden at a place that I didn't even find after I > knew it is there - why is it not on the Annotations page?), > I started using it but I dislike the behavior when only one icon is present > in the ruler: why does the icon "expand" to two icons, showing the > add breakpoint icon? I don't need a hover for that action -- I'll > just double click if I want a breakpoint. > > When hovering over a single icon I want to see the icon's hover > (e.g., details of a warning). > > That's completely different from seeing a mess of icons and moving the > mouse over it to untangle. > > just my 2c. With recent discussion in bug 476676 this side-issue would become even more relevant as more people would be using the expand on hover feature.
(In reply to Stephan Herrmann from comment #10) > With recent discussion in bug 476676 this side-issue would become even more > relevant as more people would be using the expand on hover feature. I don't see it as relevant or blocking for changing the default. Personally I like the symmetry of having Add and Remove Breakpoint in the expanded hover.
(In reply to Dani Megert from comment #11) > ... Personally > I like the symmetry of having Add and Remove Breakpoint in the expanded > hover. Hm, I thought those icons were markers not buttons. Meaning: I definitely interpret the expansion as showing all the markers that are present at a given location, not as showing buttons for all possible actions at a location. (Wouldn't your reasoning require that the Add Breakpoint icon be shown in a hover even on locations that have no marker?) But mainly I'm worried that once this features is enabled by default, all users will have a broken experience of viewing the hover of a single non-conflicting annotation. What's the warning message behind this warning icon? What's the super method implemented/overridden by a given method? Instead of the answer I'm offered to create a breakpoint, what? (Yes, I know that I can still get the hover, but the first impression is: its broken).
We will take a look at this for 4.6. Plan is to immediately show the combined hover when the expanded hover opens.
If it is chosen to keep the bp button in the hover, I suggest that it be the last button in the list or, at a minimum, not the first. 1- I find that the first button in the list should be the top-most marker; that seems the most intuitive thing as I wouldn't have to move my mouse to click on the most visible action. 2- There is also a race condition when I put my mouse on a marker and then click. If I wait too long, the hover will trigger right before I click, and I may end up setting a bp instead of getting the action of the top marker (or getting both for some reason). If the top marker was the first button in the list, that would be avoided.
(In reply to Tom Hofmann from comment #2) > The real problem IMO is that the roll-over already has a delay, making it two > timeouts to wait for. As we've discussed, the roll-over propably should pop > up immediately. I think this issue will be more annoying if the first button of the hover is the top-most marker (suggested in comment 14), as the user will need to move his mouse ever so slightly to get the second hover to trigger at all. I fully agree the second hover should be shown immediately.
Some more observations regarding "Add a breakpoint": When a line has a big pile of annotations, the expanded hover showing all annotations certainly helps to figure out what that pile consists of - great, but checking if a breakpoint has been set on that line requires a very close look, because the hover *always* contains a breakpoint-ish icon. Just in some cases it's not an annotation but the "add breakpoint" button. If a line has a method-entry breakpoint, the hover even shows two breakpoint-ish icons: "Add a breakpoint", "Method breakpoint ..." On a similar note: bookmarks don't have the "add" button in the hover, either. For me all is pointing towards: removing the "Add a breakpoint" button would re-establish a consistency that otherwise would require several other changes and it would avoid one unnecessary level of hovers for the common case where there is only one annotation. Regarding the symmetry between add and remove: I would have never expected a hover to operate as a "remove me" button, nor can I see any visual cue about this functionality. It seems this really is an experts-only feature :) If I would expect any action from clicking the breakpoint icon, I'd expect that the breakpoint properties dialog opens. I think I'd really like that. Sorry, if this is stretching the topic of this bug. LMK if revision of the "Add a breakpoint" button has a chance of acceptance, and I'll file a new bug for it ...
(In reply to Stephan Herrmann from comment #16) > For me all is pointing towards: removing the "Add a breakpoint" button +1 I also find that the breakpoint icon in the expanded hover annoys me more than helps me. However, removing it does require to be careful with the double-click. If go to a line with two markers (two warnings, or a warning and an overrides, etc) and I double-click it should always set a breakpoint; I shouldn't trigger the action provided by the roll-over if the roll-over happens to pop-up right when I start double-clicking. If this is not done right, then setting a breakpoint will become more difficult and annoying.
(In reply to Marc Khouzam from comment #17) > (In reply to Stephan Herrmann from comment #16) > > > For me all is pointing towards: removing the "Add a breakpoint" button > > +1 > I also find that the breakpoint icon in the expanded hover annoys me more > than helps me. > > However, removing it does require to be careful with the double-click. If go > to a line with two markers (two warnings, or a warning and an overrides, > etc) and I double-click it should always set a breakpoint; I shouldn't > trigger the action provided by the roll-over if the roll-over happens to > pop-up right when I start double-clicking. If this is not done right, then > setting a breakpoint will become more difficult and annoying. Please take the following as me trying to help and not as me trying to add unnecessary pressure. I'm personally on the verge of turning off the expanded hover in my environment because the breakpoint part of it makes using quick-fix and navigation much more difficult. I'm saying this as a user, which makes me think other users may end up with a similar experience once the expanded hover is on by default, if the breakpoint button is part of it (or at least is the first part of it).
(In reply to Marc Khouzam from comment #18) > I'm personally on the verge of turning off the expanded hover in my > environment because the breakpoint part of it makes using quick-fix and > navigation much more difficult. I'm saying this as a user, which makes me > think other users may end up with a similar experience once the expanded > hover is on by default, if the breakpoint button is part of it (or at least > is the first part of it). We have support for the hover in CDT now but we (thanks William!) have moved the breakpoint as the last button of the hover. It seems to be much smoother. With this enhancement we have enabled the ruler hover by default in CDT: https://wiki.eclipse.org/CDT/User/NewIn91#Expand_Ruler_Icons
(In reply to Marc Khouzam from comment #19) > (In reply to Marc Khouzam from comment #18) > > > I'm personally on the verge of turning off the expanded hover in my > > environment because the breakpoint part of it makes using quick-fix and > > navigation much more difficult. I'm saying this as a user, which makes me > > think other users may end up with a similar experience once the expanded > > hover is on by default, if the breakpoint button is part of it (or at least > > is the first part of it). > > We have support for the hover in CDT now but we (thanks William!) have moved > the breakpoint as the last button of the hover. It seems to be much > smoother. With this enhancement we have enabled the ruler hover by default > in CDT: > > https://wiki.eclipse.org/CDT/User/NewIn91#Expand_Ruler_Icons An improvement, but not a solution, if you ask me. - will still "untangle" a single marker into marker & add breakpoint button - may still have breakpoint marker & add breakpoint button in the same hover - still mixes markers and buttons without a visual clue which is which Is the hover of the first marker shown immediately when the popup appears? That would at least avoid the double wait-for-hover just to see a detail hover (e.g., an error message).
(In reply to Stephan Herrmann from comment #20) > Is the hover of the first marker shown immediately when the popup appears? > That would at least avoid the double wait-for-hover just to see a detail > hover (e.g., an error message). Yes the hover message of the first marker shows immediately. This was also an improvement done for CDT.
(In reply to Marc Khouzam from comment #21) > Yes the hover message of the first marker shows immediately. > This was also an improvement done for CDT. BTW, we are hoping to contribute these improvements as patches to JDT, but I don't believe time has allowed yet.
(In reply to Marc Khouzam from comment #22) > (In reply to Marc Khouzam from comment #21) > > > Yes the hover message of the first marker shows immediately. > > This was also an improvement done for CDT. > > BTW, we are hoping to contribute these improvements as patches to JDT, but I > don't believe time has allowed yet. I'm hoping to have the time to contribute back the fixes I made for CDT in the next month or two. There is also a bug with breakpoint tooltips that I found after finishing the CDT port, which I also need to look into a fix for (CDT bug 504310).
Let's cast a vote: Should we remove or keep the "add breakpoint" thingy? ( ) REMOVE ( ) KEEP I vote REMOVE, because the concept of this hovers should be: show all markers on this line in an expanded hover as a simple means to unclutter a pile of markers. No more no less. "Add breakpoint" is not a marker. A single marker does not need a hover for uncluttering, as it is not cluttered in the first place.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
