GNOME Bugzilla – Bug 136858
No way to get the previous workspace in active_workspace_changed signal
Last modified: 2007-06-05 18:01:56 UTC
Currently when connecting to the active_workspace_changed signal in WnckScreen there is no way to know what the previous active workspace that was changed from was. The actual change of the workspace should probably be handeled in a default signal handler, so that connecting before or after will allow you to get the previous data. Or the signal could have an argument of the previous workspace (I think that is was the GtkNotebook does somthing simmilar to this). Either of these will break API though... (Even though I know it wont go in anytime soon, I might have time to hackup up a patch sometime soon, if you tell me which/if any of these options are preferable)
After posting the bug some additional things occured to me, so sorry about the spam. a. If such a change is made for the active_workspace_changed signal, it should probably also be done for the active_window_changed signal just for plain consistancy's sake b. it might make sense to add a boolean accumulator allowing the signal to 'cancel' switching the workspace/window. Though if the first option I mentioned earlier is used, I beleieve you could stop the emission of the signal and that should do it. (I am not 100% this works)
Moving to right component. Sorry for the spam.
This is not pager stuff. Updating the component.
Created attachment 88442 [details] [review] Patch to add the previously active workspace/window to the signal Here's a patch to do this. This breaks API again (yay :-)), but this is a more serious break than the others since this one will probably mean programs have to be updated for it (other changes were really less important). Elijah: do you think it's interesting to get this in? I believe it can make sense.
Elijah, Havoc: any comment about this? I forgot to commit this for 2.19.3, but I'll likely release 2.19.3.1 with all the final bits breaking API. So I'd love to have a final yes/no for this change :-)
As long as we're breaking API/ABI for other things, might as well throw this one on the list. :-)
Okay, it's in. (the attached patch contained some stuff that was not related to this, but I didn't commit this)