definitely a separate issue.
-andy
From: openjfx-dev on behalf of Kevin Rushforth
Date: Monday, June 17, 2024 at 15:09
To: openjfx-dev@openjdk.org
Subject: Re: Platform diferences
If it only misbehaves on multi-screen, then that's almost certainly a separate
issue.
-- Kevin
On 6/17/2024
On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao
wrote:
>> This fixes two bugs appointed on the JBS issue:
>>
>> 1) Sometimes window was moving to the top left corner - seems to be a bug
>> somewhere in `gdk_window_get_origin` when used before map (a X concept when
>> the window
If it only misbehaves on multi-screen, then that's almost certainly a
separate issue.
-- Kevin
On 6/17/2024 1:52 PM, Andy Goryachev wrote:
Thank you for clarification.
I guess the only problem I see (and which applies to both mac and
linux) is that the alert window appears on the wrong
Positioning of Windows, among other window system interactions, is
inherently platform specific. We added language, primarily in support of
Wayland, to clarify this, but I can easily imagine other windowing
environments where this is also true. We should try for consistency
where possible, but
On Mon, 17 Jun 2024 18:54:15 GMT, Andy Goryachev wrote:
> Initial comments:
>
> 1. the description says this fixes two issues. do we have two JBS tickets?
> if so, please add the other ticket to this PR
> 2. the description in JDK-833 is insufficient: missing steps to
> reproduce,
On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao
wrote:
>> This fixes two bugs appointed on the JBS issue:
>>
>> 1) Sometimes window was moving to the top left corner - seems to be a bug
>> somewhere in `gdk_window_get_origin` when used before map (a X concept when
>> the window
Thank you for clarification.
I guess the only problem I see (and which applies to both mac and linux) is
that the alert window appears on the wrong monitor - I would expect it to
appear on the same monitor where the main window is positioned.
-andy
From: openjfx-dev on behalf of Thiago
On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao
wrote:
>> This fixes two bugs appointed on the JBS issue:
>>
>> 1) Sometimes window was moving to the top left corner - seems to be a bug
>> somewhere in `gdk_window_get_origin` when used before map (a X concept when
>> the window
I'm forwarding here since it's unrelated to the specific issue.
The existing behavior on Linux is to center the windows. I think we should
let the window manager decide and don't touch the initial position (unless
the user sets it).
On mutter, for example, there's an option to automatically
On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao
wrote:
>> This fixes two bugs appointed on the JBS issue:
>>
>> 1) Sometimes window was moving to the top left corner - seems to be a bug
>> somewhere in `gdk_window_get_origin` when used before map (a X concept when
>> the window
On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao
wrote:
>> This fixes two bugs appointed on the JBS issue:
>>
>> 1) Sometimes window was moving to the top left corner - seems to be a bug
>> somewhere in `gdk_window_get_origin` when used before map (a X concept when
>> the window
On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao
wrote:
>> This fixes two bugs appointed on the JBS issue:
>>
>> 1) Sometimes window was moving to the top left corner - seems to be a bug
>> somewhere in `gdk_window_get_origin` when used before map (a X concept when
>> the window
On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao
wrote:
>> This fixes two bugs appointed on the JBS issue:
>>
>> 1) Sometimes window was moving to the top left corner - seems to be a bug
>> somewhere in `gdk_window_get_origin` when used before map (a X concept when
>> the window
On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao
wrote:
>> This replaces obsolete XIM and uses gtk api for IME.
>> Gtk uses [ibus](https://github.com/ibus/ibus)
>>
>> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative
>> positioning on `InputMethodRequest`.
>>
On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote:
> This is an alternative solution to the PR:
> https://github.com/openjdk/jfx/pull/1310.
>
> This solution is based on the invariant that if a node is marked as dirty,
> all ancestors must also be marked as dirty and that if an ancestor is
On Fri, 3 May 2024 10:23:27 GMT, Florian Kirmaier wrote:
>> In some situations, a part of the SG is no longer rendered.
>> I created a test program that showcases this problem.
>>
>> Explanation:
>>
>> This can happen, when a part of the SG, is covered by another Node.
>> In this part, one
16 matches
Mail list logo
