https://bugs.kde.org/show_bug.cgi?id=368337
--- Comment #9 from Elvis Stansvik <elvst...@gmail.com> --- 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 which trickery it uses. I think it's actually a regular QWidget, but with a manually set up OpenGL context "on top" of it. So that might be hard to detect... Also, in our real app, the GL widget is not directly added to the splitter, it's contained in another regular QWidget, so detecting would have to traverse the widget hierarchy I think... But if it is possible to detect, and you try such a workaround, could you perhaps make it so that the size of this invisible hit area is reduced in size only on the side facing the GL widget (could be both sides)? On a more philosophical note, I find it strange that in Breeze the splitter handle has no visual appearance. The only way to know it is there is to hover the area and notice that the cursor changes. This means the handleWidth property of QSplitter is not really respected by Breeze. Could a better workaround perhaps be to make the splitter handle have a visual appearance? That would give the user additional guidance when trying to hit it, and perhaps the workaround with the splitter proxy / hidden hit area is then not needed? [1] https://github.com/Kitware/VTK/blob/master/GUISupport/Qt/QVTKWidget.cxx -- You are receiving this mail because: You are watching all bug changes.
