On Mon, May 05, 2008 at 02:12:10PM +0200, Matthias-Christian Ott wrote: > "Anselm R. Garbe" <[EMAIL PROTECTED]> 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
