[wmii] Re: some things worth to look at before 3.1

From: Anselm R. Garbe <garbeam_AT_wmii.de>
Date: Mon, 29 May 2006 09:31:21 +0200

On Sun, May 28, 2006 at 07:52:16PM +0000, Sander van Dijk wrote:
> Here are some things that I think should be looked at before 3.1:
>
> - should wmii do bordersnap when moving resizing on the managed layer?
> On the floating layer, bordersnap is very useful, but on the managed
> layer this is arguable...

ACK

> - new column creation with the mouse: right now, this is done by
> moving clients > 50% offscreen; however, all other mousebased
> 'targets' are related to pointer position, so it might be better to do
> column creation based on pointer position too (new leftcol if
> pointer->x is 0, and new rightcol if pointer->x is screenwidth). This
> would improve consistency I think.

ACK, should be pointer based, will also fix those annoyances of
two floating areas pro view (see the BUGS file).

> - separate namespaces for taglabels and user-defined labels in the
> bar? This is simply necessary in -4 (because of the possibility to
> have empty views, a click on the statuslabel will create view status,
> which is undesirable), but also welcome in wmii-3.1. Using a tag
> 'status' results in (from the user's POV) strange behavior right now
> (I just pushed and removed again a workaround for the problem that
> makes the situation slightly less crappy, see irclog for details; if
> wmii-3.1 is not going to have separate namespaces for taglabels and
> user-defined labels, I still think that this hack is better than the
> current situation).

No, for wmii-3.1 we don't make a change into this direction.

> - it seems that OLD_PATH and the 'extern' action have to be restored;
> without them, there is no way to guarantee that no collisons occur: if
> wmii's action dirs are appended to the path, scripts/binaries on the
> system can interfere with wmii actions (in -3, problems will occur if
> there is a /bin/wmiirc or /bin/status for instance); if wmii's action
> dirs are prepended to the path, actions might interfere with
> scripts/binaries on the system.
> I think that the OLD_PATH var is the only safe way to make sure that
> the right thing will get executed in the right place. (the 'extern'
> action is not strictly necessary of course, but if OLD_PATH has to
> come back, it might be good to bring the env cleaner back too...)

Yes, to keep the namespace clean OLD_PATH seems a good idea.
Anyway, the extern action is not necessary.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361
Received on Mon May 29 2006 - 09:31:22 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:07:08 UTC