Docky makes drag and drop impossible on a big region of the screen

This is a bug in Xorg. It does not pay attention to the input shape mask when doing drag and drop. I hacked around this when implementing autohide, but hacking around it for normal mode will be considerably more difficult.

Is this reported upstream and maybe even worked on? Is a bit annoying indeed. Do other docks such as AWN have the same problem?

Awn has the same problem, but on an horizontal stripe that is only slightly higher than the actual bar. Even if this is a bug in Xorg, and if the suggestion given in the bug report were not doable, I'd anyway suggest to make Docky's window a bit smaller. It would make the problem less evident.

Well take a look at this video. The docky drag and drop zone is way too big, it interferes with other applications. I was wondering why dragging and dropping between two nautilus folders didn't work this morning. Why is this bug marked invalid?

Mostly because I cant really do anything about it. Enabling autohide is the best suggestion I can make since I was able to hack around the issue. I will be trying to improve this in the future, but even then it will be a rough go.

Hell yeah, go me, go me, its my birthday, its my birthday. I have fixes this bug, I surprise even myself. It will be fixed in 0.8.1. When my branch gets merged, magic will be ours =)

You, sir, are awesome. Thanks!

I'm trying 8.0.1 from do-testers. Now d'n'd works for desktop icons and files (if you don't drop too fast..!! ;). It still doesn't work if you drag something out of firefox, e.g. if you select text / an image and then drag and drop it on the desktop / into a folder. By the way, I didn' find any bug on Xorg about this problem. Did somebody? Otherwise I / somebody should file it.

p.s.: thanks!! :)

Nautilus works now, but the bug should not be closed. The gnome-do window still affects several applications: the main issues are with firefox and vmware unity mode.

This bug seems to be back in Jaunty, can anyone else confirm or deny?

I can confirm, d'n'd between two nautilus folders do not work

lsb_release -rd
Description: Ubuntu jaunty (development branch)
Release: 9.04

gnome-do 0.8.1.2
bzr do r1106

i can confirm this in jaunty- amd64 bits

I can confirm this for Jaunty too. gnome-do 0.8.1.3-0ubuntu2

upsetting... it works on intrepid...

On Tue, 2009-03-24 at 00:10 +0000, morryis wrote:
> I can confirm this for Jaunty too. gnome-do 0.8.1.3-0ubuntu2
>

I don't know whether this is a different issue, but I cannot get any mouse input through the invisible part of the Docky window when Docky is not in auto-hide mode. Maybe consider resizing the window whenever possible?

gnome-do 0.8.1.3-0ubuntu2 on jaunty amd64 with xcompmgr (openbox)

This bug makes banshee barely unusable in Jaunty. All packages up-to-date.

When I connect my ipod, it is shown inside banshee treelist. I have it configured for manual maintenance, so it does not sync automatically with my music library. What I want to do is to drag & drop specific songs/albums to Ipod.

I was going crazy, blaming banshee for its bad ipod support. I almost filled a bug against Banshee when I realized that moving the banshee's window to the very top of the screen, out of the drag&drop region of Docky, made the drag&drop in Banshee to work again.

Please fix this bug, or remove the Docky interface, otherwise a lot of apps are going to be blamed without fault.

In all fairness it was fixed, somehow its broken in jaunty. I am
working on it but jaunty doesn't work on my box so its kind of difficult
to fix.

On Thu, 2009-04-02 at 11:50 +0000, Dani Alonso wrote:
> This bug makes banshee barely unusable in Jaunty. All packages up-to-
> date.
>
> When I connect my ipod, it is shown inside banshee treelist. I have it
> configured for manual maintenance, so it does not sync automatically
> with my music library. What I want to do is to drag & drop specific
> songs/albums to Ipod.
>
> I was going crazy, blaming banshee for its bad ipod support. I almost
> filled a bug against Banshee when I realized that moving the banshee's
> window to the very top of the screen, out of the drag&drop region of
> Docky, made the drag&drop in Banshee to work again.
>
> Please fix this bug, or remove the Docky interface, otherwise a lot of
> apps are going to be blamed without fault.
>

Ok, did a more robust fix in bzr. This should get every last edge case I hope

thank you Jason, i can confirm, this bug is fixed now even if you
drag something out of firefox as reported by Gianluca Inverso

Jason,

I just merged an built and all that I can say is that, unfortunately, it is not working in Jaunty. I still have the reported problem with banshee.

Sorry.

Could I help you to debug the problem some way?

Ooops, I'm really ashamed!!! I didn't test with the rebuilt version, sorry.

It is really working now. Congratulations and excuse me for the mistake.

Here on intrepid the situation is improved but not solved after the fix.
The region where drag and drop does not work is much smaller than before, about 100 pixels in height.

Can you give exact instructions on how you are causing the bug? I cant
cause it at all, even in the smaller region.

On Thu, 2009-04-09 at 12:39 +0000, Massimo Tisi wrote:
> Here on intrepid the situation is improved but not solved after the fix.
> The region where drag and drop does not work is much smaller than before, about 100 pixels in height.
>

With snap to edges enabled these changes make Docky grab windows being dragged by.

http://ezri.org/dockyedgesticky.ogv

Not sure its a solvable problem, though.

File a bug report with compiz for that

On Fri, 2009-04-10 at 06:48 +0000, Wade Menard wrote:
> With snap to edges enabled these changes make Docky grab windows being
> dragged by.
>
> http://ezri.org/dockyedgesticky.ogv
>
> Not sure its a solvable problem, though.
>

Since a picture is worth a thousand words I attach a screenshot.
"About Do" says r1124. The bug is tested with metacity and compiz.
The system is Intrepid with a few manually updated libraries (e.g. gtk 2.16 and mono 2.0.1). In a few days I will however upgrade to Jaunty.

The upgraded gtk is a big hint I think... I will check it out

On Sat, 2009-04-11 at 14:58 +0000, Massimo Tisi wrote:
> Since a picture is worth a thousand words I attach a screenshot.
> "About Do" says r1124. The bug is tested with metacity and compiz.
> The system is Intrepid with a few manually updated libraries (e.g. gtk 2.16 and mono 2.0.1). In a few days I will however upgrade to Jaunty.
>
> ** Attachment added: "Screenshot-1.png"
> http://launchpadlibrarian.net/25249762/Screenshot-1.png
>

Thanks for the gtk 2.16 hint there, that was the big one. Seems calling
gdk_screen_get_window_stack () is throwing an exception and therefor the
proxy isn't working. I'll have to try to work around that, but I dont
know if its possible. This bug needs to be assigned to the GTK# package
now as its a bug in their library.

On Sat, 2009-04-11 at 14:58 +0000, Massimo Tisi wrote:
> Since a picture is worth a thousand words I attach a screenshot.
> "About Do" says r1124. The bug is tested with metacity and compiz.
> The system is Intrepid with a few manually updated libraries (e.g. gtk 2.16 and mono 2.0.1). In a few days I will however upgrade to Jaunty.
>
> ** Attachment added: "Screenshot-1.png"
> http://launchpadlibrarian.net/25249762/Screenshot-1.png
>

Can you try latest trunk, I just committed a fix (I hope)

I tested the latest trunk with Nautilus and Firefox drag'n'drop, and the bug seems fixed. Thank you!

The only app that isn't fooled by the fix seems vmplayer. The most annoying symptom is that full screen windows in unity mode don't cover the lower part of the screen. The bug is certainly related to the d'n'd bug, since the troublesome area is exactly the same (about 100px from the bottom of the screen) and it was much bigger when this bug was reported. Anyway we could maybe open another report just for vmplayer.

Thats a new bug but I doubt we can do much about it. vmplayer would
have to properly check the window struts.

On Sun, 2009-04-12 at 07:58 +0000, Massimo Tisi wrote:
> I tested the latest trunk with Nautilus and Firefox drag'n'drop, and the
> bug seems fixed. Thank you!
>
> The only app that isn't fooled by the fix seems vmplayer. The most
> annoying symptom is that full screen windows in unity mode don't cover
> the lower part of the screen. The bug is certainly related to the d'n'd
> bug, since the troublesome area is exactly the same (about 100px from
> the bottom of the screen) and it was much bigger when this bug was
> reported. Anyway we could maybe open another report just for vmplayer.
>

I hope I'm doing the right thing to reopen this (changed status to "confirmed").

Gnome-Do 0.8.1.3 was released today, and this bug was supposed to be fixed by this release, but I've installed it from the PPA (Jaunty) with Jaunty's deps on three different computers, and the drag and drop problem still exists with this release.

It is fixed in trunk, which I'm using, so it isn't a huge deal... but when I left a comment on the 0.8.1.3 release bug, I was told to come here and reopen this one.

 status fixcommitted

I found the same problem with version 0.8.2 with autohide and intellihide and none hiding configuration.