Re: Hot-Spots 1.0.3

[Christopher Roy Bratusek <zanghar freenet de>]

Am Tue, 19 Oct 2010 15:19:38 +0900 (JST)
schrieb Teika Kazura <teika lavabit com>:

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