https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #18 from nyanpasu64 ---
Sadly the GTK folks don't think GTK4 is doing anything wrong, and I stopped
investigating, so I still don't know what the issue is.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=439137
Nate Graham changed:
What|Removed |Added
URL||https://gitlab.gnome.org/GN
|
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #16 from nyanpasu64 ---
FYI there is more investigation and discussion happening at
https://gitlab.gnome.org/GNOME/gtk/-/issues/4090. I think the buggy GTK4
behavior is not caused by the "dialog parent" race condition, but rather
because
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #15 from nyanpasu64 ---
I don't think the bug is solely in the demo program. gtk4-widget-factory and
gtk4-rs apps are also affected, and gtk3-demo (organized differently from
gtk4-demo), gtk3-widget-factory, and gtk3-rs apps are unaffected.
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #14 from qydwhotm...@gmail.com ---
An issue about gtk-demo is also reported.
https://gitlab.gnome.org/GNOME/gtk/-/issues/4090
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #13 from qydwhotm...@gmail.com ---
I studied the source code of gtk-demo, and found the bug may exist in the demo
program.
1. In main.c, gtk_demo_run() is called when "Run" button is pressed.
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #12 from nyanpasu64 ---
Who should comment on the GTK issue? I'm not the most well-versed in KWin or
the underlying X11 protocol causing this bug. If I were to comment on GTK, I'd
say:
"There's a race condition where GTK4 exposes a new
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #11 from Martin Flöser ---
Good! That explains the behavior. The placement is done in the manage method,
thus once we know it's a transient, it's too late.
I think this should go back to GTK devs to look into ensuring that the property
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #10 from qydwhotm...@gmail.com ---
I guess the window does change its WM_TRANSIENT_FOR property after its
initialization if I add debug messages to the right places.
I use a custom patch to add more debug information to
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #9 from Martin Flöser ---
(In reply to nyanpasu64 from comment #8)
> On the technical side of things, how would I "monitor the property states
> once the window gets mapped and then monitor for changes of the property"?
> Should I insert
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #8 from nyanpasu64 ---
On the technical side of things, how would I "monitor the property states once
the window gets mapped and then monitor for changes of the property"? Should I
insert debug statements into kwin? Or try reading kwin or
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #7 from Martin Flöser ---
>From the description it sounds that window gets mapped without the
WM_TRANSIENT_FOR property and KWin and likewise XFWM does not support changing
the state of that property.
I just checked ICCCM and could not
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #6 from nyanpasu64 ---
https://bugs.kde.org/show_bug.cgi?id=439137#add_comment
The upstream maintainers have replied:
(https://gitlab.gnome.org/GNOME/gtk/-/issues/4070#note_1197122):
> We set a transient parent, and mark the dialogs as
https://bugs.kde.org/show_bug.cgi?id=439137
qydwhotm...@gmail.com changed:
What|Removed |Added
CC||mgraess...@kde.org
--
You are
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #5 from qydwhotm...@gmail.com ---
Top-left corner:
kwin_core: transientFor.getTransientFor() returns False. "Dialogs <2>\u200E"
kwin_core: verifyTransientFor(): new_transient_for == XCB_WINDOW_NONE and set
is False. "Dialogs <2>\u200E"
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #4 from qydwhotm...@gmail.com ---
▣The transient status bool is defined
here(https://github.com/KDE/kwin/blob/8c8098a61c8990076f6d0866d662ab7980e49dc7/src/x11client.h#L559)
The default value of m_transientForId is equal to XCB_WINDOW_NONE.
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #3 from qydwhotm...@gmail.com ---
Running kwin_x11 using
env QT_LOGGING_RULES="*.debug=true;qt.qpa*.debug=false" kwin_x11 --replace
If dialog locates in the top left corner:
kwin_core: User timestamp, ASN: 2520815
kwin_core: User
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #2 from nyanpasu64 ---
I also noticed that in GTK4 apps, if the dialog spawns on the parent window
rather than in the corner of the screen, the KWin title bar will have an empty
space to the right of the X button (visible in Comment 1's
https://bugs.kde.org/show_bug.cgi?id=439137
--- Comment #1 from qydwhotm...@gmail.com ---
Created attachment 139780
--> https://bugs.kde.org/attachment.cgi?id=139780=edit
There are chances that the dialog window locates in the center of the parent
window.
It can also be reproduced on openSUSE
https://bugs.kde.org/show_bug.cgi?id=439137
qydwhotm...@gmail.com changed:
What|Removed |Added
Platform|Archlinux Packages |unspecified
CC|
20 matches
Mail list logo
