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