Hi, thanks Jeremy and Timo. Glad two savants are interested. 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. 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. I myself have experienced similar at least three times, both in focus and stacking. Isn't it a problem or what? :) It's true that evaluation of the hook gives hints. Actually it's the only way. But it requires each user, each time they'd like a hack. Then you plunge into the sea of git-grep / ack. For layman like me, it's quite a workload, and sometimes I fail to read off the program intention. It hinders Sawfish progress. And don't assume anyone knows ack. (Until GSR (?) told in this mailing list, I've been using for i in `find...` ; do str=`grep... Headaches. ;) It's unsound that no one knows exactly what happens internally, especially when a window is added and mapped. Doc (notes) may suffice. Easiest way to maintain is to attach inline comments into the code, though. (Separate docs are often left untouched after enhancements in codes.) Yet, its anticipated difficulty discourages me. Doc is easier, but at least one is desired. Let me add some points. 1. It is better if hooks provide an easy way to hack, not requiring rewritement of the core code as far as possible. Anyway, user should be able to understand which is needed. Currently not. 2. On order in add-hook. My words were curt. I mean, you can't tell if it should come earlier or later if you don't understand what's exactly hooked in, is it? > And order isn't supposed to matter in a hook; It should be so, but many are thrown into hooks. So I guess it does matter. (For example, it must be likely that someone wants to override matcher's action. Then it must be done *after* matcher.) And it may be inevitable. If you move the poiter in a hook, it can send some events, resulting in another call hook, erasing previous effect. (I don't understand X, so not sure.) > Personally, I like hooks. Hooks make the code much more extensible > by the end user, and ideally more modular as well. I can add to a > hook in the module that needs that hook, so if the module isn't > loaded that code never gets run. Or I could add a hook in my > .sawfishrc file if it's just a quick hack. I don't deny use of hooks by core codes, especially for optional features, like tab or infinite-desktop. What I want is to glue all-time hooked in (= "main") functions together. But we can reduce to make things transparent. 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. On Sun, 27 Sep 2009 14:35:20 +0300, Timo Korvola wrote: > On Saturday 26 September 2009 07:38:24 Teika Kazura wrote: >> Currently, each module independently puts their functions on hooks. >> So, it is quite obscure both for users and developers what is >> processed, e.g., when a window is mapped. > > This is unavoidable in modular code, where different modules will need > to react to the same events. It's true for modules which provide optional functionalities, but not for mandatory codes? > Does Rep have a function that would return the structure (module) where > a given closure is defined? I don't know most of you don't know. ;) 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. > Some of this may indicate bugs that should be fixed. I was about to ask if someone knows the mechanism :) It's not good, but in fact JS Harper seems to have known it. I guess that's why in lisp/sawfish/wm.jl, intern-structure is used before open-structure. What's `intern-structure'? Let me quote from require() in librep/src/structures.c: ------------------------------------------------------------------------ /* Need to do all this locally, since the file providing the feature/module has to be loaded into the _current_ structure (in case it contains bare code). %intern-structure OTOH always loads into *root-structure*, since it's often called with only the %meta structure imported */ ------------------------------------------------------------------------ I don't understand. Maybe Timo does. Regards, Teika (Teika kazura)
