[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [STUMP] improvements of floating-group
From: |
Ben Spencer |
Subject: |
Re: [STUMP] improvements of floating-group |
Date: |
Sun, 13 Mar 2011 10:30:04 +0000 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Fri, Mar 11, 2011 at 04:23:57PM +0100, Manuel Giraud wrote:
> Ben Spencer <address@hidden> writes:
> > I agree that having click-to-focus by default in float groups makes
> > sense, but it seems non-intuitive to do this when *mouse-focus-policy*
> > is :ignore. Perhaps we should allowing configuring the focus policy
> > on a per-group-type basis, and default it to :click for float groups.
>
> I have used (unless :sloppy) instead of (when :click) because :ignore is
> the default mouse focus policy and the click policy is a good default
> for floating-group. Regarding *mouse-focus-policy* on per-group-type
> basis, that'd be cool but is the per-group-type machinery already here
> or someone have to implement it ?
Somebody would have to implement it. I've been trying to think of an
elegant way to do so, but the best I've come up with is something like this:
(defgeneric group-get-setting (group name))
(defmethod group-get-setting (group (name symbol))
(declare (ignore group))
(symbol-value name))
(defmacro defgroup-setting (type name value)
`(defmethod group-get-setting ((group ,type) (name (eql ',name))) ,value))
Then stumpwm code would get settings like this:
(group-get-setting group '*mouse-focus-policy*)
And the user could override them on a per-group-type basis like this:
(defgroup-setting float-group *mouse-focus-policy* :click)
This all seems a bit clunky though and I'm thinking maybe it would be
easier just to have two separate variables in the cases where we need
it.
> Don't know. I initially removed it to remove those ugly hardcoded values
> but adding more knob to stumpwm is not IMO the way to go. (in fact,
> maybe we should stick to hardcoded colors here)
I think removing the hardcoded colours is definitely the way forward.
I don't really see the problem with adding more options myself: even
if 'no more themes' is a selling point of stumpwm I think 'extreme
customisability' is a more important one.
Ben