Re: [dwm] dwm and dualhead

2008/12/11 Mate Nagy <mnagy_AT_port70.net>:
> Hiho,
> On Thu, Dec 11, 2008 at 09:39:19AM +0100, yy wrote:
>> on this list and, if somebody finds a great _general_ solution (which
>> seems difficult, but I would be love to be wrong), I'm sure Anselm
>> would be glad to include it in the official release.
>> Just my 2cts,
> I don't see anything "difficult" about this. In fact, awesome generally
> gets this right. This is what I want from dwm:
>
> - handle each xrandr screen separately
> including all data structures, so different layout, client set,
> tagging, etc.

You could have a tile algorithm for two screens, where you have the
zoomed client in one of them and the stack in the other screen
arranged in a grid layout, for example; or something similar to tile
in one screen and two more columns of stack on the other one, the
possibilities are endless. And if you want to completely change your
whole "workspace" with tagging having to set tags in both screens
would be a pain.

> - draw statusbar everywhere (from the same input text)

I don't understand why you would want the same status text in two
adjacent screens.

> - have a key-bindable function for:
> - changing between screens

just warp the pointer to the client.

> - move window to another screen

which could simply be done by having different tags in both screens,
something like 1.1 1.2 2.1 2.2 etc.

> - do something semi-intelligent when a screen with clients goes away,
> e.g. put clients in previous/next screen oslt.
>
> Basically, it should behave as multiple separate dwms, except that
> clients can be sent from screen to screen and all dwms have the same
> configuration.
>

This is an use-case, but I don't see it like a general approach.
Having said this, I don't think it would be difficult to implement, as
far as I can remember dwm did something similar at some point and it
wasn't satisfactory to everybody, but it can definitively be done and,
if everybody (using dual-head, my opinion doesn't count) agrees this
is the perfect behavior, it should be included in main, IMO.

-- 
- yiyus || JGL .