RFR: 4512626: Non-editable JTextArea provides no visual indication of keyboard focus

Alexey Ivanov aivanov at openjdk.org
Mon Dec 12 21:18:51 UTC 2022


On Thu, 8 Dec 2022 08:27:27 GMT, Sergey Bylokhov <serb at 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



More information about the client-libs-dev mailing list