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
