Hello. I'm the one who reported the "sticky always focused" bug and fuchur was so kind to fix it. So I'm all for keeping this behavior intact, though, I can live with having to add an additional tag to sticky windows to get that behavior back. As far as I can see, sticky windows have to be "declared" by the user anyway, and as that is most likely happening through a rule it shouldn't be a problem
On Sat, 13 Jun 2015 21:53:04 +0000 Mario Domenech Goulart <[email protected]> wrote: > Hi, > > I've been experiencing a very annoying behavior in Sawfish. It is > caused by a race condition in > {record,restore}-focus-most-recent-at-workspace. > > I use M-SPC to hide/unhide my terminal window. So, whenever I want my > terminal, I just press M-SPC. It works across workspaces, since it is > implemented with move-window-to. The race condition shows up in cases > like: > > 1. Switch to workspace X and focus app A. > > 2. At workspace X, I need my terminal, so I press M-SPC and my > terminal is popped up. Now my terminal is the most recently focused > window at workspace X. > > 3. Switch to workspace Y and press M-SPC again to get my terminal. > > 4. Switch to workspace X again. No window is focused, since my > terminal had been recorded as the most recently focused window, but > now it has been moved to workspace Y. I expected app A to be focused. > > One solution, as a user, would be removing > record-focus-most-recent-at-workspace from leave-workspace-hook and > restore-focus-most-recent-at-workspace from enter-workspace-hook, but > it seems that it is not possible, since they are not exported by > sawfish.wm.util.window-order: > > client > (require 'sawfish.wm.util.window-order) > t > > client > (remove-hook 'leave-workspace-hook > record-focus-most-recent-at-workspace) (You're accessing an undefined > variable or function `record-focus-most-recent-at-workspace') > > client > leave-workspace-hook (#<closure > record-focus-most-recent-at-workspace @ sawfish.wm.util.window-order> > #<closure viewport-leave-workspace-handler @ sawfish.wm.viewport>) > > So, I think this static focus tracking approach is not a good > solution, since it is subject to race conditions in case > move-window-to is used. I have some suggestions to work around that > issue: > > 1. keep {record,restore}-focus-most-recent-at-workspace and export > them, but leave them out of {enter,leave}-workspace-hook by default. > That'd still be a hack and using it would still cause race > conditions, but at least would not be the default behavior. > > 2. dynamically determine the most recently focused window upon > entering workspaces (window-order-focus-most-recent). That's what > I'm doing. > > With regard to the comment > > ;; The problem is that any sticky windows that have been focused > once ;; will _always_ rise to the top of the order when switching > viewports ;; (since the topmost window is _always_ focused when > entering a new ;; workspace). The hacky solution is to record the > "input-focus" ;; window if leave a workspace and restore if reenter > the workspace. > > a possible work-around would be tagging sticky windows as not > focusable or cycle-skip, no? Of course, Sawfish shouldn't do that > automatically, but users who want to avoid the "sticky always > focused" behavior. > > Best wishes. > Mario -- Sawfish ML
