Re: [IMPORTANT] EdgeActions ready (+ setup guide)

[Christopher Roy Bratusek <zanghar freenet de>]

Am Samstag 20 November 2010, 05:00:31 schrieb Teika Kazura:
> On Sat, 13 Nov 2010 12:33:29 -0600, Jeremy Hankins wrote:
> > I prefer using the keyboard for navigating and triggering actions,
> > so I don't think I'm a good person to have an opinion
> 
> Me, too. Don't take my impression in this mail too strongly.  (It
> applies to themes, too. I invoke window operation menu with keys. ;)
> 
> On Sat, 13 Nov 2010 19:32:10 +0100, Christopher Roy Bratusek wrote:
> > EdgeActions is now considered stable and ready for testing
> 
> Great work!! (Now you agree it should be in 1.8, rather than 3.0. :)
> 
> > Q: How to set it up?
> > A: Everything except the hot-spots actions can be setup via
> > SawfishConfig.
> 
> Currently, (require 'edge-actions) is necessary. Let's load it by default,
> by adding edge-actions to `intern-structure' in wm.jl.

Done.

> There's a serious one-liner bug. In actions.jl, ":after-set (lambda ()
> edges-activate))", the last element has to be in parentheses.

Oops ;)

> > Also all 4 edges are now separated,
> 
> I realized that it makes sense to have only 2 in the configurator,
> top-bottom and left-right. (Names horiz / vert can be confusing. The
> top edge is used for vert move, but its shape looks horizontal!)

... at first I wanted to say that it might produce problems, but now I came to 
the conclusion, it won't. The assumption you made is correct; you either use 
EF or VD on the opposting site. If you use HS, it doesn't matter, as those are 
nil by default.

> > Actions for when hitting the edge with the pointer and when hitting
> > while moving a window are now SPLIT. So you can have separated
> > behavior or the same for both cases, just as you like.
> 
> I think it's better to combine, but it can be changed later.
> Merge to the master will be soon, so let's see how users feel.

I personally think it's pretty 1337 (I had to use that) to perform different 
actions for when moving. Of course in the default setup it will be the same.

Current default is „do nothing“. Any suggestions for other defaults, or should 
it stay like that? Would equal to former defaults, there EF was disabled.

> I don't think `edge-actions-enabled' is necessary. (It servers only to
> disable all edge actions, but does anyone want it?) Instead, after
> setting any of *-edge-func, call edges-activate, and it must suffice.

Removed. Now 4 times none (instead of 8) is necessary to disable.

Also I don't think it' a good idea to recreate flippers each time the option is 
changed (useless waste of cpu cycles). Instead sawfish.wm.user does activate 
them now once. For resolution changes we are already hooked-in.

To disable the flippers (and thus the edges) you would do (edges-activate nil).

> It's for the first time that I heard of layouted workspaces. Vertical
> workspace flipping is only useful for it. Is it still possible to set
> it by GNOME or so? If it's still necessary, then we have to write its
> documentation, too, because from Sawfish, you can't set it in ICCCM /
> EWMH compliant way. (You can mock it from Sawfish. But pager prints
> workspaces linearly. See wm/ext/workspace-grid. )

Well I have 2 . 2 workspaces. Check pager-workspace-per-column. Though it's 
not 100% working: right-flip on firsth WS moves to fourth instead of third WS:

* = window

1* | 3 ==> 1 | 3
2  | 4 ==> 2 | 4*

> On the delay: In VD, delay is bad. (Even 50 is clumsy.) In
> edge-flip, I feel 250 ms is good. I felt no delay was a bit abrupt. To
> cancel hot-spot, at least .75 sec or so is necessary, I guess. (I
> haven't tried HS yet.)

Hmm. Yes, delay for HS was a bit long. and missing for corners.

Now it is:
- VD: no delay
- EF: full delay
- HS: half delay

> It's better to listen to others first, but my image of the solution is:

I doubt there will be much 'others'. So again it's our points of view. ;)

> no delay for VD. Since HS has to be set via lisp, make it accept a
> delay option for each HS. Not sure for flipping.

It's not a good idea to make the delay for each HS different (possibly).

> That's all I've tried so far.
> 
> > Q: How to test?
> > A: git branch test # create new branch "test" from master
> > 
> >     git checkout test # switch to it
> >     git merge edge-actions # ... you need to resolve the conflicts
> >     (sorry)
> 
> Conflicts are there in joe.jl and windows.jl. I first thought that it
> could be fixed by rebasing, but it's probably bad to rebase a public
> branch. Merge is safe.
>
> Todos in edges:
> * Doc
Of course

> * Rename src/flippers to src/edge.
... I doubt that. flippers != edges. What we do in C is handling the flippers, 
edges are handled in LISP. I know it might be confusing, but current names are 
technically correct.

> * Relegate some functions in C to lisp, so that it can be used for
>   multi-head dead-zone problem, too. Currently C functions are
>   not exported from lisp modules, so it can be after the release,
>   but it's better to combine API changes in one release.
adding them as SUBRS isn't enough? Or do you plan on more work?

> * Add old options to compat.jl, so that you don't have to edit
>   ~/.sawfish/custom manually.
The editing thing is no longer needed, as all current options have new names.
a defvar-setq on edge-flip-enabled which doesn't exist anymore should be ok.

Only function calls in private code might stop working.

> Teika (Teika kazura)
Chris