Why not just keep it simple and store a seltags[] for each monitor and a single variable indicating which is the current monitor selected?
This way you can achieve any of the possibilities (show the same client in both monitors, move a window from one to another, etc.. For me this approach looks the simpler one and fits all my needs. which situations are not handled by this approach? On Sun, 9 Dec 2007 23:10:14 +0100 Antoni Grzymala <[EMAIL PROTECTED]> wrote: > Anselm R. Garbe dixit (2007-12-09, 18:27): > > [snip] > > > > One idea I was playing in my mind with for a while was assigning some of > > > the tags to the other display and move between the displays seamlessly > > > as if moving between the tags -> I guess I'll still have the problem of > > > not being able to move the programs between other-display-tags but it'd > > > look more natural and I won't have to invoke switchscreen separately. > > > > > > For my taste, treating different displays as different tag sets is a > > > better solution than defining a very large display where one tag spreads > > > over both of the screens. But of course the ability to move program > > > windows between the displays is quite handy, too. > > > > One problem with using a subset of your tags for a different > > screen occures, if a window is tagged with a tag from one screen > > and with another tag from a different screen. We cannot display > > a window on two screens, at least not mirrored (Xinerama allows > > to display portions of windows on different screens however) ;) > > I think this discussion is going in the right direction. My suggestion > to marry those two contradicting views would be like this: > > - in normal circumstances two heads act like two separate dwm instances > (the way I guess most people are doing now), you can jump between them > the usual way (ie. sh -c 'DISPLAY=:0.1 swarp 512 384'); > > - both heads have their own freely settable sets of tags (like two > separate dwm instances); > > - add another property to a client (called head, for example), > signifying which head a client should appear on (mutually exclusive, > so that we don't try do display a client on both heads; > > - allow changing the "head" property for a client with a keyboard-bound > function while preserving other attributes of the client (tagset, > float/non-float); > > Do you think this makes sense? > > Regards, > > -- > [a] > --pancake