From sdothum at gmail.com  Fri Nov 27 15:58:11 2015
From: sdothum at gmail.com (Steven Hum)
Date: Fri, 27 Nov 2015 09:58:11 -0500
Subject: herbstluftwm hook event processing
Message-ID: <20151127145811.4896.67440@luna>

Hello Thorsten,

I have tried applying a global rule to perform some frame management 
(essentially, when the feature is enabled, to place new windows in the 
next frame when more than 1 frame exists on the monitor) via

hc rule focus=on hook=focus_frame

"focus_frame" selects the next frame. In my workflow, I often want new 
windows to open in adjacent frames as I work in max a lot when editing.

In my emit_hook handler I have essentially..

herbstclient --idle '(focus_.*|rule|toggle_.*)' \
| while read hook rule winid
...
case $rule in
  focus_frame)
    if [ $dynamic ] ;then
      focus_frame
      bring $winid
    fi
    ;;

The next frame gets selected, but the new window opens in the current 
frame -- resulting in the next frame has focus (not the new window 
opened which is not where it is expected). "dynamic" is just a switch 
for the feature to preserve herbstluftwm's manual behavior.

I tried using xdotool -- just grasping at straws here as my 
understanding of X11 is nil -- and added this with no change in result..

  focus_frame)
    if [ $dynamic ] ;then
      name=$(herbstclient attr clients.$winid.instance)
      xdotool search --sync --onlyvisible --classname $name
      focus_frame
      bring $winid
    fi
    ;;

Any idea what I am misunderstanding? It would appear that the hook is 
being executed after the window creation as the next frame is selected. 
But the "bring" is not producing the expected results. I suspect with my 
non-existent knowledge of X11 and the herbstluftwm code, that the order 
of window events is not as linear or sequential as I require for the 
above to work. (Guess I need to start looking at the winterbreeze code.. 
is it available from the git repository?)

I suspect, this may not even be a good way to achieve what I am trying 
as this may cause some visual window activity (with the newly created 
window being redrawn in next frame) and that the only way to prevent 
this visual distraction would be to have some sort of "prehook" rule 
option that would allow executing the focus_frame script before window 
creation (if that is at all possible. Similarly, I could see use for 
a "posthook" to allow some sort of housekeeping after a window is closed 
-- I have a function attached to the "close_or_remove" command but that 
does not trap instances whereby the application quit is performed 
instead.)

At the moment, I have implemented the focus_frame behaviour by simply 
adding it to the few scripts I use to launch programs so the appropriate 
frame is selected before the application is launched. So it is not 
a huge deal (and herbstluftwm's lock/unlock feature is absolutely 
brilliant -- I don't know if any other tiling window manager implement 
that, certainly not ones I have configured extensively). But the hook 
method would have been cleaner IMO.

Looking forward to winterbreeze..

Regards,
Steven