GNOME Bugzilla – Bug 571109
Handle minimized windows better when switching to/from overlay
Last modified: 2010-01-23 16:31:06 UTC
When you switch to a desktop minimized windows animate as if they weren't minimized, then at the last minute go poof and vanish. would be nice if they animated toward the taskbar.
Created attachment 129339 [details] [review] patch for this bug
Created attachment 129340 [details] [review] patch for metacity-clutter Add minimized property to window.
I think you can use clone.realWindow.meta_window.showing_on_its_workspace() and not have to add a property (also gets the obscure case of "show desktop mode" right). I don't think the property is a bad thing, but we're trying to keep metacity-clutter changes to only what's really necessary things to avoid divergence from the upstreams. For bonus points, meta_window.get_icon_geometry() would allow animating into the taskbar rather than in place.
*** Bug 576631 has been marked as a duplicate of this bug. ***
Created attachment 131794 [details] [review] patch for gnome-shell Implement what Owen says. Needs a patch to metacity-clutter to make get_icon_geometry() public.
Created attachment 131795 [details] [review] patch for metacity-clutter
Created attachment 131811 [details] [review] Expose meta_window_get_icon_geometry() Here's what I applied to metacity-clutter. It adds a doc comment and a FIXME about how I think that the function *should* be annotated for gobject-introspection
metacity-clutter patch pushed to the gnome-shell repository and filed "upstream" as: http://bugzilla.openedhand.com/show_bug.cgi?id=1536 There's an additional possible enhancement that might make sense - which would be to cache the icon geometry and invalidate it when we get a property notify for the property. Having a round-trip for every minimized window on every desktop when you leave the overlay feels a bit ugly, though it's likely not anywhere close to worst performance problem at the moment. On the gnome-shell patch, two comments: 1) I have this feeling that the windows get too small too fast and there are just little dots vanishing into the panel. Does using a different easing function help? 2) You probably should check the return value of get_icon_geometry() - if it returns FALSE what's in rect will be more-or-less random (or maybe just 0s, but still not something meaningful.) Thanks a lot for the patches!
Created attachment 131846 [details] [review] patch for gnome-shell v2 Owen, thanks for the review. I fixed the points you raised in your last comment: - I used a linear easing function instead of the quad one. - I set the target scale to 0.2 instead of 0; IMHO it's nicer and doesn't give the impression of the windows disappearing from the view - I added a fade effect. If we get this patch in, I'd like to apply this effect also to the minimize action, as currently the windows are warped in the middle of the screen instead of going back to the taskbar. Do you think it's a good idea to do so? Want me to file a separate report?
Some thoughts trying out the new version: - Do you think the fading is too extreme? I get the impression of fleeting ghosts of windows, but it's very hard to tell what is going on. - I think it might be more effective you animated the center of the window to the center of the icon geometry instead of upper-left to upper-left. (See clutter_actor_set_anchor_point_from_gravity()) - What if you split the tween into two parts - one that animated the position with an transition of easeOutQuad, and one that animated the scale and maybe opacity with linear or easeInQuad - that would give the impression of the window moving quickly to the task list and then shrinking into it. (I wasn't sure if this would work with tweener, but it seems to in a quick test.) - if get_icon_geometry() fails would it be better to just not animate the position at all but have it shrink in place? (Having it fail seems unlikely with the current task list, but we might make the nature of the task list more flexible in the future.) - I get a warning: JS ERROR: !!! WARNING: 'trailing comma is not legal in ECMA-262 object initializers' JS ERROR: !!! WARNING: file '/old/home/otaylor/gnome-shell/source/gnome-shell/js/ui/workspaces.js' line 596 exception 0 number 161 Applying this to normal minimization definitely would make sense - there's an item on live.gnome.org/GnomeShell/Todo but I don't think there is a bug for it. Probably better as a separate bug report.
Created attachment 131955 [details] [review] patch for gnome-shell v3 Better patch: - fixes the comments of the last review round. - I tried *a lot* of combinations between tweener transitions, and this is the one I liked most. Without any opacity transition at all, it seems that the window disappears suddenly, but with opacity 0 it becomes transparent too soon. You can get another tone of effect which I personally like much, by changing the second tweener transition effect to "easeInQuint" or "easeInExpo", maybe that's what you meant with windows quickly moving to the tasklist and then shrinking into it. It might be a little too toyish though.
I like the effects as you have them in the patch. You could argue about the exact opacity value, or whether easeInQuint is better than easeInQuad, but it's quite good this way. But I see a problem where windows jump position at the beginning of the animation - this is more evident if you have only one workspace with only 2 or three windows in it. I dont' know if this is inherently a problem with putting two tweens on a single actor. (Removing the workspaceRelative modifier from the second tween doesn't help)
I opened bug 578147 for the window minimize effect.
(In reply to comment #12) > But I see a problem where windows jump position at the beginning of the > animation > - this is more evident if you have only one workspace with only 2 or three > windows in it. This appears to be caused by the call to clone.actor.move_anchor_point_from_gravity(). In fact, if you remove the tweens and just add: clone.actor.x = clone.actor.x; clone.actor.y = clone.actor.y; immediately after changing the gravity, you'll still see the jump. Clutter bug?
somehow this bug drifted away from its original description. I've updated the summary to reflect what's actually being discussed (and the original bug is now fixed).
(In reply to comment #14) > (In reply to comment #12) > > But I see a problem where windows jump position at the beginning of the > > animation > > - this is more evident if you have only one workspace with only 2 or three > > windows in it. > > This appears to be caused by the call to > clone.actor.move_anchor_point_from_gravity(). In fact, if you remove the tweens > and just add: > > clone.actor.x = clone.actor.x; > clone.actor.y = clone.actor.y; > > immediately after changing the gravity, you'll still see the jump. Clutter bug? Actually, you don't even need to re-set its position. It jumps if you just call move_anchor_point_from_gravity and do nothing else. This definitely seems to be some sort of clutter bug. Perhaps a bad interaction between ClutterClone and clutter_actor_move_anchor_point_from_gravity? But I've been unable to come up with a simpler test case that reproduces it.
*** Bug 589657 has been marked as a duplicate of this bug. ***
What about the other direction; going to the overlay ? The bug summary mentions both directions is why I ask.
In addition to minimized windows (which have to appear when entering the overview and disappear when leaving it), we also have the opposite problem, of toolbar/utility windows, etc, that should disappear when entering the overview and reappear when leaving it. None of these windows have anywhere obvious to go to/come from
One possibility would be to fix the patch to use the well icons as a source/destination rather than the task bar.
Created attachment 151551 [details] [review] Adds unobtrusive animations for hidden windows from/to overview. I attached a patch to this bug that animates hidden windows from/to the overview in an unobtrusive way. The windows are currently faded out/in and shrunken/grown when transitioning from/to the overview. I also made the hidden windows slightly transparent in the overview mode. I am not sure if this is desired, it's easy enough to remove from the patch in case it is not. I have still not found a workaround for the maybe-clutter-bug described above. I have added two TODO lines in the code, indicating that this should be fixed up sometime. I doubt that with an animation time of 0.25 the difference between shrinking the window to the center or the top-left is noticable, but if the animation time is made configurable one day, shrinking to the center looks nicer.
This e-mail to the mailing list http://mail.gnome.org/archives/gnome-shell-list/2010-January/msg00183.html contains a video of the proposed animation for minimized windows when going from the overview to the desktop: http://www.youtube.com/watch?v=aoXZBB1sRhA
(In reply to comment #21) > Created an attachment (id=151551) [details] [review] > Adds unobtrusive animations for hidden windows from/to overview. > > I attached a patch to this bug that animates hidden windows from/to the > overview in an unobtrusive way. The windows are currently faded out/in and > shrunken/grown when transitioning from/to the overview. > > I also made the hidden windows slightly transparent in the overview mode. I am > not sure if this is desired, it's easy enough to remove from the patch in case > it is not. Looks nice. Shrinking seems like a good compromise between getting the window out of the way quickly and doing something that can still be called "minimizing". Certainly a lot better than the "current" part of your video. I'm not totally sold on the slight transparency though.
(In reply to comment #23) > Looks nice. Shrinking seems like a good compromise between getting the window > out of the way quickly and doing something that can still be called > "minimizing". Glad you like it. Actually, while designing the animation I thought more about "hiding" rather than "minimizing". That's why the windows fade out rather fast. Windows don't really go anywhere (like a taskbar) - they just disappear. > Certainly a lot better than the "current" part of your video. That's really why I made the patch - the current non-animation started to annoy me. The video was actually made by Janne Liljeblad on the mailing list. > I'm not totally sold on the slight transparency though. I just searched bugzilla and discovered that 607338 is about giving hidden windows another appearance in overview mode. Discussion about this should probably happen there. The line is easy enough to remove from the current patch.
Created attachment 152060 [details] [review] Nicer animation of hidden windows when transitioning to/from the overview I've rebased your patch to the latest changes to the workspaces code. I also removed the lower opacity for the hidden windows in the overview and the TODO comments. I'm not sure how to get each window to shrink around its center point, but I think the patch works well as is and can be committed. clone.actor.set_anchor_point_from_gravity(Clutter.Gravity.CENTER); is putting the center point of the window preview at the x and y coordinates of the parent at which the (0,0) point of the window preview used to be, so it is not surprising that the window previews jump to the upper left when this code is uncommented. I see that similar code produces the desired result of the window shrinking around its center point in _minimizeWindow() in windowManager.js, but I don't know what the difference is. Btw, if you are experimenting with window animation, it's useful to know about a special parameter called Tweener.slowDownFactor that you can set (to say 5 or 10) in the Looking Glass prompt. http://live.gnome.org/GnomeShell/LookingGlass The patch doesn't have you as an author because of the rebase, so if you want you can make a new patch with the content from the patch I'm attaching or I can commit the patch as is.
Created attachment 152068 [details] [review] Patch with my name The patch now contains my name, apart from that it's the same (yay, my first patch to GNOME!). The jumping windows, even with the move_anchor_point_from_gravity (instead of set_anchor_point_from_gravity) function are really quite weird, but the animation looks decent without it. Thank you for telling me about this LookingGlass thing, it's really quite useful!
Thank you for the patch! New bug can be filed if we want to change the animation in any particular way.