GNOME Bugzilla – Bug 97288
animation showing windows going to/from their source
Last modified: 2020-11-07 12:37:04 UTC
Greg merchan mentioned the following comments on usability list, and this is indeed what the mac does (at least in os9) In order to provide the illusion of persistence and a sense of continuity there should be an animation when a window is presented or hidden. Everyone should be familiar with minimise/restore animations, so I'll skip those. When opening a file from a folder, the animation should run from the file icon to the window to view the file. When the window is closed, there should be an animation from the window back to the file icon. If an icon is not visible, then the icon of its parent folder is used. Example: The Home icon sits on the desktop. When it is opened the animation connects the icon to the folder window which opens. Suppose that there is a folder called Mail in the Home folder. Again, when that is opened the animation connects the icon to the folder window. Now the user closes the Home folder. The animation connects the Home folder window to its icon. Lastly the user closes the Mail folder. Because its icon is no longer visible, the animation connects the Mail folder window to the next visible icon in the folder hierarchy, the Home icon. When opening a window from a menu - e.g., an app from a global app menu or a dialog from File->Save As... - the opening animation runs from the menu item to the window. If the menu item is no longer visible, the animation runs from the parent menu item and so forth. When the window is closed, the animation runs back to the menu item if it is visible (unlikely), or to its parent menu item. Global app menu example: The user opens the Applications menu and selects the Web Browser. Because the web browser takes some time to open, the Applications menu has already closed. When the window is finally presented, the animation runs from the Applications menubar item to the window. When the Web Browser is closed, the animation runs back to the Applications menubar item. Save As... dialog example: The user opens the File menu and selects Save As.... This window appears speedily, so the File menu will not have closed. The animation runs from the Save As... menu item to the dialog window. Because when the Save As... dialog is closed the File menu is also closed, the closing animation runs from the dialog window to the File menu bar item. In the event that the animation destination is a minimized window, the task bar representation will become the destination. Here are some options for the appearance of the animation: Windows style - a moving resizing title bar. Metacity style - a moving resizing black square. XOR square - like metacity style, but the color is "opposite" the underlying color. XOR lines - Lines connect the corners of one representation to the corresponding corners of the other. There are surely others, like Apple's "genie" effect. But the four I've listed seem speediest and least obtrusive. How to make it work? The window manager knows and determines where windows will appear, so it's the best candidate for doing the animation. Except for minimize/restore there is no specification for animations sources and destinations. The end-points may move from one app to another. The time for an app to show a window may also be long; if the window manager could know where the window should open, it could run the open animation immediately and leave a window frame with a message like "Loading Foo..." until Foo actually maps the window to be framed. That's a basic description of the interface. There are interface and implementation details which remain.
"implementation details which remain" is a pretty major understatement, this will be tricky to implement. I'm in favor of doing so but it's going to involve additions to the startup notification spec, the EWMH window manager spec, additions to GTK, additions to metacity, and probably additions to some desktop components. Plenty o' fun to be had.
Definitely a tricky implementation problem. Is one with big usability payoffs though, particularly if we can do more generically than MacOS and leverage it in more than opening file manager windows.
Another huge technical hurdle is that file manager windows will need to draw themselves faster for this not to just frustrate the user :-)
What about if the animation source is the file manager window instead a particular icon? Should be already effective as a visual clue, so it's visible that the application is starting, working in the current directory, and opening the selected file (which Gtk+ highlights with a "rubberband" anyway). Appears to involve less changing of other components to make it work.
Commenting here to bring it up again. The idea sounds good, but maybe was left over because of the ammount of changing involved. Should be more feasible now with the compositor?
Can't this be fixed by adding new optional fields to startup-notification giving X and Y coordinates?
I don't know if it's related, but how this is implemented on notification area icons? (e.g., Rhythmbox minimize-to-tray draws the iconifying/restore Metacity animation coming from and going to the tray icon and with the correct size too).
To the best of my knowledge, that's nothing to do with us. I think rhythmbox just draws rectangles and then removes them from the screen.
(In reply to comment #8) > To the best of my knowledge, that's nothing to do with us. I think rhythmbox > just draws rectangles and then removes them from the screen. > Looks like Rhythmbox isn't doing it for himself. Building metacity with animation style set as META_ANIMATION_WINDOW_OPAQUE (effects.c, line 443) shows the desired opaque animation for Rhythmbox minimize from/to tray icon too, so I guess metacity has total control on what and how the effect is done. But I remain curious on how Rhythmbox (or what else) triggers the animation on hiding to tray icon, and how the animation flows from and to the correct position. Anyway, the way this is handled could be implemented on, e.g., nautilus, so on double-clicking an icon, it launches the application for the document, and when the application is ready (can check this with startup notification?), draw the visual feedback coming from the icon to the application window (kind of a reverse minimize animation). What do you think?
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.