After Ctrl+Q (Quick documentation) I could not see all text. I have to scroll horizontally to see all content. I could not make the editor to fit the window.
UPDATE:
The problem is only symbol definition, ie. the first line. The description (block text) is wrapped correctly. Actually, I don't want to resize this window as I prefer to keep it as I write in the same position for quick reference. I have to add that my monitor is quite small (15-inch) which is probably causing the problem.
Indeed method signature in the popup is not wrapped. There is a request you can vote for: IDEA-169414.
UPDATE: The documentation popup is reworked in 2018.1 and it should be fixed.
I'm not aware of a way to configure IntelliJ to wrap text in these windows.
I think the quickest way to see the full line in the quick documentation window is to press Ctrl+Q again to make it a little bigger (and center it) or maximize it with Ctrl+Shift+"
Keep in mind that the smallest version (the one that appears after the first Ctrl+Q) can be resized by hovering the mouse cursor over its edge and dragging it. It's going to retain the same size the next time you open it.
Related
While doing accessibility sanity checks, I like to ensure to provide appropriate guidance for developers to correct anything that is reported as problematic or incorrect.
In this case, their implementation of a tooltip was incorrect. So I set to use MDN's documentation (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Tooltip_Role) as a reference.
But before simply sharing that, I tested MDN's code example with VoiceOver myself, and I discovered something curious:
List elements (<ul> in MDN's example) are not actually read by the screen reader. I tested with VoiceOver on Chrome and Firefox, and they both read the tooltip content as expected.
Does anyone know if this is a Safari bug, or if there is anything to ensure to do in the markup to ensure the tooltip content is read?
Here is a link to test: https://htmlpreview.github.io/?https://github.com/jansensan/test-a11y-tooltip/blob/main/public/index.html
Here is the code: https://github.com/jansensan/test-a11y-tooltip/blob/main/public/index.html
Edit: To clarify, I currently tested this on macOS Ventura with Safari, Firefox, and Chrome. The issue of VoiceOver not reading the content happens on Safari (weirdly enough). It skips the list altogether (I added paragraphs , <p> before and after the list to see what it would read).
There are two different situations here.
Descriptions only need to be read as a flat string
According to ARIA’s Text Equivalent Computation, exposure of the referenced structure is not required:
The purpose of the computation is to create a perceivable label or description for alternative presentations, in the form of a flat string of space separated textual tokens.
So this concerns the text read when focus is on the input—provided the user activated announcement of descriptions in their settings.
Reading the tooltips content by moving reading cursor onto it
If the reading cursor is moved onto the tooltip widget itself, the whole contents must be read, including structure. It would be surprising if Safari didn’t do that. If it doesn’t, it’s a bug.
Tooltips must stay open on hover
Both tooltip examples have one issue, though: They fail WCAG Success Criterion 1.4.13 Content on Hover or Focus, because they close when trying to move the mouse pointer on them.
Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
It’s a reflex of mouse users to hover content they are reading, independent of screen reader use.
I am using IntelliJ Idea for developing scala and Java programs. I am also a screen reader user.
One of the most useful features that IDEs provide is code linting and displaying error and warnings in your code, along with descriptions. I understand if you are a sighted user, you can just hover your mouse over an erroneous line of code and you get a tooltip with the description.
I haven't been able to figure out how to access this description as a screen reader users. So far, to review errors/warnings I would just build the program and look at the command line output, however this is pretty inefficient compared to just hovering over line of code.
Could someone share a better way of reviewing errors/warnings in IntelliJ using a screen reader? Ideally how to access the error tooltip, or how to access a better UI for reviewing them instead of looking at raw command line output.
I'm not sure about warnings however errors can be accessed in two ways:
Firstly when the caret is moved into a line with error the error text is written into the status bar - the problem with this approach is that for JAB applications screen readers are generally unable to find it, so in case of NVDA object navigation has to be used.
The second way requires your caret to be exactly at the point with error - generally it would be set in the proper place if you've navigated to the line with F2. After that you need to press CTRL+f1 - focus moves to the unnamed pane and the error text is its first descendant so once again you need to employ object navigation. I haven't found any reasonable way to access error texts with JAWS sadly.
Importantly, make sure to turn on screen reader support:
settings (ctrl + alt + S) > appearance and behaviour > Appearance > Support screen readers (requires restart)
Then when your caret is on an error/warning, you can press ctrl + F1 and a dialogue will pop up with the description. Press escape to close it.
If you want to make sure the caret is on an error/warning, use F2 to jump to next error/warning.
As noted by lukaszgo1 in his answer, the description is also printed to status bar, but NVDA cant find it using its normal command, because JAB GUI applications are lacklustre in their implementation of accessibility, however if you want to access the status bar of IntelliJ to read the description you can use an NVDA addon which I developed, that adds a command for reading IntelliJ status bar and fixes list items not being labelled properly.
I actually forgot I asked this until I got an answer recently.
Thanks to lukaszgo1 for his answer.
When I'm working in IntelliJ, I often get this popup window that helps to see what method signatures I can use.
It's helpful sometimes, so I don't want to disable it, but in certain situations like this, it blocks my view and I don't know what I'm doing. Is there a way to move the position of this pop-up to under the code being typed instead of above? Basically, I'd still like the pop-up, but I'd like to see the code above it.
I'm using Dymola but I expect OpenModelica might very well be the same (or at least similar).
For a given component model sometimes it makes more sense to have lots of parameters shown on one "tab" of the parameter GUI. This can lead to an excessively long GUI which, for many reasons including for psychological reasons in relation to how humans process information, is not a appropriate solution.
To solve this I would like to add a vertical scroll bar on the parameter GUI. I believe I saw it once though I cannot recall exactly where.
For illustrative purposes look to the right side of your web browser window. That gray bar that goes up and down is the scrollbar :). I know, obvious but you never know.
I assume I need to put some command in an annotation somewhere though where and what command I am not sure. For example, I found some reference to a verticalScrollBarPolicy but alas, I can not find any documentation on this.
Anyone know how to do this?
EDIT #1:
Dymola (and Adrian indicated OpenModelica as well) will automatically create the scroll bar when the GUI gets larger than the screen. Unfortunately (at least in Dymola) there is little margin so if you GUI is a fraction smaller than the window the "OK" button will be covered by the ribbon on the bottom of the screen and the GUI will be needed to made slightly larger to make the scroll bar appear automatically. This is a reason why a manual option for a scrollbar would come in handy.
I think additional "tabs" might help?
As far as I know in OpenModelica we have a scroll bar for that dialog windows if the window would expand out of the screen.
As of this posting my understanding based on feedback on this forum, my own experience, and from additional discussions with others there is no current manual control of the GUI (i.e., size, scrollbars, etc.).
Your best bet if you come across issues (e.g., you have a super small 2nd monitor) is to use lots of tabs and keep descriptions very short (which is probably appropriate for most applications anyways).
This is a Dymola and OpenModelica issue not a modelica issue as it is not contained in the modelica specification (as I understand it).
If this changes and I find out about it I'll remove or update this post.
I'm new to intelliJ and sometimes like to use the "tool tips" (or whatever the kids are calling it these days - the thing that pops up when your mouse hovers over it) to find out what the different buttons do.
Annoyingly, sometimes i have to wait more than a heartbeat for the tool tip to appear. Is it possible to edit the speed with which said tips appear in intelliJ when I hover my mouse over a tool-tip-enabled item?
EDIT i am running 12.0.1 - one solution below is for 12.1.3+ (as noted in the comments), any ideas for below 12.1.3
There is a setting in the Settings window.
Edit
This seems to be available from version 12.1.3 only.
You can although edit the idea.vmoptions file and add a line like this at the end:
-Dide.tooltip.initialDelay=200
This makes the tooltip appear much faster (at least in some areas). Try by hovering on a tab in the editor pane. It will pop up very fast. Then close IntelliJ and change the value to 20000 and try again. As you will notice it will take 20 seconds (as expected).
For example try hovering over buttons as you describe in your question. By setting the delay to a very low value the tooltip appears immediately.