Havoc: I'd say it's a bug in libwnck. There should be a callback for
showing_desktop_changed somewhere or something like that...

it may really be a metacity bug for not setting STATE_HIDDEN on 
windows when showing desktop. will need some tracking down.

I've looked at the code in metacity (meta_screen_show_desktop). And,
as far as I can understand the code, it looks to me Havoc is right
about the STATE_HIDDEN stuff. So moving to metacity.

*** Bug 142200 has been marked as a duplicate of this bug. ***

*** Bug 139445 has been marked as a duplicate of this bug. ***

Created attachment 30318 [details] [review]
Set hidden state for windows if we're in the showing desktop state

Here's a patch that almost does the trick.  When we enter showing desktop
state, not all windows are queued for update, and thus only the windows in the
current desktop actually get the net_wm_state_hidden property set.

However, bug 142198 aims to make "show desktop" be a per-desktop quantity
anyway, so I don't want to bother further until that patch is committed (or
rejected).  Note that due to bug 142198, we will have to replace
window->screen->showing_desktop with
meta_screen_showing_desktop_on_current_workspace (window->screen) in this
patch.

Oops, crap.  That was an old version of the patch where I had reversed logic. 
It is kinda fun to see the workspace applet empty unless you're in show desktop
mode, though.  But to get it right, remove the exclamation mark.

Created attachment 32683 [details] [review]
Updated patch

Here's a patch that takes into account the changes in bug 142198, and fixes the
logic reversal bug I pointed out in my last patch.

Comment on attachment 32683 [details] [review]
Updated patch

I think this will set HIDDEN on panels and desktop... probably need something
like "if this window would be hidden due to showing desktop, and we are showing
desktop"

Unfortunately I think this check is a bit complex, see
window_should_be_showing(), where it matters if the window is a transient of
the desktop or dock

Created attachment 32753 [details] [review]
Handle the needed cases from window_should_be_showing()

Lots of comments on this patch:

The patch in bug 142198 accidentally introduced a bug as part of an attempt to
optimize.  This basically means that under certain circumstances, sticky
windows will not show/hide appropriately when showing or unshowing the desktop.
 This patch reverts the few relevant lines from screen.c to fix this problem
(and adds a comment to help explain why the old method is necessary).

I split window_should_be_showing() into two by adding the function
window_showing_on_its_workspace(), which contains the portion of
window_should_be_showing() relevant to determining HIDDEN state. 
(window_should_be_showing() then just ANDs the boolean check it does with the
return value of window_showing_on_its_workspace()).  This should keep things in
sync better and, as a bonus, it simultaneously solves bug 144745.

Unfortunately, this patch actually doesn't quite solve this bug.  There's still
a small corner case (those who use sticky windows and use "showing desktop" and
move around between desktops when some workspaces are in the showing desktop
state and others aren't) which affects the pager display of sticky windows. 
This corner case exists because we have conflicting requirements:
  - windows are allowed to be on more than one workspace
  - "showing desktop" is now a per-workspace quantity instead of a global one
  - _NET_WM_STATE_HIDDEN is still a global quantity, not a per-workspace one
This basically means that we can't get "sticky" windows to work correctly with
showing the desktop for the pager (although the version I have makes the bugs
hard to discover).  I can see three solutions (though perhaps there are more):

  1) Don't allow windows to be on more than one workspace--obviously, sticky
     windows are stupid  ;-)
  2) Introduce a new state into the EWMH that replaces _NET_WM_STATE_HIDDEN
     and has the same general meaning but which is a per-workspace quantity.
  3) Implement the requested feature of having sticky windows "follow the
     user", meaning that they only appear in the pager for the current
     workspace.  This has been discussed from a usability perspective in bug
     87531.

For both solutions 1 and 3, we should probably ensure that a window's
window->workspaces list contain no more than one item.	I believe that's
currently true for Metacity, but we definitely don't enforce it.  It would be
nice to replace the GList window->workspaces with a MetaWorkspace*
window->workspace.

Personally, I think (3) makes the most sense.  I think Michael argues
convincingly enough for it (in bug 87531), we avoid sticky windows for the most
part so this change will only affect a niche anyway, and that niche group seems
to be requesting this feature occasionally anyway (I remember seeing a few
other requests for this behavior).  If we really decide we don't like it, we
could revert and then do (2).

Thoughts? Comments? Other solutions?

I agree with approach #3.

window->workspaces having multiple items was just designing for flexibility.
It's been that way since the very first draft of metacity iirc. I think changing
this should be filed/discussed as a separate bug though.

Comment on attachment 32753 [details] [review]
Handle the needed cases from window_should_be_showing()

This looks basically reasonable to me, I would say HEAD only due to risk?

I have some sense we might be recalculating whether a window is showing lots of
times, but until it shows up in a profile we can probably ignore it.

Committed to head, but the portion that reverts part of the ill-advised
optimization made by the patch in bug 142198 still needs to be committed to the
stable branch.  But, I'll reopen 142198 and post the patch there.  I'll also
open another bug as you suggest about having one window per workspace.

*** Bug 162010 has been marked as a duplicate of this bug. ***