I'm upgraded to Vaadin 23.3 Preview because of Tooltip component. Works and looks great. Only one question - I use the tooltip as a toggletip. I added an icon to my textfield and manually open tooltip by clicking it. In order to close the tooltip, I have to click the icon one more time. Is it possible somehow to close the tooltip by clicking the tooltip text also?
That's not supported, as the Tooltip feature is not intended to be used for anything interactive. As the docs say:
Tooltips only support plain text content. They aren’t focusable and
can’t contain interactive elements.
Due to technical (and especially accessibility) reasons, interactive popups like that need a different implementation. There are some vague plans to add such a feature to the Vaadin platform in the future, however.
One component in the Vaadin's Directory that can be considered better suited for the task is Popup.
Related
I am using Tooltip for multiple input elements and showing the Tooltip on input elements both hovering and clicking. I need to prevent the JAWS reader from reading the Tooltip content while hovering. I have tried to remove the "role" attribute and set the "aria-hidden" attribute as true.
But none of this way works and the Tooltip still readable. Any assistance would be appreciable. we are using JAWS 2020.2008.24 ILM
There could be several things at play here. The first is that JAWS, by default, does not announce anything when you move the mouse so I'm puzzled why you are hearing something read when you hover. There's a "mouse echo" setting in the JAWS Setting Center but that's off by default for JAWS (unless you're running ZoomText). Did you specifically turn that feature on?
Secondly, you say you are showing the tooltip. So you're not relying on the default tooltip feature of browsers via the title attribute? You are handling the tooltip yourself and displaying it via javascript? JAWS will not announce newly displayed text unless the new text is in an aria-live region. Are you using live regions?
And lastly, if a tooltip attribute is being used, such as the title attribute, then the tooltip text might be used in the accessible name calculation or in the accessible description. It's the last attribute looked at (step 2.I). If it's being used in that manner, then you would not want to turn that off. It's expected behavior by JAWS users.
You may want to post some code to clarify all these issues in order to get a more accurate answer.
In GIMP: is there a way how to make my own custom dock (toolbar) where a could put my most used functions?
Something like this:
Create new empty dock or toolbar
Somehow set what functions will be in it
(any of the functions, no matter it has an icon or where in menus is located)
I'd like to have it so I don't have to search in menus every time I need something. I'm aware that I can make keyboard shortcuts but they are difficult to remember since I don't use Gimp every day. I'm used to this from Corel Photopaint and I think it is really useful.
Thanks for your suggestions.
In GIMP 2.8, you can only customize the dockable dialogs - by dragging then around, and in another level, customize tool presets and make use of the tags in the presets dialog to quckly access paint-modes with set brushes, gradients and painting dynamics - so, keeping the tool-presets dialog around, and appropriately using the tags can give you quick access to these settings.
You can't, however, add additional menu entries or icons to select particular plug-ins (filters) - and access those from any of the dockable dialogs. without rebuilding GIMP, you could edit the XML files at /usr/share/gimp/2.0/menus to customize your menus.
In the master branch, the unstable "GIMP 2.9" which will eventually become GIMP 2.10, there is a "search" action implemented, initiated by pressing the / character that will probably make it for the need to quickly find-out any operations wanted.
Background/Context:
I am developing touch screen based kiosk application with JavaFX. The app integrates browser – WebView. The problem is that all user inputs have to be made through on screen keyboard (SW keyboard)
It would be nice to have an option to register an event-handler on WebView/WebEngine for any HTML text input element got/lost focus, so that I could show/hide on-screen-keyboard.
Even though I searched the Internet, I did not find this kind of feature.
My questions:
Does JavaFX / WebView provides any support for these cases?
If you were to tackle this problem, what would be your approach to that?
My solution so far:
I have a small button (at one corner of the screen) that allows user to show/hide on-screen-keyboard. Since they have to do that manually, it is quite annoying. Especially on sites where browsing (consuming information) and text inputs changes frequently.
It would be nice to have an option to register an event-handler on WebView/WebEngine for any HTML text input element got/lost focus, so that I could show/hide on-screen-keyboard.
A potential strategy for doing this:
Start with a jdk8 preview.
Run the application with -Dcom.sun.javafx.isEmbedded=true to enable the virtual keyboard.
Use a webengine.executeScript technique to embed jQuery into the target page.
Bind a jQuery focus handler to the relevant html elements.
In the jQuery focus handler make an Upcall from JavaScript to Java.
Upon receiving the upcall make use of JavaFX's Virtual Keyboard.
As the user enters values into the keyboard, make executeScript calls to set the value of the corresponding html field.
Some parts will likely be a bit (or totally) flaky, but perhaps other parts may prove useful to you.
In the future, if WebView is supported on touchscreen platforms on embedded devices, I'm guessing that out of the box it will work well with a virtual keyboard.
SO I have a select box that I fill dynamically. I discovered that once the SELECT gets longer than the page, it automatically becomes a dialog listview.... which is TERRIBLE!
When this happens, the page refreshes when the dialog is closed and my whole page starts over....
Has anyone experienced that and do you know how to shut it off?
Thanks!
Todd
You could use the native look and feel?
http://jquerymobile.com/demos/1.0.1/docs/forms/forms-all-native.html
Native form elements & buttons Although the framework automatically enhances form elements and buttons into touch input
optimized controls to streamline development, it's easy to tell jQuery
Mobile to leave these elements alone so the standard, native control
can be used instead.
Adding the data-role="none" attribute to any form or button element
tells the framework to not apply any enhanced styles or scripting. The
examples below all have this attribute in place to demonstrate the
effect. You may need to write custom styles to lay out your form
controls because we try to leave all the default styling intact.
I hate default select control, that's because it can't be styled in IE using CSS.
This is why I developed a new select control from scratch, using HTML + CSS + JavaScript.
I did a great job in the past two days matching CSS and HTML together, but today I discovered a bug wich looks very hard for me to fix.
In IE 7, when I have tow controls on the same page, the one from top does not overlay the one from bottom.
See the image: coolrgb dot com/files/select-help.jpg
Download the demo page (HTML + CSS + Javascript): coolrgb dot com/files/select-help.zip
Please help me, this control looks so nice for me and I want to use it on all my projects from now on. This bug killed my hopes and lot of time.
Thank you.
If you give each control the same z-index, then you will not have control over the stacking order.
I would suggest modifying your control to behave more like a real SELECT element: only one can be open at a time, or losing focus causes it to close. Alternately, you can set a high z-index when the control has focus, and a lower one when it does not.
Another thing to look out for: try putting some other controls like radio, checkbox, and select under your control. You might find that IE also will not hover over those even if you give them a different z-index (as #grawity explained in his answer). This is why you'll typically see widget demos displayed on top of these elements, as shown here: http://jqueryui.com/demos/dialog/
A typical hack to fix this is to use an iframe, but that probably deserves a different question altogether.
Edit: After rereading the question, this answer now seems totally unrelated, but I'm keeping it here anyway.
Not really an answer, but an attempt to explain:
In Internet Explorer, <select> tags are implemented as simple windowed controls, while all other elements are windowless controls (this allows them to be styled). That's why these tags are always on top and don't follow the z-order rules. (The drop-down menu part must be styleable so it's a windowless control, and so it shows under the main part.)
In Firefox all elements are windowless, and in IE8 they should be too.