Atm plugins have no notion whether they are hidden or not. This could be improved by making the following API changes: Add 1 or more signals to monitor when a panel is hidden or visible. The panel uses 4 stages for this action: 1) Enter notify, here we start a timeout to show the panel. The user has to 'focus' the hidden panel for at least 225ms before the popup occurs. 2) When the condition above is true, the panel shows. 3) Leaving the panel either stops the timeout from 1 (leave early, then the panel never pops up) or start a timeout to hide the panel. 4) Panel is hidden again. The question is which stages are interesting for plugins: i'd say 2 and 3, but 1 could be used to make the plugin 'ready' for popping up. Other api addition could be a function like xfce_panel_plugin_get_panel_hidden(). Plugins could use it if an update is needed (read the current state). NOTE: Currently when a panel window is hidden, the window is resized, which results in weird size allocation for plugins. This will be fixed in the 4.8 panel.
s/i'd say 2 and 3/i'd say 2 and 4/
I see three reasonable options: = A = Emit the signal: - "show" when the panel becomes visible on the screen. - "hide" when the panel becomes hidden off the screen. = B = Emit the signal: - "show" when the user moves the mouse over a hidden panel. - "hide" when the panel becomes hidden off the screen or when the user has left early (when "show" was emitted but the panel won't be shown). = C = Emit the signal: - "pre-show" when the user moves the mouse over a hidden panel. - "show" when the panel becomes visible on the screen. - "hide" when the panel becomes hidden off the screen or when the user has left early (when "pre-show" was emitted but the panel won't be shown). This lets the plugin dev determine whether show or pre-show is appropriate for that plugin. = Code Outline = Coding a monitor for any of these options would look very similar: on "show" (or alternatively "pre-show") signal: update the monitor [1] set a timeout to update again soon on "hide" signal: delete the timeout on the timeout: update the monitor [2] [1] When listening on "pre-show", if the timeout interval is <225ms, this update is not necessary. In general, I think the timeouts are at least 0.5s, though. [2] It's ok if we happen to update the monitor an extra time in the rare case that the "hide" handler isn't called quite soon enough. = My Opinion = Although (C) gives the most flexibility to the plugin dev, I can't think of any plugins that would greatly benefit from that. I think it'd be reasonable to write the API documentation in such a way that the interface is purposely ambiguous between (A) and (B). Then, we can see which one feels snappier on fast and slow hardware and make a decision. While I'd bet on (B) appearing faster than (A) to the user, it's possible that it could introduce a noticable lag any time you accidentaly move the mouse over a hidden panel on slow hardware. Thus, I think it'd be best to test it experimentally.
It's also possible to create a signal like this: void (*panel_state_changed) (XfcePanelPlugin *plugin, XfcePanelState state); where state is an enum like: typedef enum { XFCE_PANEL_STATE_MOUSE_OVER, XFCE_PANEL_STATE_VISIBLE, XFCE_PANEL_STATE_MOUSE_OUT, XFCE_PANEL_STATE_HIDDEN } XfcePanelState;
(In reply to comment #0) > Atm plugins have no notion whether they are hidden or not. A question here concerning the status icons, i see when the panel goes into hide mode i receive a size-change event of size 1 and then the normal size when the panel is shown again. So can i say when i have the size 1 that's means the panel is hidden ?
(In reply to comment #4) > So can i say when i have the size 1 that's means the panel is hidden ? No, Nick said in comment #0: > NOTE: Currently when a panel window is hidden, the window is resized, which > results in weird size allocation for plugins. This will be fixed in the 4.8 > panel.
Nick, would you be looking for a patch on this one, or do you plan to implement it?
Implementing this is easy (and a patch is useless since the new panel has completely new code), so all i want is plugin developers feedback on how to implement this.
Any opinions on this? I think the state changed signal is quite easy to use and also easy to extend in the future.
(In reply to comment #8) > Any opinions on this? I think the state changed signal is quite easy to use and > also easy to extend in the future. I think it's reasonable, fwiw.