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

Reported by GianZap on 2009-01-18
66
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Do
Medium
Jason Smith

Bug Description

When Docky is not in autohide mode, every d'n'd action on the bottom third of the screen will fail, probably because the window manager (?) thinks that I'm dropping in the docky window (which occupies a huge part of the screen, as is evident by switching to metacity w/o compositing).
This means that one cannot reorganize icons on the bottom part of the desktop, but also d'n'd to any window placed on the bottom part of the screen won't work!
Steps to reproduce: just try to drag and drop something to any window in the lower part of your screen.

Do version: 7.96 from do-testers
Window manager: Compiz and Metacity
Distribution: Ubuntu Intrepid

Maybe it's possible to make Docky's window as large as the actual bar, and eventually enlarge the window geometry only when the icon zoom effect is performed or Do is summoned?

Jason Smith (jassmith) wrote :

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.

Changed in do:
status: New → Invalid

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

GianZap (gianzap) wrote :

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?

Jason Smith (jassmith) wrote :

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.

Jason Smith (jassmith) wrote :

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 =)

Changed in do:
assignee: nobody → jassmith
importance: Undecided → Medium
milestone: none → 0.8.1
status: Invalid → Confirmed

You, sir, are awesome. Thanks!

Jason Smith (jassmith) on 2009-02-07
Changed in do:
status: Confirmed → Fix Committed
GianZap (gianzap) wrote :

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!! :)

Massimo Tisi (massimotisi) wrote :

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.

Michael Rooney (mrooney) wrote :

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

manzur (sl-solaris) wrote :

i can confirm this in jaunty- amd64 bits

morryis (morryis) wrote :

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
>

Jukka Helle (squider) wrote :

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)

Dani Alonso (dalonso) 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.

Jason Smith (jassmith) wrote :

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.
>

Jason Smith (jassmith) wrote :

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

Dani Alonso (dalonso) wrote :

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?

Dani Alonso (dalonso) wrote :

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.

Massimo Tisi (massimotisi) 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.

Jason Smith (jassmith) wrote :

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.
>

Wade Menard (wade-ezri) 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.

Jason Smith (jassmith) wrote :

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.
>

Massimo Tisi (massimotisi) 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.

Jason Smith (jassmith) wrote :

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
>

Jason Smith (jassmith) wrote :

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
>

Jason Smith (jassmith) wrote :

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

Massimo Tisi (massimotisi) 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.

Jason Smith (jassmith) wrote :

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.
>

Alex Launi (alexlauni) on 2009-04-22
Changed in do:
status: Fix Committed → Fix Released
GonzO (gonzo) wrote :

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.

Changed in do:
status: Fix Released → Confirmed
Chris Halse Rogers (raof) wrote :

 status fixcommitted

Changed in do:
status: Confirmed → Fix Committed
Robert Dyer (psybers) on 2009-07-03
Changed in do:
status: Fix Committed → Fix Released
Alberto (alberto-arcagni) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers