[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 Jan Blackquill changed: What|Removed |Added CC||bugsefor...@gmx.com --- Comment #17 from Jan

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #16 from Hugo Pereira Da Costa --- (In reply to Elvis Stansvik from comment #13) > Or, I should rather say: > > 1. With Fusion, setting handleWidth to 4, I get a handle that is 4 visually > pixels wide,

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #15 from Elvis Stansvik --- (In reply to Hugo Pereira Da Costa from comment #12) > > Could 2 perhaps be fixed somehow? So that if the proxy is disabled, Breeze > > could draw the handle slightly larger (visually), like

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #14 from Elvis Stansvik --- Created attachment 104740 --> https://bugs.kde.org/attachment.cgi?id=104740=edit Fusion vs Breeze with handleWidth 4 -- You are receiving this mail because: You are watching all bug

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #13 from Elvis Stansvik --- Or, I should rather say: 1. With Fusion, setting handleWidth to 4, I get a handle that is 4 visually pixels wide, with a hittable area of 4 pixels. 2. With Breeze (proxy disabled), setting

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #12 from Hugo Pereira Da Costa --- > Could 2 perhaps be fixed somehow? So that if the proxy is disabled, Breeze > could draw the handle slightly larger (visually), like Fusion does? Because > as it is, if

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #11 from Elvis Stansvik --- As we're using more and more splitters in our application, several of them being having GL windows in them (VTK), this is becoming more and more of a problem. The problem from the point of

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #10 from Elvis Stansvik --- Sorry, I was wrong in the above. Breeze does respect handleWidth, but the default is for it to have no width, and unlike Fusion there are no "dots" or marks on the handle to indicate it is a

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #9 from Elvis Stansvik --- Ah, that could perhaps work. Though my test case just used QGLWidget because that was an easy way to make a minimal test case. In our real application it's a QVTKWidget [1], and I'm not sure

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #8 from Hugo Pereira Da Costa --- what I can try on the style size is to peek from the application what type of widget would be below the proxy before showing it, and disable, when detecting GL (or others

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #7 from Elvis Stansvik --- Sorry, posted the above comment before I read your reply. Thanks for the fast reply, I think I understand what is going on, and I understand the rationale for the proxy (since the default

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #6 from Elvis Stansvik --- Okay, I've now confirmed that disabling use of the SplitterProxy, by setting SplitterProxyEnabled to false in the Breeze style config, fixes the issue. So perhaps the problem is that the

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 Hugo Pereira Da Costa changed: What|Removed |Added CC|

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #4 from Elvis Stansvik --- My analysis might not be correct, as I just tried adding splitter->handle(1)->setAttribute(Qt::WA_OpaquePaintEvent, false); to the test case, and the problem remains. I see there's

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #3 from Elvis Stansvik --- Created attachment 100954 --> https://bugs.kde.org/attachment.cgi?id=100954=edit Screenshot showing the artifact issue -- You are receiving this mail because: You are watching all bug

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #1 from Elvis Stansvik --- Created attachment 100952 --> https://bugs.kde.org/attachment.cgi?id=100952=edit Test case source code -- You are receiving this mail because: You are watching all bug changes.

[Breeze] [Bug 368337] Consider disabling Qt::WA_OpaquePaintEvent for QSplitterHandle

https://bugs.kde.org/show_bug.cgi?id=368337 --- Comment #2 from Elvis Stansvik --- Created attachment 100953 --> https://bugs.kde.org/attachment.cgi?id=100953=edit .pro file to build test case -- You are receiving this mail because: You are watching all bug changes.