| Summary: | dragging an item (file) over the taskbar doesn't raise the application (4.6 regression) | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma4 | Reporter: | Patrizio Bassi <patrizio.bassi> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andresbajotierra, aseigo, avg, csw, de.techno, dev+kde, doktor5000, drvladl, j.k, kde-2011.08, master.homer, mschoepf, pano_90, rossi.f, samchim, spectral, thomas_reardon, vovochka13 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Patrizio Bassi
2010-12-28 12:30:44 UTC
[Comment from a bug triager] As in bug 259335, is your Dolphin navigation setting set a "double-click to open file/folder" ? Regards yes i can confirm i have double click set, plus that's the nasty drop and raise issue to the taskbar [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 as mentioned by Dario, the double click issue is tracked at bug 259335, while here we track only the window raise issue still broken in 4.6RC2 this is a significant usage regression. I too have this, though I still have single click enabled. *** Bug 262561 has been marked as a duplicate of this bug. *** *** Bug 262623 has been marked as a duplicate of this bug. *** I have it too. Extremely annoying when I have to attach some files to an e-mail. Same here, kde 4.6rc2. This is really a showstopper for 4.6 Final IMO. 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 "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. 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 i can confirm patch works *** Bug 264359 has been marked as a duplicate of this bug. *** *** Bug 264579 has been marked as a duplicate of this bug. *** [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 ?) 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. 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. 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. *** This bug has been confirmed by popular vote. *** (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. 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. 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. @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 @Vlad Lungeanu: Thanks, that works. Strange. Why doesn't it work with the normal tasks? 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. 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. I can confirm the problem. Please see some additional details here: http://article.gmane.org/gmane.comp.kde.freebsd/19640 url drag&drop doesn't work anymore either Well then, lets see how it works in KDE 4.7 (In reply to comment #31) > Well then, lets see how it works in KDE 4.7 Still the same problem in 4.7.1... :( I hope you all know the workaround for now... (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... Set the window to which you want to drag to "keep above others" 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. The executable bit on FAT/NTFS can be set while mounting the partition. 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. 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. 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 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 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. 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... 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. @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 We need to file a new bug. 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. Matthias, see bug 295142 |