[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #33 from RJVB  ---
@Tsu Jan: now that you know that the KFileWidget triggers a QtCurve bug, do you
also know why it only happens with its 2 context menus? I'd guess it must be
something KFileWidget does in setting up those menus because the one that's
actually from KDirOperator works fine in other contexts.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #32 from RJVB  ---
Do you think you could try to get Kvantum to work on Mac? It currently builds
on my development system but doesn't work properly (doesn't show any SVG, I'd
guess), neither with the native Cocoa QPA nor with the XCB QPA.

Yichao, since you clearly know this part of the code much better than I and
actually understand what it does: do you think it could be possible to set
WA_TranslucentBackground` early in addition to the current approach, at least
for recent enough Qt versions where this solves our issue?

Also, you mention issues with Qt 5.0/5.1 - what would be a reasonable earliest
version to require? I'd guess 5.3.2 would be a good compromise but I don't know
if that helps us here?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #31 from Tsu Jan  ---
I forgot to say that I successfully tested this solution on two machines (one
very old and with nvidia, the other new and with Intel) and also on virtualbox,
with Qt-5.7.1 and Qt-5.5.x. All tests are done with Linux+x11.

I happily changed my active Kvantum themes to translucent ones on both machines
-- no fear of Qt5 window+menu translucency anymore ;)

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #30 from Tsu Jan  ---
@ Yichao Yu

I didn't work with QtCurve's code but, both practically and theoretically, I'm
sure that setting "WA_TranslucentBackground" before widget creation is the
safest solution. The code structures of QtCurve and Kvantum are very different
from each other. By "before creation" I mean only at "Style::styleHint()".
Here, it works flawlessly with Kvantum (I'll push the changes after testing for
2 days). I can't think of a reason why it shouldn't work with QtCurve after
some changes to the code structure.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Yichao Yu]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #29 from Yichao Yu  ---
The usage is basically unsupported by Qt and is a hack from the very beginning
so unless Qt provide a proper way to do it this is always a bug of the style.
The only question is that what's a better way to hack it.

Setting `WA_TranslucentBackground` was indeed what I started with
https://github.com/QtCurve/qtcurve/blame/58a4438b901311914d0d453c3987bfabbf258047/qt5/style/qtcurve.cpp#L406
. However, (at least in Qt 5.0/5.1) it causes many side effects that needs to
be undone and calling the private API/interact with the backend directly caused
much less trouble so I decided to switch to the current approach in
https://github.com/QtCurve/qtcurve/commit/c1543d2f27e5ac6f6424537a53e3764233967e68

The main issue with setting `WA_TranslucentBackground` is that applications
actually test/set it and messing with it creates lots of confusions in the
application/high level libs (iirc kwin and plasma together with their widget
libraries caused a lot of issues). OTOH, there are much fewer backends so
backend specific hacks are much easier to write without worrying about
application specific behaviors. Therefore, IMHO, the best solution (other than
having deeper support from Qt) is to interact with the backend directly and
make sure the native windows created have the correct events etc.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #28 from Tsu Jan  ---
Much to my surprise, after playing with various codes, I found out that this is
really a QtCurve bug!

Let me summarize the problem and its new solution:

To make Qt windows translucent, we should set the surface format of their
native handles BEFORE they're created. For Qt4, that could be done in
"Style::polish()". But Qt5 windows are polished AFTER they're created.
Therefore, setting of "WA_TranslucentBackground" in "Style::polish()" would
have no effect with Qt5. Early creation of native handles (as is done by
QtCurve) could have unpredictable side effects -- for menus if not for windows
-- because we don't know how it would affect the complex process of widget
creation. However, setting of "WA_TranslucentBackground" in an early stage
BEFORE the widget creation sets the alpha buffer size to 8 automatically and
safely.

When I implemented this logic in Kvantum (offline for now), all problems, that
I'd considered as translucency bugs of Qt >= 5.7, were gone :)

Doing the same thing for QtCurve isn't so easy because it requires changing of
the code structure. (Fortunately, in Kvantum, I'd used "QSet"
to track translucent widgets.)

I don't know whether setting of "Qt::WA_TranslucentBackground" to "true" before
widget creation has the same effect on Mac too but if the answer is no, there
won't be a safe way to make Qt5 windows/menus translucent/rounded on Mac.

@RJVB
Thank you for this report, without which I wouldn't have enough motivation to
wrestle with this problem!

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #27 from Tsu Jan  ---
Although satisfied with the "ensurePolished" solution on x11, I reverted to the
freeze code (with Kvantum) under KDE to study the problem a little and found
that actually there was a way to close the menu without killing any app. I'd
assigned the super key to the Plama main menu; so by pressing that key, the
main menu was shown and the KFileDialog menu was closed.

I used that opportunity to see which QEvents were triggered on opening the
freezing menu and to compare them with those of a normal menu. Freezing menus
lacked ChildPolished, PolishRequest and MouseButtonRelease events and instead,
had an extra ActionChanged event.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #26 from RJVB  ---
No, if the freeze were a deadloop one couldn't get out of it by clicking
swapping focus back and forth.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #25 from Tsu Jan  ---
OK, I just wanted to know if the freeze was caused by a loop, in which case
you'd see a difference. Before using ensurePolished(), I didn't see a high CPU
usage either.

The freeze -- without ensurePolished() -- is still a mystery to me. I'm not
good at tolerating mysteries ;)

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #24 from RJVB  ---
Wayland only works on Linux, i.e. a 2016 Intel N3150 with "Cherryview"
graphics. No idea if there's extra CPU usage that isn't simply due to
inefficiency in the simple Qt Wayland compositor. On the Mac: compared to what?
Even at 5y old, a 2.7Ghz i7 is still very powerful for rendering just a
drop-down menu...

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #23 from Tsu Jan  ---
I have a relatively new laptop with Intel and an old desktop computer with
nVidia. All menus are OK on both computers.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #22 from Tsu Jan  ---
Any extra CPU usage under wayland or Mac?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #21 from RJVB  ---
FWIW, I just tried under Wayland, using Qt 5.7.1's
qtwayland/examples/wayland/qwindow-compositor . Same effect without the patch
as on Mac: the menu freezes but can be unlocked by clicking on the desktop
background.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #20 from RJVB  ---
This is probably more an issue with the underlying OpenGL implementation, maybe
even the drivers for my GPU (a 2011 i7 with an Intel HD3000). I see the same
glitch when I use the XCB (X11) plugin on Mac.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #19 from Tsu Jan  ---
Created attachment 103238
  --> https://bugs.kde.org/attachment.cgi?id=103238=edit
x11 menus

All menus are OK on Linux (x11) now. Qt's behavior should be different in Mac.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #18 from Tsu Jan  ---
Strange! The whole point of ensurePolished() is to call `QStyle::polish()`
before creation of native windows. Here, on x11, it works not only with menus
but also with most top level widgets, although it's safe only with menus. And
in "qwidget.cpp" → `QWidget::ensurePolished()`, there isn't any Mac-specific
line.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #17 from RJVB  ---
Created attachment 103233
  --> https://bugs.kde.org/attachment.cgi?id=103233=edit
corner effect on Mac

Well, the fix does have some side-effects on Mac; rounded corners don't look so
nice anymore there, but show their background behind the rounded-off corners
(I've set the corners to max. rounded so it shows better in this screenshot).

It usually doesn't happen under X11 but more testing appears to be required.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #16 from RJVB  ---
They are ;)

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #15 from Tsu Jan  ---
Glad to know it works for QtCurve too! The developer(s) of QtCurve should be
informed about the whole problem and its solution.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #14 from RJVB  ---
You sire (sic) are a saviour!

I rewrote addAlphaChannel() so basically it does

if (qobject_cast(widget)) {
widget->ensurePolished();
} else {
// previous addAlphaChannel code
}

and that works around the issue on X11. I have yet to test on Mac.

Interesting observation: adding a qWarning() print probe before calling
widget->ensurePolished() shows that this was called during kdialog's startup,
regardless of whether I used the menu or not. No output was generated when
using the menu.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #13 from Tsu Jan  ---
OK, I may be wrong but I couldn't find any problem in kio. Of course, someone
knowledgeable about kio would know better.

I tested with Kvantum and found that ensurePolished() (only at
Style::styleHint()) is enough for all menus to have translucency and/or rounded
corners (will make a commit after some tests). I think QtCurve can do the same,
i.e. it can use ensurePolished() instead of addAlphaChannel() for menus --
although, as I mentioned above, most menus wouldn't need it. In other words,
addAlphaChannel() should be used only for window translucency.

All this trouble is because of https://bugreports.qt.io/browse/QTBUG-34064

P.S. This question isn't answered yet: why does the creation of a window handle
for KFileDialog's menu cause a freeze.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #12 from Tsu Jan  ---
I haven't found anything in kio yet but I'm pretty sure about this:

The freeze happens when a window handle is going to be created for those menus,
whether by setting WA_NativeWindow to `true` temporarily or by using
`createTLExtra()` and `createTLSysExtra()`, as QtCurve does. I mean, the freeze
isn't related to setting the format -- `setFormat()` -- but to the creation of
a window handle for menus.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #11 from Tsu Jan  ---
> You'll also have to look in kdiroperator.cpp, that's where the context menu 
> (for right-clicking on items in the file list) is defined.

Thanks! I will soon.

> I have rounded corners configured for popup menus, and that required some 
> translucency.

That's correct.

Anyway, I'll report back as soon as I find something in those files.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #10 from RJVB  ---
Heh, and your reaction taught about a widget style I never heard about, and
which might be even more appropriate to implement an "OS X" lookalike that
makes KDE applications actually looks good on Mac (without specific tuning) and
not as if they're designed for the visually impaired ;)

You'll also have to look in kdiroperator.cpp, that's where the context menu
(for right-clicking on items in the file list) is defined.

I think I understand why I'm running into issues  without using menu
translucency. I have rounded corners configured for popup menus, and that
required some translucency. You don't happen to have a suggestion how to obtain
that without calling addAlphaChannel() (or let it do only safe things), by
chance?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #9 from Tsu Jan  ---
@RJVB

Actually, I was lead to your report by google, while trying to know why
KFileDialog is an exception and which source file I should read. Your patch
says "kfilewidget.cpp". That will be a good start :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #8 from RJVB  ---
Ah, thanks!

This sounds like a reasonable beginning of explanation that just leaves 2
questions open:
- why is only the toplevel pop-up menu concerned, i.e. why can I open its
submenus normally when rendered in QtCurve as long as I use another widget
style for the parent menu?
- I don't have translucency configured in my QtCurve settings (all 3 parameters
are 100% opaque). That suggests that the operations required to obtain
translucency are what triggers the behaviour, not the translucency itself, and
offers the possibility of another workaround (behave as if translucency isn't
supported when not requested).

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[Tsu Jan]

https://bugs.kde.org/show_bug.cgi?id=374224

Tsu Jan  changed:

   What|Removed |Added

 CC||tsujan2...@gmail.com

--- Comment #7 from Tsu Jan  ---
I'm on Linux (Manjaro and Debian).

This problem happens only when QtCurve menus are translucent. Then, a freeze
occurs when an options dropdown submenu of KFileDialog is supposed to be shown
by selecting a menu-item. For me, the only way out of this situation has been
ctrl+atl+f2 and restarting sddm manually.

Qt5 window translucency requires setting of RGBA format before windows have
native handles. QtCurve does it in `Style::prePolish()` and
`addAlphaChannel()`, using private headers. Kvantum does the same thing in
`Style::setSurfaceFormat()` but without private headers.

Now, in Kvantum, I encountered exactly the same freeze ONLY WITH KFileDialog.
As a workaround, I excluded menus from `setSurfaceFormat()` because most menus
didn't need it for translucency (there are rare exceptions when both
WA_WState_Created and WA_NativeWindow are set for a menu, in which case, they
don't have translucency in Kvantum).

It isn't strange that this only happens with QtCurve because no other Qt5 style
engine (except for Kvantum, that has a workaround) supports translucent menus.
I haven't read the code of KFileDialog but as far as I know, QtCurve doesn't do
anything invalid. Therefore, I think the problem is in KFileDialog.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #6 from RJVB  ---
I'm not saying those patches should go into the code... but they *can* be used
by anyone who wants to look into this.

Debugging yes, but how (and with that I don't only mean "how do you get back
keyboard and mouse control")? The freeze/whatever happens nowhere near QtCurve
code, and could be triggered well before QtCurve code is called.

To make this even more subtle and beard-pulling at the same time: the freeze
only occurs with the toplevel context menus. Its submenus are fine, provided
you can get at them. In addition, the KDirOperator context menu only seems to
hang when used from within a KFileWidget. That is presuming that it's the same
context menu that is being shown when you right-click an entry in KDevelop's
file manager toolview; that particular menu just works.

And I think that this observation put much of the ball back in the KIO camp ;)
IOW, this may not be a bug in the usual sense of the term. There are many
context menus around KDE apps, but these 2 are the only ones I discovered that
fail to work properly.

@Martin Gräßlin: are you seeing this?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[David Faure]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #5 from David Faure  ---
Over my dead body ;-)

This needs debugging, and it sounds like the bug is in QtCurve itself, if it
doesn't happen with other widget styles.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #4 from RJVB  ---
Comment on attachment 103038
  --> https://bugs.kde.org/attachment.cgi?id=103038
workaround patch

the same hack has to be applied to `KDirOperator::setupMenu(int whichActions)`
(at the end of the method).

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

--- Comment #3 from RJVB  ---
Created attachment 103038
  --> https://bugs.kde.org/attachment.cgi?id=103038=edit
workaround patch

For now I'm applying this workaround patch which forces a different widget
style on the options menu, instead of (and only of) qtcurve. I made it possible
to override the workaround because it'd be nice to figure out what is going on
here.

Is it possible that this issue is caused by something in the aboutToShow
delegate?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 374224] KFileDialog Options drop-down menu grabs keyboard and mouse with QtCurve style

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=374224

RJVB  changed:

   What|Removed |Added

Version|unspecified |5.29.0
 CC||kdelibs-b...@kde.org
   Assignee|kdelibs-b...@kde.org|fa...@kde.org
 Resolution|UPSTREAM|---
  Component|general |general
Product|frameworks-kdelibs4support  |frameworks-kio
 Ever confirmed|0   |1
 Status|NEEDSINFO   |REOPENED

--- Comment #2 from RJVB  ---
After some more digging around it seems that the Options menu is provided by
KIO's KFileWidget (?)

-- 
You are receiving this mail because:
You are watching all bug changes.