GNOME Bugzilla – Bug 129443
Show desktop makes Empty Trash confusing
Last modified: 2004-12-22 21:47:04 UTC
This is a GNOME 2.4 desktop with Metacity and the "Show Desktop Button". 0) Click on "Show Desktop" button to show desktop 1) Right-click on Trash icon 2) Choose "Empty Trash" result: nothing seems to happen expect: Empty Trash confirmation dialog to appear 3) click on "Show Desktop" button to restore windows result: Empty Trash confirmation dialog appears with restored windows Even more confusing: if instead of clicking on "Show Desktop" button again you simply click on one of the minimized items, the clicked item will restore to the desktop and the Empty Trash confirmation dialog still may not appear. The Empty Trash confirmation dialog actually is present, but it is *under* the other windows rather than on top of them! Using Workspace Switcher to look at other workspaces, you find that the Empty Trash confirmation dialog is under the windows on each workspace, never on top of the other windows. The Trash icon is dimmed to show that it's waiting for the result of the Empty Trash dialog, but this is pretty subtle. This behavior could easily lead a user to believe that the Trash is broken. Note that no Nautilus features will work until the Empty Trash confirmation dialog is either OKed or Canceled, so the user could believe that Nautilus is broken!
Created attachment 22697 [details] [review] Proposed patch.
Created attachment 22698 [details] [review] Proposed patch #2. #1 contained unrelated fix, sorry
Good catch Steve! Thanks for this one. The patch works as described in [1] which is correctly implemented by metacity. regs, Chris [1] http://freedesktop.org/Standards/wm-spec/wm-spec-1.3.html#id2830316
Cool. upping priority.
This just makes the empty trash dialog without parent. I'm not sure this is right.
According to the specs it is. regs, Chris
You are so funny. There is a spec about how trash dialogs in file managers are supposed to behave? The trash dialog is currently modal, and there is a discussion about this in bug 75212. Its not really clear what the right thing to do is here, and this needs further consideration. Furthermore your patch is *not* following the spec you linked to. It removes the WM_TRANSIENT_FOR property, instead of setting it to None or the root window as the spec says.
*** This bug has been marked as a duplicate of 75212 ***