Unity Launcher steals minimize app animation end point from other docks

[Томица Кораћ]

If I use a dock app other than Unity Launcher (e.g. Docky, AWN, Cairo Dock, Plank etc.) and use an animation for minimizing my open windows (for example, 'Magic Lamp'), the animation should be ending on my dock app's icon for that window. However, more often than not, Unity's Launcher steals that end point, so on minimizing the animation's end point goes to the Launcher instead on the other dock app as it should. Same thing with the start point for the restore animation. This is most frustrating for me, it looks disgusting.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity 5.16.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic x86_64
ApportVersion: 2.0.1-0ubuntu15
Architecture: amd64
CompizPlugins: [core,composite,opengl,decor,move,snap,grid,vpswitch,compiztoolbox,commands,regex,winrules,imgpng,animation,mousepoll,resize,place,gnomecompat,unitymtgrabhandles,wall,workarounds,mag,expo,fade,session,scale,ezoom,unityshell,dbus]
Date: Fri Nov 9 22:20:01 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64+mac (20120425.1)
MarkForUpload: True
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

[Robert Dyer (psybers)]

There is actually nothing that can be done here. Only 1 location on the screen can be the icon region for an application. If you run more than 1 dock, then they will (at best) fight to set that region. Unity updates the region more often than say Docky, so it 'wins' in that situation. There is nothing the docks (or Unity) can do here.

[Robert Dyer (psybers)]

Please do not change the bug status for Docky. We consider this to be an Invalid bug.

[Томица Кораћ (tomicakorac)]

Thanks a lot for the quick reply Robert, and for finally clarifying this to me. I've been trying to get any useful information about this problem for at least a year, with nobody bothering to help me.

I'm not sure I get you. Before Unity Launcher was introduced, we had panels in our Desktop Environments, and they were acting as containers for the open windows' icons. However, they weren't causing (to my knowledge) any such conflicts. I don't see how different this situation now is, except that instead of panels we have Unity's Launcher.

[Robert Dyer (psybers)]

Also think about the general problem you are seeing. Your application has 2 locations on the screen that have a launcher for it: one on Unity and one on <some other dock>. How is the system supposed to know which of those 2 it should animate the minimize to?

You can solve the problem by only having ONE of the 2 contain a launcher for the program. So between Unity's launcher and <other dock> your application only appears on one of the two. In that case, it should work as expected.

[Robert Dyer (psybers)]

The panels also caused the problem. It is just that the frequency with which the panels updated the icon regions was (most likely) much less, so the dock would 'win' in that situation. Unity, as far as I know, updates the regions much more frequently (at least in comparison to Docky and Plank, which I work on). Thus Unity typically 'wins' against other docks.

[Robert Dyer (psybers)]

For reference, here is the standard property:

http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#id2760955

[Robert Dyer (psybers)]

I just realized I tend to call it 'icon region' when its actually named 'icon geometry'. Hope that didn't confuse you more! ;-)

[Томица Кораћ (tomicakorac)]

I see what you mean, here's what I think. For one thing, I hate the stupid Launcher, I don't need it, I don't want to use it and it makes my life miserable. Of course, that's my personal opinion and it differs from what Mark Shuttleworth thinks about the Launcher. That's why we now have the Launcher that can't be disabled, unfortunately. Anyway, my Launcher is always hidden (it's not showing on the screen) and I'm not using it, like, ever. I only use my dock apps (specifically Docky) and I only want them to manage my open windows.

For example, in CCSM > Animations > Effect Settings > Magic Lamp, there is a setting 'Open/Close Moving End'. As explained in Compiz Wiki (http://wiki.compiz.org/Plugins/Animation#Magic_Lamp), it determines whether the animation's end point will be focused to the pointer or not. What makes no sense at all to me is that this setting is only related to the animation's end point for opening or closing a window, while it has no effect if that same animation is used for minimizing/restoring. I really see no reason at all why we should have a setting for one thing, and not have a setting for the other. What if I want the same setting for both?

Of course, I'm talking just like a mere user, without any in-depth knowledge of the code behind. But this is a behaviour that doesn't make much sense. That's why I've reported this bug primarily against Unity. I wish, if after all we can't get rid of the terrible Launcher, we were at least able to minimize its negative impact on all the other useful apps.

What I think can be done, well, where you say 'Unity updates the region more often than say Docky, so it 'wins' in that situation.', pardon my dumb question, but couldn't you in that case make Docky update the region more often (what ever that means)? If I'm not mistaking, that would make Docky win again, wouldn't it?

And where you say 'There is actually nothing that can be done here. Only 1 location on the screen can be the icon region for an application.', then can anything be done to actually change the Desktop Environment, so that more than just one location on the screen can be the icon region for a window?

My point is, if only developers realize that something *should* be done here, than there would be plenty that can be done. And I mean the Unity developers here.

Finally, it's understandable to have a conflict if more than one dock are visible on the screen. But in that case why can't we simply have an option to have an animation's start/end point move to the cursor for minimizing/restoring, just like we have it for open/close? In my opinion, that would salve two problems: 1. the currently existing inconsistency for one and the same animation if it's used in open/close and in min/max; and 2. at least it would make more sense than minimizing a window from one dock, and having it go to a completely wrong direction.

[Томица Кораћ (tomicakorac)]

Also, what I can notice, and it completely responds to what you explained, is that while using Plank, this giltch occured only once in MONTHS! So once in several thousand clicks, that's actually fine. Whereas with Docky it starts after 5-10 clicks tops (sometimes even right after the first open window), and it stays forever, never getting better.

If only Docky was more like Plank in this, it would make a world of difference.

[Robert Dyer (psybers)]

"If I'm not mistaking, that would make Docky win again" Maybe. Maybe not. The point here is that they are both contending to set that geometry, so if Docky starts updating more frequently then you'll probably see much more non-deterministic behavior. They will fight even more!

"can anything be done to actually change the Desktop Environment, so that more than just one location on the screen can be the icon region for a window?" This is actually part of the WM standard, changing this is a lot more involved than you probably realize.

"why can't we simply have an option to have an animation's start/end point move to the cursor for minimizing/restoring, just like we have it for open/close?" You can, just ask Compiz for that feature. The animations are drawn by Compiz. However I make no promise that they would implement that. Personally, I think that is a bad solution and I wouldn't implement it.

There is one option you seem to be missing: stop using Unity. Switch over to something else, like XFCE.

[Томица Кораћ (tomicakorac)]

Of course I'm aware I could use other environments, but I like the other Unity's features, the Dash, HUD etc. I just hate the Launcher.

Thank you so much for your time, patience and explanations. What ever the cause is, I see Plank and Cairo practically never having this problem, and AWN having it to much less extent. Docky is the only dock app that "fights", as you described it, with the Launcher this much, and constantly losing. One, Docky is currently my dock app of choice, so I'd like to see this improved, and two, I'm pretty sure at least something can be done, so that Docky becomes more like Plank or Cairo, that's all.

[Robert Dyer (psybers)]

Docky 2.x is no longer under active development. Docky 3.0 and on will be based off Plank.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alex Baggott (alex-baggott)]

As part of the big bug review for 16.04 LTS I have tested this on 15.10 and the bug is still there. I think this is a feature request rather than a bug.

[Томица Кораћ (tomicakorac)]

Alex, what difference will this change of status make? Will it help this issue get solved faster?

[Dmitry Timoshenko (whityfenix)]

+1 Still the same on 16.04 LTS with Cairo-Dock 3.4.1.