Summary: | Blender 3D causes Folder View icons to snap back after being dragged on the desktop (icons become immovable) | ||
---|---|---|---|
Product: | [Unmaintained] plasma4 | Reporter: | Mircea Kitsune <sonichedgehog_hyperblast00> |
Component: | containment-desktop | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED NOT A BUG | ||
Severity: | normal | CC: | cfeck, kwin-bugs-null, philipp, sonichedgehog_hyperblast00 |
Priority: | NOR | ||
Version: | 4.8.5 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Mircea Kitsune
2012-10-16 13:41:22 UTC
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. |