Re: Project idea on "Big one hook"

[Timo Korvola <Timo Korvola iki fi>]

On Saturday 03 October 2009 09:07:19 Teika Kazura wrote:
> If the example I cited is impossible, then it should be clear to
> users.

Which example do you mean?  I didn't try to debug the window cycling 
vs. pointer warping case, but x-cycle.jl is rather complicated.  It is 
not a very representative example of the hook mechanism in general.  
Window cycling runs in recursive-edit under a synchronous keyboard grab.  
The other example I recall you mentioned is modifying the results of 
window matching.  There you have more of a point: it is a bit unclear 
and entirely undocumented that the essential difference between before-
add-window-hook and add-window-hook is that window matching runs as the 
last thing in before-add-window-hook.  There is also after-add-window 
hook but that runs after placement - if you want to modify placement, it 
is too late there.  You also mentioned focus and stacking in general but 
provided no concrete example.

>  And I'd like a tutorial which describes what happens in typical
>  events.

The docs could certainly be improved.  Giving the big picture is 
what a proper manual is needed for.  Descriptions of individual 
functions and variables can be found in docstrings (except that 
sometimes they can't, but they should). 

>  Those who don't know the difference between window addition
>  and mapping must be many.

In X, a newly created window is invisible or "unmapped".  It needs to be 
mapped to become visible.  The idea is that you can create the window 
and all contained windows or "children", then map the whole lot.  Then 
the user does not see any flicker while the contents of the window are 
being created.

A reparenting window manager like Sawfish has a SubstructureRedirect 
event mask on the root window.  Therefore, when a client asks X to map a 
top level window, i.e., a child of the root window, the window does not 
get mapped automatically.  Instead, Sawfish gets a MapRequest event and 
responds to it by creating a window frame, reparenting the client window 
into the frame, and mapping both.  After the window has been mapped, X 
sends a MapNotify event to interested parties, including Sawfish.  
[before-]add-window-hook, place-window-hook and after-add-window-hook 
run in various stages of MapRequest processing, whereas map-notify-hook 
runs during MapNotify.

> On Wed, 30 Sep 2009 00:56:03 +0300, Timo Korvola wrote:
> > The simplest solution is splitting the hook in stages, i.e.,
> > several hooks that are called in sequence.
> 
>  I've thought of this too, but I've discarded it. It *is* what you
>  call a problem, relying on the order, isn't it?

Sometimes there just are dependencies among functions that cannot be 
ignored.  If processing can somehow naturally be split in sequential 
stages, it may guarantee just enough order.

>  But this situation where "by chance" is required can't be
>  called a specification. It is a lack of acceptable design.

Or perhaps a shortcoming of documentation.

>  Though it's module in a bit broad meaning, but Gentoo Linux
>  init provides "before/after" or "dependency" mechanism.

I mentioned the Linux boot sequence analogy earlier, although 
without reference to Gentoo, which I am not familiar with.  Basic SysV 
init scripts use sequence numbers, while LSB, if I recall correctly, 
specifies an explicit dependency notation.  Although explicitly 
declaring dependencies and ordering the calls based on that is sort of 
elegant, it is also rather complicated.

> Timo, tell me, is it wrong what I plan? It's:

Motivation for starters.  What specific problem would be solved by this?  
As a general principle what you suggest loses modularity.  Would it gain 
something in some cases?  What and where?

> ;;; But you can't read both at the same time!

If not, there is an error in one or both of the modules.  It should be 
tracked down.  Only if it turns out that there is an unavoidable 
dependency among the hook members, then means to resolve it should be 
investigated.

> (add-hook 'before-add-window-hook system-before-add-window)
> ---------------------------------------------------------------------
> --- As I wrote, this is only for core procedures. Many functions can
>  retain their own hooked functions.

Now the function system-before-add-window would depend on how you define 
core and everything that is in it. Such tangled dependency messes should 
be kept small.

If func2 knows that other functions often need to be called either 
before or after itself, it could do this:
(define (func2 w)
  (call-hook before-func2-hook (list w))
  ... do what func2 is about ...
  (call-hook after-func2-hook (list w)))

Stuff that does not care about func2 could still go to before-add-
window-hook.  Stuff that cares could go into one of the new hooks.
Of course if every hook member did this, there would be an insane number 
of new hooks.

-- 
	Timo Korvola		<URL:http://www.iki.fi/tkorvola>