Community
Participate
Working Groups
3.4.1 When you resize the workbench window it is possible to get into a state where the line number widget is not shown just before wrapping. This is an issue for screen readers as they walk the visible widgets and then report on thier contents. As the line number is an important piece of information for people who cannot navigate visually it can make the editors much harder to use. There is no redraw function such as reset perspective to correct this as far as I could find.
Created attachment 125138 [details] Screenshot
Tried for 10 minutes bug cannot reproduce using I20090210-0950. If you can, please provide more detailed steps and reopen.
Dani please see the screenshot I provided. This is actually pretty easy for me in 3.4.1 - did you try that or 3.5? All I need was open a java file with the default perspective and gradually made the window narrower. On 3.3.2 it is easier to do because the window doesn't wrap.
As stated in comment 2 I used I20090210-0950, and yes I looked at the picture but that doesn't help me reproduce it. I just repeated your steps and it works here. So there must be something else.
Created attachment 125380 [details] Image with line numbers
Tod, I guess you didn't actually mean line numbers in the editor, but the caret position item showing "line : column" in the trim, right? If so, please fix the summary and move this bug to the component that lays out the trim, i.e. Plat/UI.
Now I see the confusion. It is the line number in the trim we are talking about not the numbers in the java editor. I thought the title was obvious but I can see the description should have been clearer. I can make it happen with 3.5 M4 as well. I am using a 1600 x 1200 display and it happens to me with both regular and large fonts. The point at which it disappears is just before the wrapping happens.
Not sure why this went to text as it is a trim issue. Martin I left the summary as is as it mentions trim.
Sorry, given that Boris sent this down to text and I quickly read comment 0 I applied it to the ruler. > As the line number is an important piece of >information for people who cannot navigate visually it can make the editors >much harder to use. I suggest that they enable the line number ruler then ;-)
> Martin Markus > I left the summary as is as it mentions trim. I fixed the summary as this is not about line number*s*. Assigning back to the UI inbox.
Sorry for misfiling this - like Dani, I just read the description, looked at the screenshot, and thought it was about the line number ruler (in the "editor trim" :-).
The issue is that the current 'minimum' size for the StatusLine is too small, this is what causes the clipping you've observed. The basic problem is to determine what value would allow the necessary information to show up (and identifying what information is 'necessary'). Simply using compute size doesn't cut it because it assumes that we have infinite space and will return values that cause the trim to wrap under normal working conditions (which is guaranteed to get a lot of pushback). Any suggestions?
The problem is non-trivial as different users might see different status line fields to be essential. Me for example would hate to see the normal text clipped in favor of the column:line information. I think the simplest solution would be to allow user to lock each field individually. Locked meaning it get's priority over non-locked fields and maybe even disallow to make the window smaller than the sum of all locked fields.
Thats a great idea Dani. From a blind persons perspective the line number is the most important entry but I almost never look at it. Progress on the other hand is the most important for me.
While this is a good idea how many people do you think would actually use it? Note that this is would involve a deep rewrite of the StatusLine mechanics in order to solve a particular corner case, is it really worth it? As an alternative to solving this particular issue (vision impaired folks needing the line number) couldn't the Text editors add line (and column?) info to their accessibility string?
Eric the trim is read with a different command - if they want line numbers all of the time they would turn on the line numbers feature. This is only used by people who check the line number occassionally when they get lost.
After talking with Tod yesterday I have an alternative I think. Tod says that there's a command that reads the StatusLine and that those that need to bind to it. What if we provided a command that causes the reader to emit the information? A nice generalization would be to provide a parameterized 'context' command, allowing the user to select what they want from a variety of fields. That way they can have a binding that is editor specific and gives the current editor's name and the row/column and perhaps have a second one that would give a more generic context like active editor and active view. This would be a start to providing 'first class' support to visually impaired folks and provide them a place to ask for enhancements specific to their needs (by asking for more 'fields'), something they'd appreciate I'm sure. I'm not sure technically how to get the reader to 'speak' a particular string (use a temporary ToolTip?) but it's gotta be doable. IMO, we shouldn't be relying on the StatusLine, which has a lot of (to them) unneeded information on it.
>binding that is editor specific Should be part specific as views can also have status items. Maybe we could use one of the Accessible*Listener/s?
Dani, I was thinking of a command that wouldn't be based on the status line at all, just 'data'. Exactly what information would be available is TBD but would include at least the current editor's line and column info in order to handle the specific scenario in this defect. Saying 'editor specific' may have been misleading...i was using it as an example that the clients could reuse the same command to provide different sets of feedback based on what they need to know under different circumstances... NOTE: the following is but one possible way to 'format' the data, in this case we should define the UI for determining what gets 'echoed' based on feedback from the visually impaired community (who would be using it). Imagine a new command 'SpeakToMe' that takes a single parameter 'echoString' which is a formatted string containing replacement tokens (a la the templates). To handle the specific scenario in this defect the string might be "Editor $(activeEditorName) Row $(row) Column $(column)" They might also want a 'general context' version that would be useful when arriving at work on Monday just to let them figure out where they were "Workspace $(wsName) Perspective $(perspName) View $(activeViewName) Editor $(activeEditorName)"
I guess before pushing forward on this we should discuss this with an accessibility expert.
I agree...
Just to capture some of the information we gathered while looking into this: There is currently no viable mechanism to have JAWS 'speak' a string, it's a screen scaper with a lot of built-in keyboard 'command' hooks. Simply using our own code (or some open implementation) speak the string directly (i.e. bypassing the screen readers totally) may work but would lack support for Braille readers (screen readers evidently can either emit the string aloud or by showing in on a braille tablet... Looks like we should wait until we can get direct screen reader support before going down my suggested path. A question: Is it worth hacking the StatusLine so that it won't shrink the string containing the <line> : <column> field?
I don't want to lock just that concrete item without having a way for people to unlock (or better lock) it via UI.
Well, so many things got wrong here it is actually funny. First, the actual control on the status bar is a CLabel (StatusLineContributionItem#fLabel). The CLabel shortens the text it displays by adding "..." when needed. The CLabel has a proper override for accessibility that supplies the full text (not the shortened text it displays) to a screen reader. The problem is that nobody seems to be reading that. Jaws in response to Ins+PageDown reads the text on the last line and does not go through accessibility interfaces. Hence, Jaws gets truncated text (or no text) when Eclipse window sized too small. This is true for other applications too, even MS Word. The difference is that MS Word has the line & column number as the first widget on its status bar so it is rather hard to get it cut off. Also, Word and some other apps support separate Ins+Del keybinding which in Jaws produces line number and column number. Which bring us to the question on how this can be fixed. I don't like the idea of "locking" sizes of status bar elements. It will be rather non-intuitive. Code-wise it will be a sizable feature with no other driving force other than "we need to be able to get line & column number when the window is small". I'd prefer to see if we can supply the line & column number to a screen reader in some other way. For instance, Word and Symphony support Ins+Del key combination with Jaws specifically to read line and column number. (Even when the line & column number are visible on the Eclipse status bar, there is a lot of other information in there that gets read.)
Note for future - some code locations of interest to this bug: => The line and column number are calculated here: AbstractTextEditor#updateStatusField(String category) if (ITextEditorActionConstants.STATUS_CATEGORY_INPUT_POSITION.equals(category)) text= getCursorPosition(); => The control's text is set in StatusLineContributionItem#updateMessageLabel() => CLabel's accessibility override: CLabel#initAccessible() => StatusLine layout: StatusLine#StatusLineLayout, this turns on / off ellipses: // Take space away from the contributions first. for (int i = count - 1; i >= 0 && diff < 0; --i) { int min = Math.min(ws[i], -diff); ws[i] -= min; diff += min + GAP; }
(In reply to comment #24) > The problem is that nobody seems to be reading that. Jaws in response to > Ins+PageDown reads the text on the last line and does not go through > accessibility interfaces. To clarify: when Jaws receives Ins+PageDown, it reads the text on the bottom of the applications window which is, usually, the status line. However, because it reads the text, without consulting underlying controls, it literally reads what is visible on the screen. So, if the status bar has control with the word "English" cut off so that only "En" is visible, Jaws will only read "En". Since 3.6 we set accessibility role of the status line to indicate that it is, indeed, the status bar, using IAccessible2, but it seems that Jaws does not use that.
*** Bug 348680 has been marked as a duplicate of this bug. ***
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
