On Thu, 8 Dec 2022 08:27:27 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> > > If that is not possible I suggest providing that functionality so > > > applications will be able to use that. Probably even provide some > > > predefined cursors, like "faded"/"blurred"/nonblinked/etc. That could be > > > configured per L&F as well. > > > > That would be a nice feature to have but right now we have an issue where > > default behaviour of the component defies the VPAT guidelines. > > I am not sure that changing the default behavior of all text > components(including embedded to other components) to use a non-blinking > cursor is a good idea, you can convince me if you find someone who uses the > same approach, any applications? Probably at least for the native look&feels > we can use the same behavior as the native default components win32/cocoa/gtk. I believe this has been discussed here: * **Win32** displays a regular blinking caret for non-editable text controls; * **macOS** (Cocoa) display no caret for non-editable text controls; * **Ubuntu** (GNOME 3, GTK) displays a non-blinking caret for non-editable text controls; The above observations are based on the File Properties dialog in each OS. So, the app developer should have control over the behaviour. Then Look-and-Feel implementation could have its own defaults which match the platforms if applicable. At the same time, I don't this limitation as a showstopper. As [I said above](https://github.com/openjdk/jdk/pull/11408#issuecomment-1347190978), a visible caret facilitates selecting text using keyboard; from this point of view, this fix is a step forward. ------------- PR: https://git.openjdk.org/jdk/pull/11408
