On Thu, 29 May 2025 18:12:25 GMT, Thiago Milczarek Sayao
wrote:
> I now own a mac mini m4 so I can test on mac. Still scared of building on
> windows :)
I'm putting together some PR's to deal with the Mac bugs. Any test related to
maximization is probably going to fail due to
[JDK-8355990](h
On Sun, 18 May 2025 19:02:14 GMT, Martin Fox wrote:
> The GlassTouches code for monitoring touch events was disabled years ago
> because it uses a global event tap. As Apple tightened security this started
> generating alerts. With the latest version of Xcode (16.3) this unused c
The GlassTouches code for monitoring touch events was disabled years ago
because it uses a global event tap. As Apple tightened security this started
generating alerts. With the latest version of Xcode (16.3) this unused code is
triggering a build error. This PR removes GlassTouches entirely.
-
The most recent version of Xcode enabled a new diagnostic which caught this old
problem. Whether it’s a logic error or not is beside the point since the code
was disabled years ago (see JDK-8231513 and JDK-8238435). I agree with Kevin
that the best short-term solution is to remove the GlassTouch
On Fri, 16 May 2025 23:02:30 GMT, Andy Goryachev wrote:
> It is weird that we have to add third-party specific code to JavaFX as a
> workaround - why doesn't macOS provide a general purpose API for this?
Normally an input method is designed for a specific language and is bundled
with a collect
On Fri, 16 May 2025 23:13:43 GMT, Andy Goryachev wrote:
>> Martin Fox has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Second try at making Keyman work to some extent
>
> modules/javafx.graphics/src/main/
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
>
character to insertText:replacementRange:
> instead.
>
> This PR special-cases the Keyman layout, detecting it using the same method
> that AWT does. When Keyman is active Glass records the insertText: character
> and uses that when sending out KeyEvents.
Martin Fox has updated the pull request increm
On Thu, 15 May 2025 22:25:51 GMT, Andy Goryachev wrote:
> Do you think it's a bug in keyman or our code? I head the beep (correctly)
> but then n appears, despite the keyman onscreen keyboard showing an empty
> key. If it is our code, should there be some additional logic?
Keyman is definitely
On Wed, 14 May 2025 15:31:46 GMT, Martin Fox wrote:
> Under the hood the Keyman input method appears as a US English keyboard
> layout. The characters attached to an NSEvent are always US English Roman
> even if the selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends
>
Under the hood the Keyman input method appears as a US English keyboard layout.
The characters attached to an NSEvent are always US English Roman even if the
selected Keyman layout is, say, Hebrew or Dvorak. Keyman sends the correct
Hebrew or Dvorak character to insertText:replacementRange: inst
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
Test file attached.
[drawdeiconify.patch](https://github
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
I'll work on creating an automated test for this.
--
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
What can we do to get this PR moving again?
It looks lik
On Wed, 7 May 2025 18:45:37 GMT, Thiago Milczarek Sayao
wrote:
>> tests/system/src/test/java/test/robot/javafx/stage/StageOwnershipTest.java
>> line 436:
>>
>>> 434: stage2::show,
>>> 435: stage2::close,
>>> 436: () -> assertTrue(stage1.isFocused
On Wed, 7 May 2025 09:30:05 GMT, Thiago Milczarek Sayao
wrote:
>> This is a continuation to
>> [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to
>> stabilize the linux glass gtk backend.
>>
>>
>> Overall, it has been made more robust within its scope, particularly in
On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the
On Mon, 28 Apr 2025 17:47:50 GMT, Martin Fox wrote:
> On macOS the system animates the transition into and out of fullscreen and
> this animation runs asynchronously. JavaFX tries to make the setFullScreen
> call appear synchronous by running a nested event loop while the transit
On Wed, 30 Apr 2025 17:52:01 GMT, Martin Fox wrote:
> macOS will allow any window to enter fullscreen mode but won't expand the
> window's size if the resizable bit isn't set in the window's style mask. For
> undecorated stages the code has to set this bit befo
On Wed, 30 Apr 2025 23:34:06 GMT, Martin Fox wrote:
>> On macOS the system animates the transition into and out of fullscreen and
>> this animation runs asynchronously. JavaFX tries to make the setFullScreen
>> call appear synchronous by running a nested event loop while the
On Wed, 30 Apr 2025 21:26:41 GMT, Kevin Rushforth wrote:
> During the headful test run, the following test failed on all four of our
> test systems, so it is likely related to your fix.
I think it's unrelated. During testing @andy-goryachev-oracle noted that the
demaximized position test was n
runnables (like pulses) start firing.
>
> In this PR GlassRunnables that try to run during the fullscreen transition
> are instead placed in a deferral list. When the fullscreen event loop exits
> they are re-scheduled.
Martin Fox has updated the pull request incrementally with one
On Wed, 30 Apr 2025 17:52:01 GMT, Martin Fox wrote:
> macOS will allow any window to enter fullscreen mode but won't expand the
> window's size if the resizable bit isn't set in the window's style mask. For
> undecorated stages the code has to set this bit befo
macOS will allow any window to enter fullscreen mode but won't expand the
window's size if the resizable bit isn't set in the window's style mask. For
undecorated stages the code has to set this bit before entering fullscreen and
restore the old value after exiting fullscreen.
The old code was
runnables (like pulses) start firing.
>
> In this PR GlassRunnables that try to run during the fullscreen transition
> are instead placed in a deferral list. When the fullscreen event loop exits
> they are re-scheduled.
Martin Fox has updated the pull request incrementally with one
On Sat, 26 Apr 2025 19:01:13 GMT, Thiago Milczarek Sayao
wrote:
>> This is a continuation to
>> [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to
>> stabilize the linux glass gtk backend.
>>
>>
>> Overall, it has been made more robust within its scope, particularly in
runnables (like pulses) start firing.
>
> In this PR GlassRunnables that try to run during the fullscreen transition
> are instead placed in a deferral list. When the fullscreen event loop exits
> they are re-scheduled.
Martin Fox has updated the pull request incrementally with one
On Tue, 29 Apr 2025 17:20:08 GMT, Andy Goryachev wrote:
> > testDemaximizedPosition()
>
> sorry, I meant with the standalone reproducer, not the actual test.
The standalone reproducer is just a slightly tweaked version of the system
test. Both should work fine. The system test should have been
On Mon, 28 Apr 2025 22:49:50 GMT, Andy Goryachev wrote:
> Using the reproducer in the ticket, I could not reproduce the issue with
> `testDemaximizedPosition()` - it passed in the master branch.
You're right, it should work. The test is still disabled on macOS even though
the blocking bug was
On Mon, 28 Apr 2025 20:54:25 GMT, Andy Goryachev wrote:
> question: could this deferral of runnables cause some kind of race condition
> in respect to other synchronous changes? Like, for example, trying to hide
> the window while is being transitioned to or from full screen?
One of the goals
On Mon, 28 Apr 2025 20:22:50 GMT, Kevin Rushforth wrote:
> * Do you think this will increase the possibility of deadlock?
This PR shifts the execution of runLater runnables out to the event loop in
effect when setFullScreen() was called. This matches where Windows and Linux
would process them.
On Mon, 28 Apr 2025 18:27:37 GMT, Jose Pereda wrote:
>> Note: The JBS issue
>> [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux,
>> but it happens on macOS too.
>>
>> When a TableColumn has a ContextMenu, if the user right clicks on the
>> tableColumnHeader, the Con
On Mon, 28 Apr 2025 17:24:31 GMT, Jose Pereda wrote:
> This was changed based on @beldenfox suggestion. I'll change it back.
If the mouse pressed event triggers a context menu you might never see the
mouse released event. So you have to consider what it means if column drag lock
gets set and t
On macOS the system animates the transition into and out of fullscreen and this
animation runs asynchronously. JavaFX tries to make the setFullScreen call
appear synchronous by running a nested event loop while the transition is going
on. But this means that runLater runnables can fire during a
On Thu, 24 Apr 2025 09:11:09 GMT, Jose Pereda wrote:
>>> control+left-click works as expected for me too.
>>
>> For control+left-click it looks like the code will call
>> `columnReordingStarted` but on the released event it won't call
>> `columnReorderingComplete`. I have no idea if this will
On Wed, 23 Apr 2025 09:46:06 GMT, Thiago Milczarek Sayao
wrote:
>> This is a continuation to
>> [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to
>> stabilize the linux glass gtk backend.
>>
>>
>> Overall, it has been made more robust within its scope, particularly in
On Wed, 23 Apr 2025 09:46:06 GMT, Thiago Milczarek Sayao
wrote:
>> This is a continuation to
>> [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to
>> stabilize the linux glass gtk backend.
>>
>>
>> Overall, it has been made more robust within its scope, particularly in
eing affected by
> this.
>
> For reference, here is a video on how the issue looked like initially on
> Linux: https://github.com/xpipe-io/xpipe/issues/485
>
> On 17/04/2025 22:24, Martin Fox wrote:
>> Christopher,
>>
>> Why are you trying to change the s
On Mon, 31 Mar 2025 18:29:21 GMT, Martin Fox wrote:
> Before a window is maximized glass records its existing size and location.
> This rectangle is stored in native screen coordinates. Compared to Java
> screen coordinates native coordinates are flipped along the Y axis.
>
>
Christopher,
Why are you trying to change the size of a maximized stage? I’m not sure what
the intended effect is.
Currently this produces all sort of platform-specific behavior and since what
you’re seeing on Windows doesn’t match what I’m seeing I think there might be
some variation based on
On Sun, 13 Apr 2025 18:01:08 GMT, Thiago Milczarek Sayao
wrote:
>> On some platforms (at least on Ubuntu 24.04 with GNOME and Windows 11),
>> windows can remain maximized even when they are iconified (minimized). When
>> the window is de-iconified (restored), it retains its maximized state.
>>
Clemens,
Thanks for reporting this. I did some testing and I think I’ve reproduced the
problem. What I’m seeing is specific to the Mac; when the focus is in a
ComboBox, DatePicker, or Spinner the user can’t use Cmd+Q to quit the app. This
also affects other menu items if you’re using the system
On macOS 15.3.2 I get the same results as Andy. When I press the top button
glass asks the OS to move the window offscreen but the OS shifts the location
40 units to the left so it’s partially onscreen.
> On Apr 9, 2025, at 8:08 AM, Andy Goryachev wrote:
>
> Here are the results on macOS 15.3.
The maximized state on Mac is murkier than it is on Windows and Linux but, yes,
a window can be both iconified and maximized at the same time.
The code you referenced looks correct. If you de-iconify a maximized window the
WindowEvent should be MAXIMIZE, not RESTORE.
What steps are you taking w
On Tue, 8 Apr 2025 21:40:36 GMT, Andy Goryachev wrote:
>> On Linux I have some issues too: the test that I attached to the JBS issue
>> doesn't fail for me on Linux, but the test that I added to this PR does fail
>> without the fix.
>
> Can you try the monkey tester? it allows setting properti
On Tue, 8 Apr 2025 21:42:55 GMT, Andy Goryachev wrote:
>> control+left-click works as expected for me too.
>>
>> When the context menu is showing, clicking anywhere outside of it, closes
>> the popup (because of the autohide property), but doesn't consume the event.
>> If you click on a button
On Tue, 8 Apr 2025 19:03:01 GMT, Andy Goryachev wrote:
>> I was having trouble reproducing the original bug on the master branch; the
>> sorting is done when the mouse is released and most of the time that event
>> never arrives (I think it does every now and then).
>
> this is strange - the bu
On Tue, 8 Apr 2025 18:20:54 GMT, Andy Goryachev wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java
>> line 275:
>>
>>> 273: private static final EventHandler mouseReleasedHandler
>>> = me -> {
>>> 274: TableColumnHeader header = (TableC
On Tue, 1 Apr 2025 17:31:14 GMT, Jose Pereda wrote:
> Note: The JBS issue
> [JDK-8207333](https://bugs.openjdk.org/browse/JDK-8207333) refers to Linux,
> but it happens on macOS too.
>
> When a TableColumn has a ContextMenu, if the user right clicks on the
> tableColumnHeader, the ContextMen
On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox wrote:
>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the
>> equivalent wrapper NSRunLoop methods). When the limit is hit the OS
>> terminates the Java app. The situation arises when a JavaFX app creates t
On Fri, 4 Apr 2025 21:20:15 GMT, Andy Goryachev wrote:
> I can help with the testing: I have 15.3.2 with one or two external monitors.
> What might help is to enumerate scenarios we want to be tested.
Thanks for the offer. I'm also running 15.3.2. I suspect I'll have to try test
on an older ve
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
I think this PR is the correct fix on Windows and Linux.
On Mon, 31 Mar 2025 20:41:10 GMT, Andy Goryachev wrote:
> just curious: could this have any relevance to
> https://bugs.openjdk.org/browse/JDK-8353314 ?
No, I can still reproduce that bug with this PR. Something else is going on.
-
PR Comment: https://git.openjdk.org/jfx/pull/1749
On Mon, 24 Mar 2025 17:48:00 GMT, Kevin Rushforth wrote:
>> I added a comment explaining where the number comes from. Since it's only
>> used in this one spot putting it in a static const variable seemed redundant.
>>
>> I'm not sure that 250 is a safe limit. I know that the JUnit test crashes
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
First an errata: I wrote earlier that notifyRepaint is on
On Mon, 31 Mar 2025 18:27:11 GMT, Andy Goryachev wrote:
> Good idea. I might need some help with this though - this command line
>
> `java @build/testrun.args ./tests/manual/text/EmojiTest.java` fails because
> it cannot find
Sorry, I don't think this can be made to work. I've been able to get
On Fri, 21 Mar 2025 20:56:01 GMT, Martin Fox wrote:
> There is an undocumented limit on nesting calls to CFRunLoopRun (or the
> equivalent wrapper NSRunLoop methods). When the limit is hit the OS
> terminates the Java app. The situation arises when a JavaFX app creates too
> many
Before a window is maximized glass records its existing size and location. This
rectangle is stored in native screen coordinates. Compared to Java screen
coordinates native coordinates are flipped along the Y axis.
When the window is un-maximized that native rectangle is passed to a routine
tha
On Fri, 28 Mar 2025 23:06:47 GMT, Andy Goryachev wrote:
> The following command line expectedly fails because it can't find
> `com.oracle.util.testing.ManualTestWindow`:
>
> ```
> java --module-path=build/sdk/lib --add-modules=javafx.controls
> ./tests/manual/text/EmojiTest.java
> ```
When I
andler starts a new nested event loop; at that point we're in stage
> two and are past the call to CFRunLoopRun.
Martin Fox has updated the pull request incrementally with one additional
commit since the last revision:
Added description of the new nested event loop limit.
--
good if it wouldn't throw exceptions in later pulses if you're
> looking for a justification on why to implement an index check.
>
> On 28/03/2025 17:26, Martin Fox wrote:
>> I’ve been able to reproduce this inside a debugger on my Mac every eighth
>> try or so.
>>
ss is slightly better than an exception, but also
> not ideal. So it seems like the reproducer behavior depends a lot on the
> specific system.
>
> On 26/03/2025 19:35, Martin Fox wrote:
>> Christopher,
>>
>> Yes, there might be more than one issue here. On the
On Wed, 26 Mar 2025 08:34:06 GMT, Michael Strauß wrote:
>> Martin Fox has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Lower limit on run loop nesting
>
> In any case, this PR should at least add the fo
andler starts a new nested event loop; at that point we're in stage
> two and are past the call to CFRunLoopRun.
Martin Fox has updated the pull request incrementally with one additional
commit since the last revision:
Now throwing an IllegalStateException
-
Changes:
On Thu, 27 Mar 2025 17:33:23 GMT, Kevin Rushforth wrote:
>> Martin Fox has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Removed unnecessary import
>> - The max nested event loop constant is no longer publ
andler starts a new nested event loop; at that point we're in stage
> two and are past the call to CFRunLoopRun.
Martin Fox has updated the pull request incrementally with two additional
commits since the last revision:
- Removed unnecessary import
- The max nested event loop constant
On Wed, 26 Mar 2025 18:22:50 GMT, Andy Goryachev wrote:
>> Martin Fox has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Set limit on nested event loop count to 200 which seems less arbitrary
>> - The max
On Wed, 26 Mar 2025 17:37:39 GMT, Martin Fox wrote:
>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the
>> equivalent wrapper NSRunLoop methods). When the limit is hit the OS
>> terminates the Java app. The situation arises when a JavaFX app creates t
andler starts a new nested event loop; at that point we're in stage
> two and are past the call to CFRunLoopRun.
Martin Fox has updated the pull request incrementally with two additional
commits since the last revision:
- Set limit on nested event loop count to 200 which seems less
ventLoop is
> potentially the right method to indicate to the caller that the limit is
> close by returning false.
> And even if something like an exception is thrown when a nested event loop is
> started while it is close to the limit, that would still be much better than
> a direct
On Wed, 26 Mar 2025 08:30:08 GMT, Michael Strauß wrote:
> Why would an application need to be tested against a specific limit?
If you knew that your app could hit a limit and the limit could vary by
platform you would want to focus your testing on the platform with the lowest
limit. In any cas
On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox wrote:
>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the
>> equivalent wrapper NSRunLoop methods). When the limit is hit the OS
>> terminates the Java app. The situation arises when a JavaFX app creates t
andler starts a new nested event loop; at that point we're in stage
> two and are past the call to CFRunLoopRun.
Martin Fox has updated the pull request incrementally with one additional
commit since the last revision:
Lower limit on run loop nesting
-
Changes:
- all
On Mon, 24 Mar 2025 19:56:03 GMT, Kevin Rushforth wrote:
> > We might want to consider imposing a limit on Linux and Windows, too. It
> > could probably be done as a follow-up...
>
> Although doing it as part of this PR would be OK, too. Which would you prefer?
And there it is, that open can o
On Mon, 24 Mar 2025 15:09:43 GMT, Andy Goryachev wrote:
>> Martin Fox has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added explanation for limit on nested run loop calls
>
> modules/javafx.graphics/s
On Fri, 21 Mar 2025 21:15:27 GMT, Kevin Rushforth wrote:
>> Martin Fox has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added explanation for limit on nested run loop calls
>
> modules/javafx.grap
andler starts a new nested event loop; at that point we're in stage
> two and are past the call to CFRunLoopRun.
Martin Fox has updated the pull request incrementally with one additional
commit since the last revision:
Added explanation for limit on nested run loop calls
--
On Sat, 22 Mar 2025 02:12:48 GMT, Jay Bhaskar wrote:
> It is better to use dynamically calculated safe limit instead of a hardcoded
> value like 250.
The problem doesn't seem to be resource exhaustion. It seems that Apple is
using a hard-coded number specifically to detect a potential case of
On Fri, 21 Mar 2025 21:25:43 GMT, Andy Goryachev wrote:
>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the
>> equivalent wrapper NSRunLoop methods). When the limit is hit the OS
>> terminates the Java app. The situation arises when a JavaFX app creates too
>> many neste
There is an undocumented limit on nesting calls to CFRunLoopRun (or the
equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates
the Java app. The situation arises when a JavaFX app creates too many nested
event loops from within Platform.runLater runnables.
This PR doesn
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
At least on the Mac there seems to be a timing issue. If
On the Mac the JavaFX core creates the application menu, the one immediately
adjacent to the Apple menu in the menu bar. There is no JavaFX API to access it
so a developer can’t localize the existing items or add additional ones (like
About). We can’t easily provide access to it since it’s not b
Hi Christopher,
I was able to reproduce this crash. I wrote a small routine that recursively
calls itself in a runLater block and then enters a nested event loop. The
program crashes when creating loop 254. I’m not sure where that limit comes
from so it’s possible that consuming some other syst
On the Mac the application menu (the one to the right of the Apple logo menu)
is created by JavaFX and there is no public API to customize or localize it.
This PR allows a client to get rid of it and replace it with an entirely custom
JavaFX Menu.
Prior to OS X 10.6 (Snow Leopard) the applicati
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
Adding `entireSceneNeedsRepaint` fixes this on the Mac.
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
I just verified that this PR does not fix the original is
On Thu, 13 Mar 2025 13:53:11 GMT, John Hendrikx wrote:
> Can you give me a bit more detail what you mean here? I suspect it might be
> related to the size not actually changing, and so a size update with the same
> size does nothing?
Sorry, I'm asking a general question about how JavaFX deals
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
When the window is restored glass calls notifySize with R
ss.ui.Application::enterNestedEventLoop() even warns about it:
>>
>> * An application may enter several nested loops recursively. There's no
>> * limit of recursion other than that imposed by the native stack size.
>>
>>
>> -andy
>&
> I guess that's just the way I made it work. Implementing this in
> Control is not something I've thought about a lot.
It was really my thought experiment to begin with. Not sure it’s even possible
to do this without involving Scene and Scene knows nothing about Controls.
Don’t give it anothe
> On Feb 6, 2025, at 11:52 PM, Michael Strauß wrote:
>
>> This PR uses an event dispatcher to provide a cleaner way of channeling
>> keyboard events to another node. I haven’t prototyped the code but I suspect
>> a Control could do this using the existing API without any changes to the
>> N
hould drop everything and re-write the
> whole thing, but I do want to continue the conversation.
>
> -andy
>
>
>
>
>
> From: Martin Fox
> Date: Friday, December 13, 2024 at 08:03
> To: Andy Goryachev
> Cc: OpenJFX
> Subject: Re: [External] : R
On Mon, 11 Nov 2024 17:57:30 GMT, Martin Fox wrote:
> Input methods don’t work for text controls inside Popups. This PR fixes that.
>
> Some background:
>
> A PopupWindow always has an owner. The owner of the first Popup is a standard
> Window; I’ll refer to that as the
On Sun, 15 Dec 2024 20:26:22 GMT, Thiago Milczarek Sayao
wrote:
>> This option sets if editing happens on the application or in the IME window.
>>
>> Application:
>> 
>>
>>
>> IME Window:
>>  finished
>> input-action. Then, the in
On Wed, 4 Dec 2024 14:39:55 GMT, Martin Fox wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/InputMethodStateManager.java
>> line 48:
>>
>>> 46: * PopupWindow.
>>> 47: */
>>> 48: public class InputMethodStateManager {
>>
On Tue, 10 Dec 2024 09:52:38 GMT, Helly Guo wrote:
>> @hellyguo Could you provide more details on which Linux distribution, input
>> method, and fcitx version you're using?
>>
>> I just tested this on Ubuntu 24.10. For Chinese I'm using Intelligent Pinyin
>> and for Japanese I'm using Mozc. Ev
n the
> "leading" area, and another layout container in the "center" area, and
> assign different backgrounds to them.
>
> Does this solve your use case?
>
>
>
> On Fri, Nov 15, 2024 at 10:09 PM Martin Fox wrote:
>>
>> Michael,
>>
>
1 - 100 of 449 matches
Mail list logo
