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
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
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
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
(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...