On Mon, 19 Dec 2022 19:11:46 GMT, Alexander Zuev wrote:
>> Ubuntu 22.04 and it reproduces always.
>
> Ok, i tried on Ubuntu 22 on x11 desktop and i see this behavior. However - i
> checked out master and i also can see the same glitch so this is not related
> to my fix.
Can confirm, filed
On Sat, 17 Dec 2022 18:21:09 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area. Fix the regression test that becames unstable after the change.
>
> Alexander Zuev has updated the pull request incrementally with one additional
>
On Mon, 19 Dec 2022 18:17:48 GMT, Alexander Zvegintsev
wrote:
>> That's weird, does not happen on any of my systems. Which OS are you testing
>> on?
>
> Ubuntu 22.04 and it reproduces always.
Ok, i tried on Ubuntu 22 on x11 desktop and i see this behavior. However - i
checked out master and
On Mon, 19 Dec 2022 17:35:43 GMT, Alexander Zuev wrote:
>> The latest version does not work good for me,
>> e.g. with the test above and `textField.getCaret().setBlinkRate(250)`(not
>> `2500`):
>>
>> 1. with `requestFocus(button);`:
>> caret blinks several times and stops
>> on mouse move,
On Mon, 19 Dec 2022 12:09:01 GMT, Alexander Zvegintsev
wrote:
>> I am still having issue with non-blinking cursor on editable field with the
>> latest version of the fix.
>>
>> Fails for me with test provided above and commented `requestFocus(button);`
>> line.
>
> The latest version does
On Sat, 17 Dec 2022 01:14:00 GMT, Alexander Zvegintsev
wrote:
>> I updated the code now the behaviour is correct (as far as i tested) and the
>> blink rate is reported as if it is set to the correct value even on
>> non-editable text element.
>
> I am still having issue with non-blinking
On Sat, 17 Dec 2022 18:16:30 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area. Fix the regression test that becames unstable after the change.
>
> Alexander Zuev has updated the pull request incrementally with one additional
>
On Sat, 17 Dec 2022 01:08:12 GMT, Alexander Zvegintsev
wrote:
>> Alexander Zuev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Handle different cases where refresh rate can be set when component is in
>> different states causing some
> Set the text caret to be visible but not blinking on the non-editable text
> area. Fix the regression test that becames unstable after the change.
Alexander Zuev has updated the pull request incrementally with one additional
commit since the last revision:
Renamed blinkRateSaved to
> Set the text caret to be visible but not blinking on the non-editable text
> area. Fix the regression test that becames unstable after the change.
Alexander Zuev has updated the pull request incrementally with one additional
commit since the last revision:
Fixing situation where we can be
On Fri, 16 Dec 2022 20:05:16 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area. Fix the regression test that becames unstable after the change.
>
> Alexander Zuev has updated the pull request incrementally with one additional
>
On Fri, 16 Dec 2022 19:59:30 GMT, Alexander Zuev wrote:
>> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 389:
>>
>>> 387: } else {
>>> 388: if (getBlinkRate() != 0) {
>>> 389: savedBlinkRate = getBlinkRate();
>>
>> Look
On Thu, 15 Dec 2022 20:09:35 GMT, Alexander Zvegintsev
wrote:
>> Alexander Zuev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixed MultiSelectionText so it is now stable on Linux
>> Removed both fixed tests from ProblemList
>
>
On Fri, 16 Dec 2022 01:19:46 GMT, Alexander Zvegintsev
wrote:
>> Alexander Zuev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixed MultiSelectionText so it is now stable on Linux
>> Removed both fixed tests from ProblemList
>
>
> Set the text caret to be visible but not blinking on the non-editable text
> area. Fix the regression test that becames unstable after the change.
Alexander Zuev has updated the pull request incrementally with one additional
commit since the last revision:
Handle different cases where
On Thu, 15 Dec 2022 07:29:32 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area. Fix the regression test that becames unstable after the change.
>
> Alexander Zuev has updated the pull request incrementally with one additional
>
On Tue, 13 Dec 2022 12:52:00 GMT, Alexey Ivanov wrote:
> It would be better to verify the updated test passes on Windows. If so,
> remove it from the problem list.
Done and done.
-
PR: https://git.openjdk.org/jdk20/pull/21
On Tue, 13 Dec 2022 08:27:46 GMT, Prasanta Sadhukhan
wrote:
>>> Does it need similar change in
>>> test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java
>>> as well? Since the logic is changed, I will still request to make this
>>> test stable on windows (now that we
> Set the text caret to be visible but not blinking on the non-editable text
> area. Fix the regression test that becames unstable after the change.
Alexander Zuev has updated the pull request incrementally with one additional
commit since the last revision:
Fixed MultiSelectionText so it is
On Mon, 12 Dec 2022 22:33:51 GMT, Alexander Zuev wrote:
> Set the text caret to be visible but not blinking on the non-editable text
> area. Fix the regression test that becames unstable after the change.
It would be better to verify the updated test passes on Windows. If so, remove
it from
On Tue, 13 Dec 2022 06:10:34 GMT, Alexander Zuev wrote:
>> test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java
>> line 120:
>>
>>> 118: robot.waitForIdle();
>>> 119: robot.delay(200);
>>> 120: if (!field2.getCaret().isSelectionVisible()) {
>>
On Tue, 13 Dec 2022 02:34:46 GMT, Prasanta Sadhukhan
wrote:
> Does it need similar change in
> test/jdk/javax/swing/text/DefaultCaret/HidingSelection/MultiSelectionTest.java
> as well? Since the logic is changed, I will still request to make this test
> stable on windows (now that we are not
On Mon, 12 Dec 2022 22:33:51 GMT, Alexander Zuev wrote:
> Set the text caret to be visible but not blinking on the non-editable text
> area. Fix the regression test that becames unstable after the change.
test/jdk/javax/swing/text/DefaultCaret/HidingSelection/HidingSelectionTest.java
line
On Mon, 12 Dec 2022 22:33:51 GMT, Alexander Zuev wrote:
> Set the text caret to be visible but not blinking on the non-editable text
> area. Fix the regression test that becames unstable after the change.
Continuation of https://github.com/openjdk/jdk/pull/11408 to be integrated into
JDK20
Set the text caret to be visible but not blinking on the non-editable text
area. Fix the regression test that becames unstable after the change.
-
Commit messages:
- 4512626: Non-editable JTextArea provides no visual indication of keyboard
focus
Changes:
On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area.
>
> Alexander Zuev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Handling the case when blink
On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area.
>
> Alexander Zuev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Handling the case when blink
On Thu, 8 Dec 2022 08:27:27 GMT, Sergey Bylokhov 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
> > >
On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area.
>
> Alexander Zuev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Handling the case when blink
On Thu, 8 Dec 2022 12:46:48 GMT, Alexander Zuev 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
>>> >
On Thu, 8 Dec 2022 08:27:27 GMT, Sergey Bylokhov wrote:
> someone who uses the same approach, any applications
Gnome on Ubuntu 22, default applications. Editable text components have
blinking carets, non-editable - non-blinking ones.
-
PR: https://git.openjdk.org/jdk/pull/11408
On Thu, 8 Dec 2022 05:28:31 GMT, Alexander Zuev 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
On Wed, 7 Dec 2022 10:52:08 GMT, Sergey Bylokhov wrote:
> > The library does not provide an ability to set caret to visible permanently
> > in case of text component being non-editable. Every time focus will change
> > the caret will change too. One would have to implement a custom caret that
On Tue, 6 Dec 2022 12:01:13 GMT, Alexander Zuev wrote:
> The library does not provide an ability to set caret to visible permanently
> in case of text component being non-editable. Every time focus will change
> the caret will change too. One would have to implement a custom caret that
>
On Tue, 6 Dec 2022 02:11:19 GMT, Sergey Bylokhov wrote:
> I think that using the VoiceOver or JAWS will highlight the currently focused
> component since we should send that information to them, no?
That paragraph consists of two statements - first is that focus should be
visible and one can
On Tue, 6 Dec 2022 02:00:44 GMT, Sergey Bylokhov wrote:
> The library provides a way to set different cursors and the application may
> use that
The library does not provide an ability to set caret to visible permanently in
case of text component being non-editable. Every time focus will
On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area.
>
> Alexander Zuev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Handling the case when blink
On Mon, 5 Dec 2022 07:26:27 GMT, Alexander Zuev wrote:
> Chrome form editor hides cursor, Adobe Acrobat shows blinking cursor,
> Microsoft Office 2011 shows some custom cursor that appears to be grayed off
> or faded. Differently.
Does any of them use non blinking cursor? it seems related to
On Mon, 5 Dec 2022 19:44:40 GMT, Alexey Ivanov wrote:
> Does the background colour* of non-editable text component change in Swing?
It does not.
-
PR: https://git.openjdk.org/jdk/pull/11408
On Mon, 5 Dec 2022 18:38:29 GMT, Alexander Zuev wrote:
> My point is that if editable text component can not be visually distinguished
> from non-editable one it is also not helpful.
Agreed.
Does the background colour* of non-editable text component change in Swing? If
not, then non-blinking
On Mon, 5 Dec 2022 05:29:53 GMT, Prasanta Sadhukhan
wrote:
> The test is problemlisted for windows so not sure if the observation "passes
> on Windows" is correct..
When it failed on Linux on pre-submit task i ran it locally and deproblemlisted
it on Windows. I haven't pushed the problemlist
On Mon, 5 Dec 2022 16:42:39 GMT, Alexey Ivanov wrote:
> How do native apps on macOS handle the situation? Especially those developed
> by Apple?
It is quite hard to find a relevant case but so far it seems that it is all
over the place on Mac OS - in majority of the apps where it allows
On Sun, 4 Dec 2022 23:27:42 GMT, Alexander Zuev wrote:
> > At least on Windows, non-editable text controls have a blinking caret.
>
> Well, Windows is an important platform but it is not the only one we care
> about.
> On Ubuntu 22 the editable text field has the blinking cursor and
On Mon, 5 Dec 2022 05:50:37 GMT, Sergey Bylokhov wrote:
> How that different applications handle that?
Chrome form editor hides cursor, Adobe Acrobat shows blinking cursor, Microsoft
Office 2011 shows some custom cursor that appears to be grayed off or faded.
Differently.
-
PR:
On Fri, 2 Dec 2022 23:49:17 GMT, Alexander Zuev wrote:
> Different application handle it differently but most os them do not claim to
> pass the VPAT certification. I do not think that non-blinking cursor can be
> treated as hanged application.
How that different applications handle that?
On Fri, 2 Dec 2022 23:54:21 GMT, Alexander Zuev wrote:
> Finally the HidingSelectionTest had to be re-written because its logic is
> incorrect and it passes on MacOS and Windows only because of the flaw in the
> test that allows false positive.
The test is problemlisted for windows so not
On Sat, 3 Dec 2022 12:57:49 GMT, Alexey Ivanov wrote:
> At least on Windows, non-editable text controls have a blinking caret.
Well, Windows is an important platform but it is not the only one we care
about. On Ubuntu 22 the editable text field has the blinking cursor and
non-editable has a
On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area.
>
> Alexander Zuev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Handling the case when blink
On Fri, 2 Dec 2022 23:52:55 GMT, Alexander Zuev wrote:
>> Set the text caret to be visible but not blinking on the non-editable text
>> area.
>
> Alexander Zuev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Handling the case when blink
On Fri, 2 Dec 2022 04:16:21 GMT, Sergey Bylokhov wrote:
> I wonder how other native applications handle this. Can the non-blinking
> cursor be considered a hang of the application?
Different application handle it differently but most os them do not claim to
pass the VPAT certification. I do
> Set the text caret to be visible but not blinking on the non-editable text
> area.
Alexander Zuev has updated the pull request incrementally with one additional
commit since the last revision:
Handling the case when blink rate is set while component is unedited
Test
On Tue, 29 Nov 2022 07:30:32 GMT, Alexander Zuev wrote:
> Set the text caret to be visible but not blinking on the non-editable text
> area.
I wonder how other native applications handle this. Can the non-blinking cursor
be considered a hang of the application?
-
PR:
On Tue, 29 Nov 2022 18:19:34 GMT, Phil Race wrote:
> Hmm. This is a pretty broad change. It applies to any Swing component that
> accepts a caret as far as I can tell, and is broader than A11Y, so I worry
> about unexpected consequences. What is the situation today for a JTextField -
> and
On Tue, 29 Nov 2022 07:30:32 GMT, Alexander Zuev wrote:
> Set the text caret to be visible but not blinking on the non-editable text
> area.
src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 386:
> 384: setBlinkRate(savedBlinkRate);
> 385:
On Tue, 29 Nov 2022 07:30:32 GMT, Alexander Zuev wrote:
> Set the text caret to be visible but not blinking on the non-editable text
> area.
Hmm. This is a pretty broad change.
It applies to any Swing component that accepts a caret as far as I can tell,
and is broader than A11Y, so I worry
Set the text caret to be visible but not blinking on the non-editable text area.
-
Commit messages:
- 4512626: Non-editable JTextArea provides no visual indication of keyboard
focus
Changes: https://git.openjdk.org/jdk/pull/11408/files
Webrev:
56 matches
Mail list logo
