Re: [Sawfish] Race condition in window-order.jl

["Robert 'Bobby' Zenz" <Robert.Zenz@xxxxxxxxxxxxxx>]

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 <mario.goulart@xxxxxxxxx> 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