Re: [dwm] snapping bugs with multiple screens

On Mon, May 05, 2008 at 02:12:10PM +0200, Matthias-Christian Ott wrote:
> "Anselm R. Garbe" <arg_AT_suckless.org> wrote:
> > I can confirm your observation and it took quite a while that
> > someone reported it. I expected it much earlier ;)
> >
> > The snap-algorithm uses wx, wy, ww, and wh as screen dimension
> > boundaries. There is no support for multiple screens in the snap
> > algorithm, so it is only intended to work correctly in a single
> > screen setup or at least at wx and ww in multi screen setups.
> >
> > As a workaround I propose to disable snapping in multihead
> > setups through setting it to 0.
> >
> > Proper snap-support would make dwm dependend from XrandR or
> > Xinerama and I don't want to do that (or alternatively of yet
> > another complex geometrie setup at compile time).
>
> Is there a particular reason for this? I mean it would be the proper

Simplicity. I'd rather remove snapping instead of supporting
XrandR/Xinerama natively if that helps.

> naturally/intuitively expected behaviour, so adding a dependency (which
> is of course bad from a suckless perspective) gives you a lot of
> benefits (including simpler GEOM setups).
> Let's do a poll!

Well, I kind of agree the reconsideration of DEFGEOM. For my
personal needs I need DEFGEOM however. But maybe it should be
simplier. It feels to fine-grain. I believe reducing it to bar
position and window area should be fine. master and tile areas
belong to the Layout, maybe those values should be extracted to
the Layout definition.

> > I see some potential to make SNAP a variable however, which
> > could be set in DEFGEOMs for this reason.
>
> Seems unreasonable. Why should you throw away information that is
> provided by extensions which have to be present anyhow (in order to use
> multiple monitors)?

Right, I propose to get rid of snapping at all. Does anyone uses
snapping at all?

Kind regards,

-- 
 Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361