To handle minimise-to-tray properly in xfmedia, I'm using the skip_taskbar hint to simulate a _hide() (otherwise, the window gets hidden when you switch workspaces, because GDK_WINDOW_STATE_ICONIFIED gets set). So when the user clicks on the tray icon, two things happen: 1) We call gtk_window_iconify() on the main window. 2) The main window notices the state change, and sets skip_taskbar so the window is "hidden". 3) The taskbar notices the hint, and removes xfmedia from the taskbar. 4) Xfwm4 notices that skip_taskbar is set, and disables the "minimise" button on the titlebar. So assume the user clicks on the tray icon again: 1) We call gtk_window_deiconify() on the main window 2) The main window notices the state change, and unsets the skip_taskbar hint. 3) The taskbar notices, and shows xfmedia in the taskbar again. 4) However, xfwm4 does *not* put the "minimise" button back in the titlebar. To get the button back, I have to switch focus to another app, or switch workspaces and back.
hey brian, all this sounds a bit hacky, don't you think so?
Can you test with current svn trunk?
Yes, it's pretty hacky, but I can't come up with a better way to achieve the same effect. The old way, which involved calling gtk_widget_hide() on a window state change, was getting triggered when the user changed workspaces, because for some reason that action sets GDK_WINDOW_STATE_ICONIFIED. The result there is that, when the user switches back to the workspace xfmedia is on, the window is gone. (Just FYI, this is only when the user has "Minimize to Tray" selected. If they're just using the systray icon as usual, this hack isn't needed.) Anyway, svn trunk works for me, though when re-showing the window, it looks like the button is there, then quickly disappears and reappears. It's just a minor visual glitch; personally it doesn't matter to me.
Looks like this is fixed...