GNOME Bugzilla – Bug 603516
[PATCH] libwnck: Don't attempt to change workspace for pinned windows
Last modified: 2010-03-09 01:21:58 UTC
Created attachment 148846 [details] [PATCH] libwnck: Don't attempt to change workspace for pinned windows I found a minor, but annoying, bug in XFCE's Task List panel plugin, where window entries in the task list would lose their pinned status if the order of the items in the list were changed (via drag-drop). I traced the root cause to libwnck's wnck_window_move_to_workspace, which would always cause a window to become a member of the current workspace, regardless of its pinned status. Attached is a patch to do nothing if a window is pinned. I think this makes sense logically: if a window is on all workspaces, what sense does it make to 'move' it to another workspace? This could cause user-visible changes (such as moving a pinned window to another workspace via drag-drop on a panel workspace viewer plugin "failing" to unpin the window), but I think it is more correct for those other projects to first unpin the window, and then invoke the move, if that is what is desired. This allows for more fine-grained control over what behavior the user wants. If this patch is rejected as too user-visible, perhaps a more acceptable fix would be a check for the window's pinned status before the call to wnck_window_move_to_workspace, around tasklist.c:3659.
Hrm, it's a hard case. But I think I disagree: if you call wnck_window_move_to_workspace(), then it means you want the window to move to a specific workspace, and not to have it in the current workspace anymore. So having this result in unpinning the window feels right to me. Take a pager for example: if you drag a window and move it to another workspace, you definitely don't expect it to stay on your correct workspace. So I would think it's rather bug in the tasklist. I've fixed this (assuming XFCE uses WnckTasklist).