After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 693714 - "Shade" is broken
"Shade" is broken
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.7.x
Other Linux
: Normal minor
: ---
Assigned To: mutter-maint
mutter-maint
: 697783 698780 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-02-13 14:59 UTC by Mantas Mikulėnas (grawity)
Modified: 2013-05-24 19:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot (268.50 KB, image/png)
2013-02-13 15:01 UTC, Mantas Mikulėnas (grawity)
  Details
compositor: Fix regression of shaded windows (1.36 KB, patch)
2013-05-15 09:29 UTC, Stef Walter
committed Details | Review

Description Mantas Mikulėnas (grawity) 2013-02-13 14:59:32 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
Comment 1 Mantas Mikulėnas (grawity) 2013-02-13 15:01:42 UTC
Created attachment 235886 [details]
Screenshot
Comment 2 Vinicius Seixas 2013-03-30 19:37:35 UTC
Same problem here with mutter 3.7.92 running at Ubuntu 13.04
Comment 3 Matthew Miller 2013-04-05 20:15:59 UTC
Same with mutter-3.8.0-1.fc19.x86_64 in Fedora 19 (pre-alpha).
Comment 4 Rui Matos 2013-04-11 12:02:06 UTC
*** Bug 697783 has been marked as a duplicate of this bug. ***
Comment 5 Matthew Miller 2013-04-27 02:22:36 UTC
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?
Comment 6 Andrea Antolini 2013-04-27 06:08:38 UTC
*** Bug 698780 has been marked as a duplicate of this bug. ***
Comment 7 Owen Taylor 2013-04-28 17:02:33 UTC
(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.
Comment 8 Matthew Miller 2013-04-28 17:20:51 UTC
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.
Comment 9 Luc Pi 2013-04-29 15:38:23 UTC
=== 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 (...))
Comment 10 Stef Walter 2013-05-09 04:17:56 UTC
Owen, Jasper, any tips on which part of the code to start hacking on this, so that we can fix the regression?
Comment 11 Stef Walter 2013-05-09 11:13:31 UTC
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).
Comment 12 Stef Walter 2013-05-10 20:20:11 UTC
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.
Comment 13 Stef Walter 2013-05-15 09:29:59 UTC
Created attachment 244290 [details] [review]
compositor: Fix regression of shaded windows

Fix issues drawing shaded window shadows.
Comment 14 Florian Müllner 2013-05-15 10:42:55 UTC
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 ...)
Comment 15 Stef Walter 2013-05-15 14:51:03 UTC
Attachment 244290 [details] pushed as 6c4bcec - compositor: Fix regression of shaded windows

Pushed to gnome-3-8 will push to master as well.
Comment 16 Luc Pi 2013-05-15 14:52:30 UTC
Excellent!
Comment 17 Baptiste Mille-Mathias 2013-05-24 18:39:45 UTC
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
Comment 18 Matthew Miller 2013-05-24 19:06:21 UTC
Patched locally on my F19 system and confirmed that this works. Awesome, and thank you very much.
Comment 19 Rui Matos 2013-05-24 19:59:51 UTC
(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.