Bug 261443 - dragging an item (file) over the taskbar doesn't raise the application (4.6 regression)
Summary: dragging an item (file) over the taskbar doesn't raise the application (4.6 r...
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 262561 262623 264359 264579 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-12-28 12:30 UTC by Patrizio Bassi
Modified: 2012-09-24 10:51 UTC (History)
18 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrizio Bassi 2010-12-28 12:30:44 UTC
Version:           unspecified (using KDE 4.5.90) 
OS:                Linux

Since 4.6rc1 file viewer widget doesn't allow the file to be selected and moved around

it shows a selection square allowing to select more files.

plus, if you try to drag the selected file over the taskbar in order to drop it in another application (for istance: select a file and add as attachment to firefox while displaying gmail) it doesn't work, it doesn't make the firefox to be selected and raised

this was fully working in a 4.5.x environment

Reproducible: Didn't try
Comment 1 Dario Andres 2010-12-29 13:45:16 UTC
[Comment from a bug triager]
As in bug 259335, is your Dolphin navigation setting set a "double-click to open file/folder" ?
Regards
Comment 2 Patrizio Bassi 2010-12-29 20:21:23 UTC
yes i can confirm i have double click set, plus that's the nasty drop and raise issue to the taskbar
Comment 3 Dario Andres 2010-12-29 22:27:06 UTC
[Comment from a bug triager]
May be we should consider that a different issue (but related to the FolderView issue). In that case I would recommend changing the title of this bug report to reflect the taskbar issue (considering that the issue about the drag-and-drop not working on FolderView is already been tracked at bug 259335)
Regards
Comment 4 Patrizio Bassi 2010-12-30 11:18:12 UTC
as mentioned by Dario, the double click issue is tracked at bug 259335, while here we track only the window raise issue
Comment 5 TR Reardon 2011-01-07 18:05:26 UTC
still broken in 4.6RC2

this is a significant usage regression.
Comment 6 Frank Steinmetzger 2011-01-07 23:51:52 UTC
I too have this, though I still have single click enabled.
Comment 7 Dario Andres 2011-01-09 00:50:31 UTC
*** Bug 262561 has been marked as a duplicate of this bug. ***
Comment 8 Dario Andres 2011-01-09 14:53:19 UTC
*** Bug 262623 has been marked as a duplicate of this bug. ***
Comment 9 Vlad Lungeanu 2011-01-11 08:37:40 UTC
I have it too. Extremely annoying when I have to attach some files to an e-mail.
Comment 10 Jonas Nyrén 2011-01-12 01:37:30 UTC
Same here, kde 4.6rc2. This is really a showstopper for 4.6 Final IMO.
Comment 11 Aaron J. Seigo 2011-01-12 03:44:09 UTC
SVN commit 1213906 by aseigo:

only accept drops of executables for launcher creation
BUG:261443


 M  +36 -6     abstracttaskitem.cpp  
 M  +1 -0      abstracttaskitem.h  
 M  +2 -5      taskgroupitem.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1213906
Comment 12 Aaron J. Seigo 2011-01-12 03:45:00 UTC
"This is really a showstopper for 4.6 Final IMO."

a showstopper is a crash, data loss/corruption bug or major functionality regression. this is none of those things. in any case, i've just committed fixes for this issue.
Comment 13 Aaron J. Seigo 2011-01-12 03:46:26 UTC
SVN commit 1213907 by aseigo:

only accept drops of executables for launcher creation
CCBUG:261443


 M  +36 -6     abstracttaskitem.cpp  
 M  +1 -0      abstracttaskitem.h  
 M  +2 -5      taskgroupitem.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1213907
Comment 14 Patrizio Bassi 2011-01-16 11:48:31 UTC
i can confirm patch works
Comment 15 Dario Andres 2011-01-30 14:46:37 UTC
*** Bug 264359 has been marked as a duplicate of this bug. ***
Comment 16 Dario Andres 2011-01-30 14:46:41 UTC
*** Bug 264579 has been marked as a duplicate of this bug. ***
Comment 17 Dario Andres 2011-01-30 14:48:14 UTC
[Comment from a bug triager]
Note: the last two duplicates are from KDE SC 4.6
Note 2: bug 261555 is also related (the same ?)
Comment 18 Fabio Rossi 2011-03-06 12:42:46 UTC
There is another regression: with KDE 4.5.5 you could drag a link between applications (for instance open a HTTP link by dragging it from akregator to firefox). Now with KDE 4.6.1 is not anymore possible.
Comment 19 Martux 2011-06-22 09:40:49 UTC
Hello!
I also want to report that the "drag and drop" of files doesn't work for me since 4.6.1 (on 4.6.4 it still doesn't do). Dragging files doesn't bring other applications in the foreground, directories do.
Comment 20 Florian Hubold 2011-06-27 19:11:57 UTC
Anyone noticed that the behaviour is related to the MIME type of the file(s) that are dragged? For me on KDE SC 4.6.3 this works with .avi files perfectly between Dolphin and VLC for example, but with .mp3 file(s) this does not work, and that is really a regression compared to 4.4.x and 4.5.x.
Comment 21 Martux 2011-07-03 19:24:41 UTC
*** This bug has been confirmed by popular vote. ***
Comment 22 Martux 2011-07-03 19:27:40 UTC
(In reply to comment #20)
Can't confirm. I tried a lot of different filetypes:
pdf, pmp, avi, mpeg, txt, jpg
I didn't works with any of them.
With png I had a strange occurance: One time it worked, the next time not...
With directories it works in general.
I tried to "update-mime-database" for root and user, didn't change anything.
Comment 23 Vlad Lungeanu 2011-07-04 07:37:02 UTC
The file type/extension does not matter. What matters is the "Executable" permission of the file. If it is checked, the file is treated as executable and the taskbar tries to create a shortcut for it. If you unset the Exec file permission, the taskbar will work normally.
My case: I have many files created in Windows, and they all have Exec enabled by default. So each time I wanted to drag-and-drop a file to another window (usually an e-mail message), I had to manually unset the Exec permission. Very annoying.
I fixed the problem by removing the normal taskbar and replacing it with "Smooth Tasks". After a bit of tinkering with the options, it looks and works just like the normal taskbar should, without the drag-and-drop annoyance.
Comment 24 Martux 2011-07-04 08:07:28 UTC
That seems to make sense. I also often create/edit files in windows. My data is generally on a shared ntfs-partition. Well, where can I find the so called "smooth tasks"?
I have the taskbar in an extra board on the botton of my desktop. There only "standard board or empty board" are available. Also under the miniprograms I can't find it.
Comment 25 Vlad Lungeanu 2011-07-04 08:17:14 UTC
@Martux: You can install Smooth Tasks via your favorite apt application. The package is called "plasma-widget-smooth-tasks". After install, it will be available in the widget list.
HTH
Comment 26 Martux 2011-07-04 09:00:32 UTC
@Vlad Lungeanu:
Thanks, that works. Strange. Why doesn't it work with the normal tasks?
Comment 27 Johannes E. Krause 2011-07-04 10:45:59 UTC
i think this is a total misfeature. why the hell would anyone drag&drop executables to the task bar? the quick starter maybe, but that is a totally different widget.

this should be removed and the 4.5.x behaviour restored.
Comment 28 Martux 2011-07-06 19:42:18 UTC
agreed. I mean, if they want to add it, OK. But breaking something much more important for that is unacceptable. I took a closer look at smooth-tasks. Some features are just better than normal, eg. middle click to set on active desktop > nice. Anyways, this program doesn't seem to be actively developed. Either add it in upstream KDE as replacement for the taskbar or fix the real one. Why should we dependent of some crappy, unmaintained hobbyist program (which many on kde-apps.org are sadly). Smooth tasks will break sooner or later, than the whole discussion begins again.
Comment 29 Andriy Gapon 2011-08-31 06:49:00 UTC
I can confirm the problem.
Please see some additional details here: http://article.gmane.org/gmane.comp.kde.freebsd/19640
Comment 30 Samuele C. 2011-09-03 09:48:41 UTC
url drag&drop doesn't work anymore either
Comment 31 dE 2011-09-28 04:53:54 UTC
Well then, lets see how it works in KDE 4.7
Comment 32 Martux 2011-09-28 06:19:42 UTC
(In reply to comment #31)
> Well then, lets see how it works in KDE 4.7

Still the same problem in 4.7.1... :(
Comment 33 dE 2011-09-28 11:29:02 UTC
I hope you all know the workaround for now...
Comment 34 Martux 2011-09-28 16:51:02 UTC
(In reply to comment #33)
> I hope you all know the workaround for now...

You mean "smooth-tasks"? That is rarely a solution as stated above. If you mean something else it would be nice if you'd give some hints...
Comment 35 dE 2011-09-29 11:19:26 UTC
Set the window to which you want to drag to "keep above others"
Comment 36 Florian Hubold 2011-09-29 18:02:50 UTC
Well, as already stated, here on Mageia 1 with KDE 4.6.5 with one of the above commits from aseigo, drag&drop works for most files. I've also got every file in question on an NTFS partition, so the executable bit doesn't really matter there as those files have no executable bit at all.

The only difference seems to be the mount point permissions. For external NTFS drives it works, as those belong to my user, but the internal partition for whatever reason belongs to root and from there drag&drop does not work.

Although other file access (deleting, renaming ... you name it) on those files works normally.


But should be fixed nevertheless properly for all file types, as this is clearly a regression compared to KDE 4.4/4.5 series.
Comment 37 dE 2011-09-30 14:17:24 UTC
The executable bit on FAT/NTFS can be set while mounting the partition.
Comment 38 Aaron J. Seigo 2011-09-30 14:32:33 UTC
this is as fixed as it is going to get. launcher creation with DnD was requested and deemed to be a more used feature than dragging executables between apps.
Comment 39 Samuele C. 2011-09-30 14:50:25 UTC
Aaron, what about url drag and drop?

Also, would a compromise solution be impossible? I was thinking maybe creating a launcher only when the file/url is dragged to the left area of the taskbar, since that is the area where the launcher is created.
Comment 40 Aaron J. Seigo 2011-09-30 15:10:05 UTC
Git commit 12cb6f5cd7939eec512f0dbec8be0ad3fac010d1 by Aaron Seigo.
Committed on 30/09/2011 at 17:07.
Pushed by aseigo into branch 'KDE/4.7'.

apparently something (bad) changed in QGraphicsView and now dragMoveEvent gets called repeatedly with the same pos

this made people confused about br#261443 as it was supposed to be fixed (it was) but a different issue entirely
had cropped up in the meantime. *sigh*

BUG:261443

M  +16   -14   plasma/desktop/applets/tasks/abstracttaskitem.cpp
M  +1    -0    plasma/desktop/applets/tasks/abstracttaskitem.h

http://commits.kde.org/kde-workspace/12cb6f5cd7939eec512f0dbec8be0ad3fac010d1
Comment 41 Aaron J. Seigo 2011-09-30 15:10:05 UTC
Git commit dbec0146e4ee6e6ec9d4bb56c88b556aa30b1b4d by Aaron Seigo.
Committed on 30/09/2011 at 17:07.
Pushed by aseigo into branch 'master'.

apparently something (bad) changed in QGraphicsView and now dragMoveEvent gets called repeatedly with the same pos

this made people confused about br#261443 as it was supposed to be fixed (it was) but a different issue entirely
had cropped up in the meantime. *sigh*

BUG:261443

M  +16   -14   plasma/desktop/applets/tasks/abstracttaskitem.cpp
M  +1    -0    plasma/desktop/applets/tasks/abstracttaskitem.h

http://commits.kde.org/kde-workspace/dbec0146e4ee6e6ec9d4bb56c88b556aa30b1b4d
Comment 42 Martux 2012-01-26 00:03:50 UTC
Ahm sorry, but I don't get how this is fixed by any means? Today I updated to KDE-4.8.0.
As foreseen, smooth-tasks stopped working now and doesn't even compile anymore. 
So now I am back with the stock taskbar and the problem still persists.
You guys are aware that this severely breaks the desktop experience?
I cannot d&d mp3 files or pictures or a lot of other files at all :(
Did I read one of the above comments right and this could be solved by giving an additional parameter in /etc/fstab to the NTFS partition? Which would that be? Thanks.
Comment 43 Martux 2012-01-27 22:58:35 UTC
Well, I learned that when mounting the partition with 
"noexec" it works. But that is not really helpful at all because there are some files on it which need to be executed :(
I really find it remarking that issues like this are simply being ignored or played down.
IMHO it severely breaks the complete desktop experience. Works since Win95...
Comment 44 dE 2012-01-28 05:01:42 UTC
I confirm this's still a bug.

It's been a long time since this critical bug is opened, similar to that automount and many other bugs.
Comment 45 Martux 2012-01-29 09:59:21 UTC
@dE: Thanks, I really thought I am crazy. So why is this not solved issue marked as solved?
Any ideas on my "noexec" issue?
Thanks
Comment 46 dE 2012-01-30 04:32:15 UTC
We need to file a new bug.
Comment 47 Mathias Tillman 2012-09-24 10:27:59 UTC
This problem is STILL present in 4.9.1. As I can see it's caused by the shouldIgnoreDragEvent method of kde-workspace/plasma/desktop/applets/tasks/abstracttaskitem.cpp, it seems to cause the taskbar to ignore all files that have the executable permission, so that you can add executable files as a launcher to the bar. But since NTFS drives are mounted as executable by default all files on there will be executable, which makes the taskbar ignore them.

I'm not entirely sure how one would fix this without messing up the launcher behaviour, but something needs to be done.
Comment 48 Christoph Feck 2012-09-24 10:51:16 UTC
Matthias, see bug 295142