2008/12/11 Mate Nagy <[EMAIL PROTECTED]>: > 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 .