GNOME Bugzilla – Bug 693714
"Shade" is broken
Last modified: 2013-05-24 19:59:51 UTC
The "shade" action is normally not shown by mutter anymore, so I'm guessing it's just not supported anymore. But I still found "shade" and "toggle-shade" actions being suggested in the description of "org.gnome.desktop.wm.preferences" in dconf-editor, decided to try them out, and found them very broken (as opposed to merely ineffective). In particular, the "shaded" window is not resized to height = 0, but becomes transparent instead – even revealing portions of windows that are much lower in the z-order, curiously. mutter 3.7.5-37-g9de142d
Created attachment 235886 [details] Screenshot
Same problem here with mutter 3.7.92 running at Ubuntu 13.04
Same with mutter-3.8.0-1.fc19.x86_64 in Fedora 19 (pre-alpha).
*** Bug 697783 has been marked as a duplicate of this bug. ***
Still seeing this with mutter-3.8.1-1.fc19.x86_64 in Fedora alpha. Is there anything I can do to help diagnose this?
*** Bug 698780 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Still seeing this with mutter-3.8.1-1.fc19.x86_64 in Fedora alpha. > > Is there anything I can do to help diagnose this? There's really nothing to diagnose - the basic problem is that to properly handle a shaded window, you have to have *two* images of it: - One image to show in the overview - One image to show in the main view while for any other window, we simple have a single image of it, and use that both in the main view in the overview. It's possible to change the implementation of shading to replace the window with a substitute window when it's shaded, and keep the original window around unshaded for display in the overview, but it's a lot of work, and since shading isn't part of the GNOME 3 UI concept, it's never been on our priority list. To just get the shaded window to appear in it's shaded form, scaled down, in the overview, is easier, but that doesn't seem very satisfactory to me.
Got it, and that makes sense. > To just get the shaded window to appear in it's shaded form, scaled down, in > the overview, is easier, but that doesn't seem very satisfactory to me. Could it do this until whatever time the more complicated approach gets attention? Because given the choice between the feature not working nicely in the overview and not working in *either* view, I think I'd prefer the latter. :) I'd also like to submit this as an idea to consider more as part of the Gnome UI concept. As mentioned above, it's a way to temporary get windows out of the way while leaving a "handle" to get them back in the same basic spacial orientation -- much better than minimize. It fits very well with the way in which I personally use the Gnome desktop, and hopefully will be useful for others as well.
=== A Use Case for shaded window is: to look at the window(s) just below. This is useful to access some information that's just behind. For example when editing a document, and using information from a web page, and maybe from another application. Toggling with Alt+Tab will work with two windows, but not with more. When double click on the title bar toggles shade, user action are: 1. click-click --> shade the window 2. look at the window(s) below, 3. click-click --> get the first window back. Exactly the same on a real desktop when there are overlapping documents. What would be the GNOME way to cover this use case? === Another Use Case is: to temporarily simplify the workspace. This is done by "removing" windows, while still keeping a visual clue (the title bar), so we know exactly where they are. With the Overview, it might not be as straight forward because you need to identify it within the window list (which might be long in this use case). What would be the GNOME way to cover this use case? (I have another use case, but it's not really meant to be: to verify an horizontal alignment in a drawing, on a web page, etc. Open a random window, shade it, and use it as an improvised ruler (...))
Owen, Jasper, any tips on which part of the code to start hacking on this, so that we can fix the regression?
bisecting didn't work, but I'm starting to suspect this has to do with the shadow. Somehow the shadow is not informed that the window has been shaded. In the absence of other advice, I'll chase down this possibility (in my free time).
Some progress on working this out today, but not done yet. 1) meta_window_actor_get_obscured_region() should return NULL when shaded. This fixes the problem with the unpredictable contents of the box when shaded. After this patch you can see a predictable shadow in the old window size. --- a/src/compositor/meta-window-actor.c +++ b/src/compositor/meta-window-actor.c @@ -1637,6 +1637,8 @@ meta_window_actor_unmapped (MetaWindowActor *self) * Gets the region that is completely obscured by the window. Coordinates * are relative to the upper-left of the window. * + * Returns %NULL for shaded windows. + * * Return value: (transfer none): the area obscured by the window, * %NULL is the same as an empty region. */ @@ -1645,6 +1647,8 @@ meta_window_actor_get_obscured_region (MetaWindowActor *se { MetaWindowActorPrivate *priv = self->priv; + if (priv->window->shaded) + return NULL; if (priv->back_pixmap && priv->opacity == 0xff) return priv->opaque_region; else 2) Problem number two is that the shadow is always drawn in the full window size even when shaded. This code needs to take into account shading, check_needs_shadow(). if (priv->shadow_shape == NULL) priv->shadow_shape = meta_window_shape_new (priv->shape_region); Hopefully I'll pick this up again soon.
Created attachment 244290 [details] [review] compositor: Fix regression of shaded windows Fix issues drawing shaded window shadows.
Review of attachment 244290 [details] [review]: ::: src/compositor/meta-window-actor.c @@ +1646,3 @@ MetaWindowActorPrivate *priv = self->priv; + if (priv->window->shaded) Could just go into the existing condition (!priv->window->shaded && priv->back_pixmap ...)
Attachment 244290 [details] pushed as 6c4bcec - compositor: Fix regression of shaded windows Pushed to gnome-3-8 will push to master as well.
Excellent!
Hi there, Could this bug deserve a release a mutter, instead of waiting new release (it seems there is no .3 release planned on the GNOME schedule). Regards
Patched locally on my F19 system and confirmed that this works. Awesome, and thank you very much.
(In reply to comment #17) > Could this bug deserve a release a mutter, instead of waiting new release (it > seems there is no .3 release planned on the GNOME schedule). We're planning a 3.8.3 release of various modules next week. Mutter is one of them.