Re: Project idea on "Big one hook"


No one does not know the sure answers to below questions, and that's
the very problem:

On Wed, 30 Sep 2009 00:56:03 +0300, Timo Korvola wrote:
> On Tuesday 29 September 2009 10:35:02 Teika Kazura wrote:
>> I myself have experienced similar at least three times, both in focus
>> and stacking. Isn't it a problem or what? :)
> Is it a problem that could be solved by having more control over the 
> order in which members of a hook are invoked? 

On Tue, 29 Sep 2009 14:25:38 -0500, Jeremy Hankins wrote:
> Yes, I seem to recall having trouble amid all the window-adding/mapping
> hooks at one point myself [...]
> Unfortunately, I don't really understand the process either.[...]
> But I don't know that the complication is due to unnecessary
> complication of the sawfish code.  It may just be complicated.
> [...]
> Looking at the thread it's not clear to me whether [failure of
> calling warp-pointer-if-necessary in focus-in-hook] 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.

I don't stick to "big one hook", but something has to be done. If the
example I cited is impossible, then it should be clear to users. "Hey,
hook is there in Sawfish, use it."-but-doesn't-work-situation is what
we've got.  This is what I mean by the following:

>> 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.

And I'd like a tutorial which describes what happens in typical events.
Those who don't know the difference between window addition and mapping
must be many. But I can't write one, due to my limited knowledge.

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? Hooked functions have to
know all other members, and there're no way to guarantee the order.

> Why was [add-window-hook] deprecated?

My guess is: at the beginning, only add-window-hook was there. But JSH
noticed it's not enough, and made before- and after-. But before- was
the same as add-, so he deprecated it.

In emacs, I often don't know when the hook is exactly called, after
reading the doc. So I try one, and if it works, "it's ok after
all". But this situation where "by chance" is required can't be called
a specification. It is a lack of acceptable design.

It's human-made.

> A lot of code still uses [add-window-hook].

Two possibilities:
1: Order problem is there, and functions in add- have to wait for the
   completion of funcs in before-.
2: JSH didn't have time.

>> It's unsound that no one knows exactly what happens internally,
>> especially when a window is added and mapped.
> I think that is the sound situation.  It allows for more modular code.  
> A module neither knows nor cares what other modules do in the same 
> hooks.  The hook mechanism is such a great idea that it has been 
> reinvented time and again: Boost and Qt have signals, Java has 
> observers.

Not really. Librep's module and hook seem simple and/thus primitive to
me.  Though it's module in a bit broad meaning, but Gentoo Linux init
provides "before/after" or "dependency" mechanism. For example, net
mount is optional, of course. And if it is enabled, it is assured that
it's done after net init.

I don't know much about hook, but my impression on hook is that it's
mainly for extensions, so aggregation of core things does not seem
far-fetched to me.

Timo, tell me, is it wrong what I plan? It's:
;; currently
;;; in module 1
(add-hook 'before-add-window-hook func1) 
;;; in module 2
(add-hook 'before-add-window-hook func2)
;;; But you can't read both at the same time!
;; new
(define (system-before-add-window w)
  ;; First prepare xxx
  (func1) ;; call module1 func
  ;; yyy is zzz
  ;; others don't depend on the order
  ... )

(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. 

.. anyway no one can embark on it soon. I even don't know if it's
possible. It's a discussion for better future.

Thanks a lot,
Teika (Teika kazura)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]