Bug 349360

Summary:	Mouse cursor not switching back to normal after it catches the "Splitter"-Cursor
Product:	[Plasma] Breeze	Reporter:	Florian <f.mahn>
Component:	QStyle	Assignee:	Hugo Pereira Da Costa <hugo.pereira.da.costa>
Status:	RESOLVED FIXED
Severity:	normal	CC:	cfeck, dev+kde, hugo.pereira.da.costa, mrypsilons, nate
Priority:	NOR
Version First Reported In:	5.2.2
Target Milestone:	---
Platform:	Kubuntu
OS:	Linux
Latest Commit:	http://commits.kde.org/breeze/5a1f5c22c014875da0554f24dccbb8601b75f929	Version Fixed/Implemented In:
Sentry Crash Report:

Description Florian 2015-06-19 00:32:15 UTC

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. ;)

Comment 1 Christoph Feck 2015-06-21 03:46:29 UTC

Does this also happen if you are not using Oxygen or Breeze widget style?

Comment 2 Florian 2015-06-23 04:47:23 UTC

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?

Comment 3 Hugo Pereira Da Costa 2015-07-19 16:52:41 UTC

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

Comment 4 Hugo Pereira Da Costa 2015-07-20 06:08:55 UTC

(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.

Comment 5 Hugo Pereira Da Costa 2015-07-20 12:19:46 UTC

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)

Comment 6 Hugo Pereira Da Costa 2015-07-20 12:27:43 UTC

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

Comment 7 Mister Ypsilon 2016-02-03 13:43:19 UTC

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?

Comment 8 Frank Steinmetzger 2020-12-01 21:54:12 UTC

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

Comment 9 Nate Graham 2021-10-08 17:43:29 UTC

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.