Description: This is a patched version of the folderview plasma applet. The patch makes dragged file/folder icons translucent. It also makes it compile stand alone (without compiling the whole KDE Base Apps; changes to CMakeLists.txt).Last changelog:
Seems that it doesn't works well on kde 4.7.3
The problem is that it doesn't remember the location to show over logouts.
It always show the home folder.
Hi, the nasty rename bug has been just fixed:
https://projects.kde.org/projects/kde/kde-baseapps/repository/revisions/e36f73c7fc3eca7beb0ebb16664b4c855cdf513e
...but will be ready only in kde 4.8.
Why don't you patch your 'fork'?
Works as expected (glitches appears as in standard folderview when desktop effects are disabled, i don't know if something can be done about it).
Do you plan to propose your patch to mainstream?
I don't think this will be merged upstream, because it is an ugly hack.
What did I do: First I uncommented everything that was marked with "Reenable this code when Qt uses an ARGB window for the drag pixmap" and then I install an event filter, filtering every event on an application level during dragging (only when composite is enabled). In the event filter I look for move event. If I have found one I look if the class name of the moved widget is "QShapedPixmapWidget" (this is the name of the class of the widget used in Qt's D'n'D code). For objects of this class I then do (window is the dragged icons):
window->setAttribute(Qt::WA_TranslucentBackground);
window->clearMask();
Plasma::WindowEffects::overrideShadow(window->effectiveWinId(), true);
See a diff of all the changes:
https://gitorious.org/kde-baseapps-patched-folderview/kde-baseapps-patched-folderview/commit/c6b89b1fd14eb8f8f757e3f453fd5a2b30483b92
This happens on every move event, meaning on every pixel the dragged icons are moved. I think it could be optimized so it only happens once per drag, but I did not experience any performance issues so I didn't bother.
The correct way to solve this would be for Qt to allow these options to be passed to the drag action. Or to expose the drag-window so one could set the options them self. I would guess that sooner or later Qt would implements a way to do this, but then how long does this issue persist now?
Ratings & Comments
6 Comments
Seems that it doesn't works well on kde 4.7.3 The problem is that it doesn't remember the location to show over logouts. It always show the home folder.
I really only changed the thing about translucency. Also I don't have KDE 4.7 yet. Still using Fedora 14.
Hi, the nasty rename bug has been just fixed: https://projects.kde.org/projects/kde/kde-baseapps/repository/revisions/e36f73c7fc3eca7beb0ebb16664b4c855cdf513e ...but will be ready only in kde 4.8. Why don't you patch your 'fork'?
Works as expected (glitches appears as in standard folderview when desktop effects are disabled, i don't know if something can be done about it). Do you plan to propose your patch to mainstream?
PS: I just uploaded a new version because I forgot to change one single line. See: https://gitorious.org/kde-baseapps-patched-folderview/kde-baseapps-patched-folderview/commit/4fac6a84bf5ae402c4be5e9319d9f08325c8955f
I don't think this will be merged upstream, because it is an ugly hack. What did I do: First I uncommented everything that was marked with "Reenable this code when Qt uses an ARGB window for the drag pixmap" and then I install an event filter, filtering every event on an application level during dragging (only when composite is enabled). In the event filter I look for move event. If I have found one I look if the class name of the moved widget is "QShapedPixmapWidget" (this is the name of the class of the widget used in Qt's D'n'D code). For objects of this class I then do (window is the dragged icons): window->setAttribute(Qt::WA_TranslucentBackground); window->clearMask(); Plasma::WindowEffects::overrideShadow(window->effectiveWinId(), true); See a diff of all the changes: https://gitorious.org/kde-baseapps-patched-folderview/kde-baseapps-patched-folderview/commit/c6b89b1fd14eb8f8f757e3f453fd5a2b30483b92 This happens on every move event, meaning on every pixel the dragged icons are moved. I think it could be optimized so it only happens once per drag, but I did not experience any performance issues so I didn't bother. The correct way to solve this would be for Qt to allow these options to be passed to the drag action. Or to expose the drag-window so one could set the options them self. I would guess that sooner or later Qt would implements a way to do this, but then how long does this issue persist now?