Re: Project idea on "Big one hook"

[Jeremy Hankins <nowan nowan org>]

Teika Kazura <teika lavabit com> writes:
> What Jeremy recalls is this. I'll add it to the faq in 1.6:
> ------------------------------------------------------------------------
> Q:
> I wrote a code to hack focus / window stacking, but it doesn't work!
> It seems quite unlikely. Why?
>
> A:
> It's one of the trickiest subjects, mainly due to the timing.
> You have to understand the entire procedure in which your code
> lies. For example, suppose you'd like some fix when a window
> appears. Most commonly, before-add-window-hook, add-window-hook,
> after-add-window-hook, and map-notify-hook are called, in this
> order. Many functions are put there. (Evaluate each hook, and you can
> guess the rough meaning of each from their name.) Pay attention to
> their order, check the variables values, and you will probably come up
> with the way out.
>
> Yes, it's too complicated. Sorry for that. It may be improved.
> ------------------------------------------------------------------------
> I fear that my draft is not good enough.

Yes, I seem to recall having trouble amid all the window-adding/mapping
hooks at one point myself, though I don't remember the details.
Unfortunately, I don't really understand the process either.  What
sorts of things can be done to windows at what stage, and what sorts of
properties can be checked at the various stages, e.g.?  Looking over the
docs there seems to be:

 - before-add-window-hook
 - add-window-hook (deprecated, evidently)
 - after-add-window-hook
 - after-framing-hook
 - place-window-hook
 - map-notify-hook

And this is in addition to a similar list for window destruction, as
well as a variety of hooks for when windows:

 - (un)iconify
 - (un)shade
 - (un)maximize
 - change depth
 - change visibility
 - move (before, after, and during)
 - resize (before, after, and during)
 - "slide"
 - restack
 - cycle
 - ...and a few others when X things happen to windows.

So it's not surprising that hacking around in this area would be
complicated.  But I don't know that the complication is due to
unnecessary complication of the sawfish code.  It may just be
complicated.  ;)

> Now an example of this kind:
>
> On Fri, 26 Dec 2008 20:34:20 -0800, Ian Zimmerman wrote:
>> I added the following to my .sawfishrc.  It didn't change anything!  Why?
>> It's as if W-Tab cycling didn't count as focus change :-(
>> 
>> (defun my-focus-hook (w mod)
>>   (warp-pointer-if-necessary w))
>> 
>> (add-hook 'focus-in-hook my-focus-hook)
>
> This is before warp is added in Sawfish-1.5.

Looking at the thread it's not clear to me whether this was a bug in
sawfish or just the wrong way to do it.  It does seem odd that that
wouldn't work, though I don't know why it doesn't.

> Hook use by contributed scripts or users are encouraged. In fact, I
> aim to make them possible, like quoted case by Ian Zimmerman's, by
> simplifying system-side hook dependence.

Ah..

> On Sat, 26 Sep 2009 12:13:50 -0500, Jeremy Hankins wrote:
>>> There's nicety in Sawfish initialization; some open/require can
>>> break Sawfish,
>> 
>> Can you give an example of this? 
>
> Add to wm/windows.jl "open sawfish.wm.menus". IIRC Chris recently said
> opening sawfish.wm.util.prompt triggered a bomb. (I mean, your sawfish
> won't run.) That's why some functions have inline 'require', loading
> but avoiding breakage.

Well, sawfish.wm.menus requires sawfish.wm.windows (for the window
operations menu).  So opening it from windows.jl would create a loop.  I
don't know what made requiring prompt cause problems -- might it have
been something similar?  prompt.jl is also not a very modular module.

-- 
Jeremy Hankins <nowan nowan org>