[Sawfish] Race condition in window-order.jl

[ Thread Index | Date Index | More lists.tuxfamily.org/sawfish Archives ]


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
-- 
http://parenteses.org/mario

-- 
Sawfish ML


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/