Am Tue, 19 Oct 2010 15:19:38 +0900 (JST) schrieb Teika Kazura <[email protected]>:
> > HS (Hot Spots) interaction with ID and EF (Infinite Desktop/Edge Flip): > > interaction is possible. > > [weeks later] > > (edge-actions '( ( top-right . hot-spot ) > > ( left . edge-flip ) > > ( bottom . infinite-desktop ) ) ) > > Aha, limiting ID to horiz / vert, and HS to the rest is ingenious. HS is not limited, but ID and EF are. Besides it's a) only a small portion of the edge and b) that portion is configurable and can be set to a minimum of 5 (which is practically nothing). > My impression was that having ID in all 4 directions together with HS > will be a frustration, but I haven't tried it. (Actually I can't test > how it feels exactly, since I don't rely on ID nor EF. A temporary > tester can barely help for this kind of thing.) I'm using HS + EF and it I like what I have ;) The optimal behavior is: HS active: not call EF or ID at hot-spot HS inactive: call EF or ID at hot-spot Currently there are two timers, therefore EF and HS work together. First HS and then EF or ID is called. But: how useful is that? That means that each time you hit the corners to activate EF or ID, you first activate HS. > > HS and ID are move to sawfish.wm.edge and the EF is moved to > > sawfish.wm.edge.flip. Stuff like restart & such should be moved to > > C. > > Right. It'll also help to rename C to wm.edge.subrs. (See wm.windows.) wm.edge.subrs sounds great. > > leave the flipper window as is. > > Just ideas: One possible extension is to make flippers have there own > keymaps. It seems possible, by promoting the edge-flip detector > windows. I don't know how difficult it will be. (Weeks ago Janek said > he have his theme indented 1 pixel so maximized windows leave borders > to the background. He can easily invoke the root menu, by hitting the > screen edge and clicking.) > We shouldn't assume all now, but to enable per-flipper keymaps, > flippers may have to be split. And if 4 / 8 flippers have differnt > role, then it's good to make them visible, and more width, more than 1 > pixel. more than 1 px is a bad idea, as the edges will then be inside maximized windows. Imagine this: edge-width 5 px + warp-pointer set to 0 . 0 of window = each time warp-pointer is called you'll also activate the edge. So I'm against increasing the width of the edges. Also making them visible is odd if you ask me. Making 8 of them is not optimal: Scenario A: 4 long edges, 4 l-shaped edges. The l-edges must be above the long ones, else their effect is lost, at the same time the parts of the long edges underneath the l-edges doesn't have any effect, as those aren't hit. Scenario B: 4 edges, leave corner-detection to get-active-corner function. Both behave exactly the same, so I don't see advantages in splitting edges, except for different keymaps, but how useful is it, to have 8 keymaps for the edges? I mean top-left-corner-keymap, top-right-corner-keymap (...) bottom-edge-keymap? That's way too much and unflexible. Instead users should get edge-keymap and rely on get-active-corner and (the not yet, but easily written) get-active-edge helpers, to fully customize the keymap. That way users have one keymap and two helper functions which make it a lot easier and more flexible for both users and developers. > With best regards, > Teika (Teika kazura) Kind Regards, Chris
