Hi there again, well I cleaned up Christof's initial multihead implementation a lot, and I played around with experimental tag sharing between different views (I decided to call a Xinerama screen view, which allows aiming Xinerama on a single head as well and which is more precise in the dwm terminology, so far we only had 1 view, with each Xinerama screen we get an additional view).
But unfortunately I more and more come to the conclusion that allowing to assign a certain tag to a specific view at runtime sucks. It is not very predictable at all when tags are dropped in clients and how (the heuristic I told about the last time does not really work well -- and this heuristic even has to be used after the rules are applied, because there might be some rule which assigns tags used by different views). I can imagine that this concept works quite well in xmonad, because there the limitation of selecting one tag/workspace per view (screen) seems to be design decision. Also what I dislike about the mutex tag sharing is, that we still need additional functions to select a certain screen (besides the fact, that all those quirks necessary to resolve tag selection conflicts clutter the code a lot). But I don't want to follow the workspace paradigm, because I think the way dwm treats multiple tags being viewed is really a nice feature and makes it unique to all other clones and related projects. So I'm back at the point I was already last week (but with a much cleaner codebase now). I propose again to go the way with partitioned tag sets, which allows to get rid of explicit screen selection functions and which avoids the tag selection joins between partitions - the tag partition setup will be done in config.h. So, tag() can move a client to a different screen (if the chosen tag is in a different partition), view() can focus a different screen (if the related tag is in a different partition). toggletag() and toggleview() only work in the currently valid partition (related on the focused client resp. view) and will not allow any conflicts. applyrules() needs special treatment as well. But it's all a question of the right data structure. I will decide tonight/tomorrow which data structures fit best this idea. Kind regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
