Bug 17557 - [rulers] Rulers should have dynamic width
Summary: [rulers] Rulers should have dynamic width
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P5 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-23 23:06 EDT by Randy Hudson CLA
Modified: 2019-09-06 15:37 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Randy Hudson CLA 2002-05-23 23:06:27 EDT
The line number ruler and Markers ruler should both resize based on the MAX 
number of digits or markers at a given line.
Comment 1 Kai-Uwe Maetzel CLA 2002-09-12 11:07:33 EDT
What are your ideas regarding the marker ruler?
Comment 2 Randy Hudson CLA 2002-09-12 12:04:54 EDT
The following icons can appear on top of each other:
breakpoint, bookmark, error, warning, maybe some others.

It doesn't make sense for an Error to hide a breakpoint, or a breakpoint to 
hide a bookmark.  In this case, the marker ruler should detect that its width 
needs to be 2 or 3 icons wide.  If this case doesn't occur, it could just be 
wide enough for one Icon.

There may be other ways to display all 3 decorations with less width, but I 
think it is rare to have more than 1 per line.
Comment 3 Claude Knaus CLA 2002-09-13 10:18:22 EDT
I personally don't like the idea to have wider vertical ruler just because one 
line happens to have multiple markers. A lot of screen real estate would be 
wasted. If you have a lot of markers (errors), then you would probably not care 
about the other markers anyway. In the case of a error and breakpoint, the 
breakpoint is irrelevant, since it's invalid anyway as long as the code is not 
correct.

Note that the hover is a textual representation of all the markers on the line.
Comment 4 Randy Hudson CLA 2002-09-20 09:23:07 EDT
The new @TODO support essentially adds yet another "priority" level to the 
list.  It might get difficult to define a fixed priority level that will 
display markers in the correct order.  For example, should @TODO's appear in 
front of compilation errors, since maybe the "undone" item is the cause of the 
compile error?

Maybe a single column can work if you allow either user-specified z-ordering, 
or use some heuristics to choose the best marker to be "on top".
Comment 5 Johan Compagner CLA 2003-07-23 14:28:47 EDT
This bug becomes more importand with the new feature light bulb when you have 
also a breakpoint on that line.

(If you double click to clear the breakpoint then the light bulb comes with a 
popup ect ect And then i can't see quite right if the breakpoint is still there 
or not)

Comment 6 Stephan Herrmann CLA 2009-06-29 19:28:16 EDT
I assume this issue is older than the option to expand icons in a hover?

In that case I guess only one thing remains to be wished:
make that option better visible.

Suggestion: as long as it is not enabled add a corresponding
action to the context menu that will enable the option 
(and tell you where you can disable it again ;-)

Comment 7 Randy Hudson CLA 2009-06-30 10:47:30 EDT
(In reply to comment #6)
> I assume this issue is older than the option to expand icons in a hover?

The expand on hover is not the same.  If you have warnings and todos in multiple places, it's difficult to tell whether breakpoints exist on those lines. Hovering over each line is no better than suggesting opening the problems/breakpoints view.
Comment 8 Johan Compagner CLA 2009-06-30 11:00:06 EDT
i am always searching for the option to change the priority of the things eclipse draws in that ruler

I want breakpoints to be always ontop of everything else there (except maybe an error marker)

But i cant seem to set this anywhere.
Comment 9 Stephan Herrmann CLA 2009-06-30 11:14:31 EDT
(In reply to comment #7)
> (In reply to comment #6)
> > I assume this issue is older than the option to expand icons in a hover?
> 
> The expand on hover is not the same.  If you have warnings and todos in
> multiple places, it's difficult to tell whether breakpoints exist on those
> lines. Hovering over each line is no better than suggesting opening the
> problems/breakpoints view.

Is that, you are still wishing for an expandable ruler?

I personally think these two views suffice:
 - If I want to find my breakpoints I use the breakpoints view
   (eagerly hoping for more structure in this view ;-)
 - If I want to see what's going on on a particular line of code
   I use the icon hover

As said in an earlier comment: expanding the width of the ruler only
because one or few lines have multiple markers (to me) feels like undue 
waste of screen real estate (even in times of bigger screens).

I could imaging the following feature would be cool: filtering
the ruler to show only particular icons - this would have to use
a very convenient gesture, like: mouse-wheel over the ruler.
I'd imagine the ruler to be restored (filter removed) as soon as
the mouse leaves the rule area. Or, to be able to go back to the
editor area and scroll: gestures like: shift-wheel selects filter,
keeps the filter until you release shift at what time it snaps
back to showing all icons.

You could think of the ruler as a cylinder which can be spun
using the mouse wheel, each "column" shows only one kind of icons,
but only one column is visible at a time.

Any one like this idea?
Comment 10 Stephan Herrmann CLA 2009-06-30 11:18:00 EDT
(In reply to comment #8)
> i am always searching for the option to change the priority of the things
> eclipse draws in that ruler
> 
> I want breakpoints to be always ontop of everything else there (except maybe an
> error marker)
> 
> But i cant seem to set this anywhere.
> 

I think that's statically specified by the plugin providing the marker?
See EP org.eclipse.ui.editors.markerAnnotationSpecification which has
a property presentationLayer (int).
Comment 11 Dani Megert CLA 2009-07-06 04:40:38 EDT
Re comment 8: no this is currently not possible, see bug 80089.
Comment 12 Eclipse Webmaster CLA 2019-09-06 15:37:18 EDT
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.