GNOME Bugzilla – Bug 641721
Add animation when closing an app from the overview
Last modified: 2021-07-05 14:38:32 UTC
The shell should make a nice animation like on the N900 when closing an app from the overview instead of just making it disappear right away.
Define "like on the N900" (I don't have one so I have no idea what it looks like).
I quickly recorded a video showing this feature :) http://people.collabora.co.uk/~cassidy/n900-close-animation.avi
I agree that an animation would be nice. Not sure the n900 approach is the right one though.
I like the N900 animation, that would be nice. May be a simple fading (like it happens after opening windows) would be enough.
(In reply to comment #4) > I like the N900 animation, that would be nice. > May be a simple fading (like it happens after opening windows) would be enough. I think fade out and shrink (so it looks like the window is moving away as it disappears) would be a good thing to try.
I think determining the right animation concept for closing a window in the Overview should be related to determining an animation for opening a new window/application in the Overview via drag-n-dropping an icon (or some automated process like inserting new media) while in Overview. There already is a subtle fade-in animation when opening windows outside of the Overview, but new windows in the Overview seem to just instantly appear. Perhaps the non-Overview new-window-animation simply needs to be applied to the Overview? The N900 animation looks pretty rough, but a smooth rendering of Allan Day's fade-out-and-shrink sounds good for closing windows. Would it shrink to the center of the window or to one of the corners? Another example to keep in mind is OSX's Dashboard. When new widgets are added to the dashboard the new window animation is like something floating to the surface (the dashboard overlay being the surface of the water), ripples briefly moving away from the new window. When a widget is closed it is sort-of vacuumed into the close button. Watch this as reference: http://www.youtube.com/watch?v=WpNt4-p1ABc I think the ripples might be overboard on cuteness, but perhaps the new window animation could simply do an animation of a window quickly "growing" out of a small, centered dot. The animation could finish with the window slightly "overgrowing" and then correcting to the final size on the Overview. And the closing window animation shrink-and-fade into the "close" button. Or shrink into the close button and then fade the button. Or, if you really can't decide, you could always make the closed window appear to burst into flames. ;)
(In reply to comment #6) .. > Another example to keep in mind is OSX's Dashboard. When new widgets are added > to the dashboard the new window animation is like something floating to the > surface (the dashboard overlay being the surface of the water), ripples briefly > moving away from the new window. When a widget is closed it is sort-of vacuumed > into the close button. Watch this as reference: > http://www.youtube.com/watch?v=WpNt4-p1ABc > > I think the ripples might be overboard... Yeah I agree. :) Adding a widget in OS X is an unusual event, so they can afford to have a visually noisy transition. The operations that we are discussing, on the other hand, could be regularly used so they need to be subtle enough not to become annoying over time. Fade out and scale (similar to what Android does when you go to the home screen from an app, if you are familiar with that) still seems like the best option to me.
I also think fade & shrink will look good. It shouldn't shrink to a specific corner just shrink to it's own center.
I have an upcoming patch implementing this animation: https://docs.google.com/open?id=0B7XfgZAvKYVTYmMzOWMyODQtYjIzMi00M2ZmLWI0MGYtMTc2OTEzYjBjNTVl
Currently it's a little too much focus on the shrink part of the animation. It shrinks to nothing at the time opacity hits 0. I think it will look better to have it shrink to like 75% of original size at the time opacity hits 0 so it does look a little more subtle.
Created attachment 204899 [details] [review] proposed patch v1 This shrinks the thumbnail to 95% and fades out completely. Shrink-factor is adjustable. Known issues: * If the overlay feels like rearranging the windows during the animation it gets a little messed up for a second.
(In reply to comment #11) > Created an attachment (id=204899) [details] [review] > proposed patch v1 > > This shrinks the thumbnail to 95% and fades out completely. Shrink-factor is > adjustable. > > Known issues: > > * If the overlay feels like rearranging the windows during the animation it > gets a little messed up for a second. You probably don't want to animate and then close but instead take a picture of the thumbnail, close the window, animate the picture & remove it. What if the window refuses to close (it asks if you want to save a file before it closes). Then this patch already did the animation and cannot close the window. Use it to test the idea of shrinking and fading for the time being.
Created attachment 204903 [details] [review] workspace: Shrink and fade destroyed windows in the overview Sorry, I've had this patch for a week or two... never got around to uploading it. Anyway, I have a related patch that shrinks and fades windows when not in the overview when they are closed. I'll open a new bug if you want that too.
(In reply to comment #13) > Created an attachment (id=204903) [details] [review] > workspace: Shrink and fade destroyed windows in the overview > > Sorry, I've had this patch for a week or two... never got around to uploading > it. Anyway, I have a related patch that shrinks and fades windows when not > in the overview when they are closed. I'll open a new bug if you want that too. Nice. You chose 90% shrink, that's close to what I felt was right. This is in the _doRemoveWindow, right? I just found out that function was the place to start instead of _closeWindow. Anyhow..
Do we really want to fade the button and title? I found it better looking to just hide them, or hide the button but shrink and fade the title anchored to the bottom of the shrinking thumbnail.
(In reply to comment #15) > Do we really want to fade the button and title? I found it better looking to > just hide them, Yeah - I agree. Alex's patch works for me, it could do to be a bit faster though. (Alex - could you add the ability to change the speed?) Jasper - can't get yours to give me the desired effect!
(In reply to comment #16) > (In reply to comment #15) > > Do we really want to fade the button and title? I found it better looking to > > just hide them, > > Yeah - I agree. > > Alex's patch works for me, it could do to be a bit faster though. (Alex - could > you add the ability to change the speed?) You can just change this line: time: Overview.ANIMATION_TIME, (time is in seconds) ex: time: 0.1,
(In reply to comment #16) > (In reply to comment #15) > > Do we really want to fade the button and title? I found it better looking to > > just hide them, > > Yeah - I agree. > > Alex's patch works for me, it could do to be a bit faster though. (Alex - could > you add the ability to change the speed?) Jasper - can't get yours to give me > the desired effect! I didn't get Jasper's to work either. If this is still an issue by then I can keep working on this after the 14th. Then I'll be able to reinstall to git and go nuts. Overview.ANIMATION_TIME could be replaced by some const or local variable.
(In reply to comment #18) ... > Overview.ANIMATION_TIME could be replaced by some const or local variable. I had a play around with this last night. Making it slightly quicker (0.2 seconds) worked well.
So, the reason this is so difficult is because when a window is destroyed, we don't save the pixmap contents. When adding an unmap animation in windowManager.js, I inadvertently paused the destruction of the MetaWindowActor we were cloning, making me think it was working. What we need to do is copy the pixmap, swap out the MWA with the new texture, fade that out, and destroy it. There's always the question of what might happen if attempting to close the window doesn't close it, but instead pops up a dialog.
Review of attachment 204903 [details] [review]: (marking needs-work)
The bits for keeping the window texture alive during an unmap animation is now in place, so this should be a lot easier to implement now.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.