On Tue, 23 Jan 2024 17:24:05 GMT, Martin Fox wrote:
>> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
>> processed on the JavaFX application thread instead of the AWT EventQueue
>> thread. This PR adds the runAndWait() calls to do that.
>>
>> This would be difficult
On Tue, 23 Jan 2024 17:24:05 GMT, Martin Fox wrote:
>> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
>> processed on the JavaFX application thread instead of the AWT EventQueue
>> thread. This PR adds the runAndWait() calls to do that.
>>
>> This would be difficult
> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
> processed on the JavaFX application thread instead of the AWT EventQueue
> thread. This PR adds the runAndWait() calls to do that.
>
> This would be difficult to test on Windows without a fix for
> [JDK-8090267](https
On Mon, 22 Jan 2024 22:13:42 GMT, Martin Fox wrote:
> this pattern is used throughout the code base.
that might be the case, but I think we should use the right pattern for the new
code.
single-element array is an anachronism, especially in the case of
multi-threaded code as here.
---
On Mon, 22 Jan 2024 21:06:01 GMT, Andy Goryachev wrote:
>> Again, thread-safety isn't an issue here. Even if the OS were to invoke the
>> IM methods on different threads (which is a terrifying thought) these
>> adapters are created on a per-call basis so each thread would get its own
>> instan
On Mon, 22 Jan 2024 20:52:56 GMT, Martin Fox wrote:
>> I might be wrong, but array would need to store its size (an int, 8 bytes on
>> 64 bit machines) in addition to the pointers themselves, while
>> AtomicReference needs just the pointer.
>> Plus, its semantics is much cleaner.
>
> Again, thr
On Mon, 22 Jan 2024 15:45:25 GMT, Andy Goryachev wrote:
>> Either an array or an AtomicReference is OK in this case. AtomicReference is
>> thread-safe, but that's not a concern here, since using `runAndWait` ensures
>> that writing to the array happens before reading it.
>
> I might be wrong, b
On Sat, 20 Jan 2024 14:07:32 GMT, Kevin Rushforth wrote:
>> I'm not familiar enough with AtomicReference to have an opinion on this.
>> Someone else will have to weigh in on this.
>
> Either an array or an AtomicReference is OK in this case. AtomicReference is
> thread-safe, but that's not a co
On Sat, 20 Jan 2024 01:08:23 GMT, Martin Fox wrote:
>> modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java
>> line 132:
>>
>>> 130: }
>>> 131: if (selected[0] == null) selected[0] = "";
>>> 132: return new AttributedString(selected[0
On Fri, 19 Jan 2024 16:15:10 GMT, Martin Fox wrote:
>> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
>> processed on the JavaFX application thread instead of the AWT EventQueue
>> thread. This PR adds the runAndWait() calls to do that.
>>
>> This would be difficult
On Fri, 19 Jan 2024 23:39:59 GMT, Andy Goryachev wrote:
>> Martin Fox has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Switched to local array variables
>
> I think this code crashes on macOS with Arabic input...
>
> correction: not cras
On Fri, 19 Jan 2024 16:15:10 GMT, Martin Fox wrote:
>> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
>> processed on the JavaFX application thread instead of the AWT EventQueue
>> thread. This PR adds the runAndWait() calls to do that.
>>
>> This would be difficult
On Fri, 19 Jan 2024 16:15:10 GMT, Martin Fox wrote:
>> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
>> processed on the JavaFX application thread instead of the AWT EventQueue
>> thread. This PR adds the runAndWait() calls to do that.
>>
>> This would be difficult
On Fri, 19 Jan 2024 16:15:10 GMT, Martin Fox wrote:
>> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
>> processed on the JavaFX application thread instead of the AWT EventQueue
>> thread. This PR adds the runAndWait() calls to do that.
>>
>> This would be difficult
> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
> processed on the JavaFX application thread instead of the AWT EventQueue
> thread. This PR adds the runAndWait() calls to do that.
>
> This would be difficult to test on Windows without a fix for
> [JDK-8090267](https
On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote:
> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
> processed on the JavaFX application thread instead of the AWT EventQueue
> thread. This PR adds the runAndWait() calls to do that.
>
> This would be difficult to te
On Thu, 18 Jan 2024 13:33:22 GMT, Kevin Rushforth wrote:
>> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
>> processed on the JavaFX application thread instead of the AWT EventQueue
>> thread. This PR adds the runAndWait() calls to do that.
>>
>> This would be diffi
On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote:
> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
> processed on the JavaFX application thread instead of the AWT EventQueue
> thread. This PR adds the runAndWait() calls to do that.
>
> This would be difficult to te
On Thu, 18 Jan 2024 07:30:05 GMT, Prasanta Sadhukhan
wrote:
>> modules/javafx.swing/src/main/java/javafx/embed/swing/InputMethodSupport.java
>> line 106:
>>
>>> 104: });
>>> 105: }
>>> 106: if (stringValue == null) stringValue = "";
>>
>> Not sure of FX
On Thu, 18 Jan 2024 07:28:57 GMT, Prasanta Sadhukhan
wrote:
>> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
>> processed on the JavaFX application thread instead of the AWT EventQueue
>> thread. This PR adds the runAndWait() calls to do that.
>>
>> This would be d
On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote:
> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
> processed on the JavaFX application thread instead of the AWT EventQueue
> thread. This PR adds the runAndWait() calls to do that.
>
> This would be difficult to te
On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote:
> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
> processed on the JavaFX application thread instead of the AWT EventQueue
> thread. This PR adds the runAndWait() calls to do that.
>
> This would be difficult to te
On Tue, 16 Jan 2024 17:59:42 GMT, Martin Fox wrote:
> On Windows we need to ensure InputMethodRequests coming from JFXPanel are
> processed on the JavaFX application thread instead of the AWT EventQueue
> thread. This PR adds the runAndWait() calls to do that.
>
> This would be difficult to te
On Windows we need to ensure InputMethodRequests coming from JFXPanel are
processed on the JavaFX application thread instead of the AWT EventQueue
thread. This PR adds the runAndWait() calls to do that.
This would be difficult to test on Windows without a fix for
[JDK-8090267](https://bugs.open
24 matches
Mail list logo
