herbstluftwm hook event processing
Steven Hum
sdothum at gmail.com
Fri Nov 27 15:58:11 CET 2015
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
More information about the hlwm
mailing list