Re: [dwm] dwm and dualhead

On Thu, Dec 11, 2008 at 09:52:45AM +0000, Anselm R Garbe wrote:
> - have a dwm environment on each Xinerama screen (like multiple dwm's
> in classic multihead setups) as suggested by Mate
> -> the problem was, it didn't felt right because it added another
> navigation layer on top of dwm, to basically navigate through screens
> and to move clients between screens, the conclusion was, if you really
> want this, run multiple instances of dwm with a classic multihead
> setup
 I use all my systems like this, where I can. The point is, that you
often *can't* do this any more, because bad driver support; also, not
being able to move windows between screens sucks sometimes.
 I would still prefer this solution.
 The "extra navigation layer" means "next screen key" and "move client
to next screen key"... not all that much. I would hazard that a majority
of multi-monitor users still use two monitors (laptop + external
monitor).
> - make layout algorithms use more screens (keep the bar at a specific
> "main screen")
> -> the problem was, that it doesn't scale well, most layout
> algorithms aren't designed for multihead setups, esp. if the screens
> have different geometries
 I don't see how this would be usable.. also, depending on automatic
tiling, clients jumping between screens would be a very confusing. The
previous approach keeps clients on the same screen until explicit wish
from the user.
 IMHO considering multi-monitor layout algorithms is just muddying
the issue and is not worth doing in practice.
> - split the tags into n distinct tagsets (1 for each screen) and use
> the existing tagging concept for focussing/moving clients between
> different screens using tagging, display the status bar on the screen
> with the focussed client (or some arbitrary fallback if there are no
> clients)
> -> I think that was my favorit approach, so the main drawback was
> that it made dwm significantly more complex and that there needs to be
> some kind of setup option which tells which tag belongs to which
> screen, so the intermediate approach was having a tag struct with a
> screen index -> but hell taht sucked
 I see this as basically the same as the first approach, differing only
in implementation details. I personally think just moving out all those
cute global variables into a screen struct, and passing a pointer
around, would be much more correct and elegant than hacking the tags.
 This solution also breaks when you assign a client to multiple screens.
> - use the screen with the pointer as default screen where the bar is
> presented and the layout algorithms happen, use all other screens for
> floating clients
> -> this is the current approach
 Again personally, I really really don't like this :) It seems that if
we're stuck to using floating windows, then using a conventional window
manager with good xrandr support is more comfortable (my fallback
recently was the xfce wm for this - it was decent).
> Also, the main question remains, how many multihead users are there?
> The main argument for the last approach was, if there are only 10% of
> multihead users, why should all single head/laptop users suffer from
> the unnecessary complexity? dwm's current Xinerama support isn't worse
> than the Xinerama support in any major desktop environment, but it is
> not very smart compared to other tiling WMs.
 I would expect a lot of programmers use multihead.. and dwm isn't
precisely for the lowest common denominator user, is it.

Mate
Received on Thu Dec 11 2008 - 10:09:55 UTC