Hi, [email protected] (2009-05-02 at 1312.01 +0200): [...] > And we have four suspended patches, is there any interrest in them? > 1) 13 mouse buttons
IIRC this one was suspended because it was a complex thing that depended in others. Keep as suspended. > 2) After raise/lower-window hooks > ... seems not to be usefull The main reason seems to be tabs, so keep as suspended, tabs recode should address the issues. > 3) Focus policy improvement > ... sounds ok, Teika: didn't we introduce remprop in 1.3x? So any change > for this to be in 1.5.0? No comment, Teika and Timo seem to be the one more knoweldge in all the quirks. > 4) Shade-focus > ... don't get this. temporarily unshading windows is what shade-hover > already does. The idea behind this one is that unshaded happens for focus not on enter events, so it should work with keys or when the mouse goes to root window and focus mode is enter-only. Teika comment about hooks seems to suggest a simpler way to do it, which works (partialy?), just add (add-hook 'focus-in-hook shade-hover-enter) and remove the call in leave-notify-hook, and probably enter-notify-hook (keep focus-out-hook). So maybe the patch should aim at different hooks, depending on desired behaviour. Or maybe consider the hover was a bit buggy and this is the way to be. ;] I said partially because I am trying to locate some corner cases, enter-notify-hook gives issues about keybindings making mouse not unshade without moving the cursor over other windows first (makes sense, the focus has not changed) or leaving unshaded windows around when moving the cursor (so it toggles the status like keybinding), depends if removed or not. OTOH, I think it even works better in other cases: menus and dropdowns keep the window unshaded (long standing issue, it shaded when you changed menus). To sum up, for now I am trying with: ,in sawfish.wm.ext.shade-hover (add-hook 'focus-in-hook shade-hover-enter) (remove-hook 'enter-notify-hook shade-hover-enter) (remove-hook 'leave-notify-hook shade-hover-leave) GSR
