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

Reply via email to