Bug 320893 - click release anywhere in a task item should activate the item
Summary: click release anywhere in a task item should activate the item
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Unmaintained
Component: widget-taskbar (show other bugs)
Version: 4.10.4
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2013-06-08 12:36 UTC by Teodor
Modified: 2013-06-17 13:28 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.11
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Teodor 2013-06-08 12:36:41 UTC
Some things won't select if your cursor was moved during the click.

For example:
  elements of task manager - windows won't select if cursor was moved during the click
 
  folders in file managers (A folder cannot be droped into itself, though it never can be done). I think, selected folder should open, instead of "A folder cannot be droped into itself"

  files in file manegers will open a dialog instead of opening thee file

  probably there are other things

Reproducible: Always

Steps to Reproduce:
1.hold left mouse button on task maneger element or file/folder in a file manager
2."accidently" move you cursor for several pixels, but within the element
3.release the button
Actual Results:  
the button don't work or shows unexpected dialogs

Expected Results:  
the button should operate as usual

if you don't wont to change that behavior you shuld add an option in mouse section in systemsettings, so people who don't want it whill not turn it on
Comment 1 Christoph Feck 2013-06-11 22:14:24 UTC
Please report the issue for each application individually. Ideally, the application should respect the "Drag distance" value set in System Settings > Mouse Settings > Advanced.

For Dolphin, I see it respects the drag distance when clicking on a file, so I am not sure which file manager you mean.

Reassigning to Plasma developers for the task bar issue.
Comment 2 Aaron J. Seigo 2013-06-15 14:04:23 UTC
(In reply to comment #1)
> Please report the issue for each application individually. Ideally, the
> application should respect the "Drag distance" value set in System Settings
> > Mouse Settings > Advanced.
> 
> For Dolphin, I see it respects the drag distance when clicking on a file, so
> I am not sure which file manager you mean.

I know this one :) Dolphin lets one drop a folder onto itself rather easily (folder icons are often much larger than the drag distance) and then shows an error. In those cases, an error really shouldn't be necessary.

In any case, I just tried with the new task bar coming in 4.11 and it does suffer from this problem and yes, it needs to be fixed.
Comment 3 Marco Martin 2013-06-17 09:52:16 UTC
Git commit ac9592832893cd6562dc0747f8afc1d7f89442c8 by Marco Martin.
Committed on 17/06/2013 at 11:50.
Pushed by mart into branch 'master'.

don't use startdragdistance here

emit click if the cursor is still in the area regardless of the distance travelled
this because MouseEventListener doesn't start drags
FIXED-IN:4.11

M  +1    -1    plasma/declarativeimports/qtextracomponents/mouseeventlistener.cpp

http://commits.kde.org/kde-runtime/ac9592832893cd6562dc0747f8afc1d7f89442c8
Comment 4 Sebastian Kügler 2013-06-17 13:28:36 UTC
Git commit 728cf2e53f95665c5140de36f65a4d4e643aa18c by Sebastian Kügler.
Committed on 17/06/2013 at 15:25.
Pushed by sebas into branch 'master'.

don't use startdragdistance here

emit click if the cursor is still in the area regardless of the
distance travelled
this because MouseEventListener doesn't start drags
FIXED-IN:4.11

cherry-picked from ac9592832893cd6562dc0747f8afc1d7f89442c8 in
kde-runtime

M  +1    -1    src/declarativeimports/qtextracomponents/mouseeventlistener.cpp

http://commits.kde.org/plasma-framework/728cf2e53f95665c5140de36f65a4d4e643aa18c