While using the Treeview-Style of the Systemsettings, the Mouse Cursor does not switching back to other Cursors if once you hovered over the vertical, resize able Listbox Borders. The Mouse stays with the Splitter-Cursor, everywhere in the Systemsettings-Window, equal which Setting-Subject you choose or over which Element You hover, unless you move over the Window Header (then gets back to normal). Reproduceable. Reproducible: Always Steps to Reproduce: 1. Systemsettings in Treeview-Design >>Fonts > Fontlist -Panel 2. Hover the Mouse over the vertical, resizeable Borders of the Listboxes (should now get the Splitter-Symbol : looks like <|> ) 3. Move Mouse over any other Element witch should trigger Mouse Courser -Change, to verify that it doesn't snap back to normal '--> Mouse Cursor gets to normal behavior, if hovered over Window Headder. Actual Results: Mouse Cursor snaps to Splitter (this one like <|> ) and does not flips back on other areas. Expected Results: The Splitter-Cursor should only stay as long as the Mouse hovers over the Listbox-Border. At least Mouse Cursor should flip back to Arrow, but respond also to the hovering over other Cursor-changing Elements. Mouse Cursor behaves normal outside the Systemsettings-Window Suggestions: - I think that the reason could be, that the Listbox-Element doesn't restore the original Cursor at the leave of the "try-Statement" properly, in which the Coursor-Switch should be executed. - Or the "Coursor-Backup-Variable" itself is overwritten accidently with the Symbol for the temporaly switch. ... Just mentioning my own favorite Bugs. ;)
Does this also happen if you are not using Oxygen or Breeze widget style?
I din't check this - but I used the presettings at thist time. Must have been Beeze, I think. Oh, I forgot to mention, that I used the Livesystem... if it matters. Do you want me to check for this?
Git commit 5a1f5c22c014875da0554f24dccbb8601b75f929 by Hugo Pereira Da Costa. Committed on 19/07/2015 at 16:43. Pushed by hpereiradacosta into branch 'master'. added option to configure shadow color default is set to Qt::black M +12 -8 kdecoration/breezedecoration.cpp M +4 -0 kdecoration/breezesettingsdata.kcfg M +5 -0 kdecoration/config/breezeconfigwidget.cpp M +56 -29 kdecoration/config/ui/breezeconfigurationui.ui http://commits.kde.org/breeze/5a1f5c22c014875da0554f24dccbb8601b75f929
(In reply to Hugo Pereira Da Costa from comment #3) > Git commit 5a1f5c22c014875da0554f24dccbb8601b75f929 by Hugo Pereira Da Costa. > Committed on 19/07/2015 at 16:43. > Pushed by hpereiradacosta into branch 'master'. > > added option to configure shadow color > default is set to Qt::black > > M +12 -8 kdecoration/breezedecoration.cpp > M +4 -0 kdecoration/breezesettingsdata.kcfg > M +5 -0 kdecoration/config/breezeconfigwidget.cpp > M +56 -29 kdecoration/config/ui/breezeconfigurationui.ui > > http://commits.kde.org/breeze/5a1f5c22c014875da0554f24dccbb8601b75f929 Ignore. Wrong bug number attached to the commit. Sorry Reopening.
If using breeze, can you go the the widget style configuration (see: http://wstaw.org/m/2015/07/20/plasma-desktopL29706.png) and uncheck "Enable extended resize handles" ? Does that fix the problem ? (compiling latest kde now to try reproduce the issue on my side)
Also, can you post a screenshot of the systemsettigns page that triggers the issue ? I want to make sure we are talking about the same. So far I do not seem to be able to reproduce. thanks Hugo
I just encountered a similar issue in dolphin with Breeze 5.5.4 If I enable split view and quickly hover over the slider again and again *while my GPU is under heavy load*, the cursor sometimes doesn't switch back to the normal pointer when i abruptly stop moving the mouse. When I click, hold and move the mouse now, I can actually move the slider, even though the cursor is far away from it. If I slightly move the cursor after it got stuck, it seems to always change back to normal again, but sometimes, during normal usage, the cursor gets completely stuck (which is why I started trying to reproduce it...) Unchecking "Enable extended resize handlers" *seems* to fix the problem, but it might only mitigate it very much. Also, reproducing this without heavy GPU load almost seems impossible. Do you think my issue might be related to this?
I just noticed the same behaviour in Dolphin on an up-to-date KDE installation. I looked for a report on that and found this ticket. No matter which splitter I move the mouse over -- left sidebar (places panel), right sidebar (file metadata), bottom bar (terminal), the cursor always changes to the appropriate move-splitter cursor, and also to the double-T cursor in the terminal pane and on the URL bar, but does not revert back to the normal pointer in any other area. Plasma 5.20.3 Frameworks 5.76.0 Qt 5.12.2 My widget style is QtCurve. All installed from normal Arch Linux packages
This was fixed a while ago in Breeze itself, and the issue some people recently saw in Dolphin was a regression which was likewise fixed recently.