[dwm] Xinerama

From: Anselm R. Garbe <arg_AT_suckless.org>
Date: Tue, 26 Feb 2008 22:59:58 +0100

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
Received on Tue Feb 26 2008 - 22:59:58 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 15:21:44 UTC