I noticed that after a while, icons on my Folder View desktop become impossible to move (as if the "Lock in place" setting for icons is enabled). Whenever I drag an icon from one spot to another, it snaps back to the previous location once I let go of the mouse button. Sometimes moving the icon will work, and typically still succeeds in 1 of 20 attempts. Occasionally, the pointer turns into a red sign while the bug happens, which I think indicates the icon cannot not be moved there. The only thing that fixes it is restarting the computer (simply logging out then back in does not). Today I discovered that Blender 3D is the program that triggers this issue. After I open Blender (installed from the openSUSE repository) I can no longer move icons on my desktop until I restart. Reproducible: Always Steps to Reproduce: 1. Make sure your desktop layout is set to Folder View and you have several icons. "Lock in place" should be disabled, and you should be able to move icons around the desktop by click-dragging them. 2. Open up Blender then close it. Actual Results: Icons can no longer be moved across the desktop, and snap back whenever dragged. openSUSE is 12.2 64bit, KDE is 4.8.5 release 2 from the openSUSE repository, Blender is 2.63 from the openSUSE repository. Mouse navigation is set to single-click mode. Settings for the Folder View desktop such as "Sorting", "Lock in place" and "Align to grid" do not affect the issue after it happens. I believe Blender to be the only program that triggers the issue. Until the problem is fixed, I would appreciate a workaround to restarting if anyone finds one and can post it here (which would also make testing a lot easier).
I am pretty sure it is a Blender bug, because it is not only the Folder View that is affected, see bug 308068.
(In reply to comment #1) Tested again after restarting, and Blender is clearly the trigger. In my opinion (and from my limited understanding of how this works) it is a KDE problem because even once Blender is closed the issue still happens. Even logging out and back in does not help, so something stays stuck pretty deep in the system. It sounds like KDE allows Blender to mess around with some high components (if not it maybe Plasma Desktop or X do), and if Blender can do that any other application might have a bug that permanently breaks the session.
@KWin developers, any idea what is going on?
When this happens, can you stil mouse interact with the folderview (eg. click it to open a file) If *not*, open konsole, run "xprop > what_is_there.txt" and click the affercted area The cursor turned into a cross, hinting it's grabbed - the click will have no impact but produce some content in "what_is_there.txt" - which you would please attach here. Also please run "ps ax" to ensure there's nothing (no process) left behind by blender. What happens if you do not only logout/in but move to VT1 (ctrl+alt+f1), login, and run "sudo telinit 3; sleep 4; sudo telinit 5; exit"? Does the issue remain?
(In reply to comment #4) When the issue happens, I can still do all other activities in my folder view. Such as clicking files / folders to open them, right clicking them to get the menu, selecting items, etc. Just no dragging and dropping. I can also copy / move them, but only by selecting and using control + x and control + v. When I'll use Blender again I will try the "ps ax" command (don't wish to ruin my session now so I'll test again when I can). I can't guarantee I can try the last thing however since I usually have bad luck with those run levels and the only way to get out of them is to restart.
Sounds like the drop event ClientMessage get somehow blocked by blender. Can you please instead of the general output just check for "xprop | grep -i dnd" on the desktop? Reg. telinit: Unless disabled it will also be sufficient to "zap" the X11 server (ctrl+alt+backspace restarts it)
I'm using Blender again today, so I decided to test this. Here's the xprop output before opening Blender then after starting it and drag support breaking: mircea@linux-qz0r:~/Desktop> xprop | grep -i dnd XdndTypeList(ATOM) = text/uri-list, text/x-moz-url, text/plain, UTF8_STRING, STRING, TEXT, COMPOUND_TEXT, application/x-kde4-urilist, application/x-qiconlist XdndAware(ATOM) = BITMAP mircea@linux-qz0r:~/Desktop> xprop | grep -i dnd XdndTypeList(ATOM) = text/uri-list, text/x-moz-url, text/plain, UTF8_STRING, STRING, TEXT, COMPOUND_TEXT, application/x-kde4-urilist, application/x-qiconlist XdndAware(ATOM) = BITMAP mircea@linux-qz0r:~/Desktop>
(In reply to comment #7) > I'm using Blender again today, so I decided to test this. Here's the xprop > output before opening Blender then after starting it and drag support > breaking: Dead end. I'm installing blender - it's supposed to happen with a stable vanilla version (blender-5:2.64a) and not some customized or beta stuff, right?
Yes. I tried it with two versions of Blender and get it with both; Latest Blender from my distribution's repositories (openSUSE 12.2) which is 2.63a-2.1.3, and latest stable Blender from blender.org which is 2.64a. Both are the 64bit builds.
after quitting blender, run xprop -remove -root XdndAware (eg. in konsole or krunner) This is a blender bug, the root window is not it's top level window. It alters the DND protocol for the entire system and restricts it to level 3 ("ARC" is the Atom symbol for the integer 3) while apparently QML only supports 5 ("BITMAP") or rather 4 .. (http://www.newplanetsoftware.com/xdnd/) Since this is after gdk manipulating the root color table the second incident where stupid clients set their junk on the root window, it might be reasonable to file a bug against Qt to ignore stuff that's stored there in this regard because it very likely comes from a bogus client. *sigh*
I can confirm the line xprop -remove -root XdndAware fixes the issue after quitting Blender. Thank you very much! This is an important workaround and keeps having to restart the system to repair drag and drop support. I don't understand much of that description, since I don't know such deep technical detail. I just hope the problem can be fixed soon by the developers of what's causing it (either KDE, QT or Blender).
Blender, file a bug there (they might rely on some toolkit for this though, while my distro doesn't list such deps) Tell them to not write standard protocol properties onto the root window. The XdndAware property belongs onto the toplevel window they create (not even the eventual WM deco window), nowhere else. If blender btw. doesn't write that property too often you can maybe run it through a script like #!/bin/sh blender & sleep 10; xprop -remove -root XdndAware what starts blender, waits ten seconds (hopefully enough for the startup to complete) and then removes the property.
If anyone is still following this or finds it on google, and is interested in its status: One of the Blender developers says this bug should have been fixed in SVN rev52252, so the next version of Blender will normally no longer have it.
Blender 2.65 came out so I updated my binaries. I can confirm that after opening Blender, drag and drop support no longer breaks on my KDE desktop, so the problem is solved.
After upgrading to (debian packages) 4.10.2 I've got the same problem again - I cannot move mails by dragging them between folders in kmail. The xprop line didn't help, and logging out/in (without starting blender ;) doesn't help either. Any more ideas? Help, please?
(In reply to comment #15) No idea. I have openSUSE 12.3 with KDE 4.10.2 and no such issue. I assume it's not Blender since I use it daily and the latest version works fine. Check which program causes this or after how long it starts happening, then open a new ticket with details about the problem (this one is about Blender and solved so it might not be the exact same thing).
The problem is that dragging doesn't work for me _right_after_login_, so I cannot say what causes this. Are there any xprop things I can check?
(In reply to comment #17) Just to make sure it's not the obvious: Right click your desktop, click Folder View Settings, go to Display, and make sure "Lock In Place" is disabled and "Sorting" is set to Unsorted. If that doesn't fix it it's a problem beyond what I can think of.
If this is limited to kmail this is more likely a kmail/akonadi internal issue. The property set by blender globally restricts DnD to an *ancient* protocol which is no more supported by QML, likely no Qt5 - but would be by legacy QWidget (at least was last time i checked) so unless kmail uses now qml(?) this is likely not related at all.