Re: [dwm] Xinerama support
Stefan Maerkl wrote: Christian Garbs <[EMAIL PROTECTED]> schrieb am 12.01.2008 um 00:36: The "inactive" head gets a static, perhaps greyed out version of the window in question. The "active" head has the real window with focus, input and output. When you move your mouse to the "inactive" window or select it otherwise, the inactive and active windows get swapped. Yes, that's more or less what I was thinking about. Might be better than windows appearing and disappearing when switching to the other head. Note that with my original proposal, windows appeared and disappeared only when one toggled the visibility of tags. Kai
Re: [dwm] Xinerama support
Christian Garbs <[EMAIL PROTECTED]> schrieb am 12.01.2008 um 00:36: > On Fri, Jan 11, 2008 at 05:27:09PM +0100, Sander van Dijk wrote: > > On Jan 11, 2008 5:16 PM, Stefan Maerkl <[EMAIL PROTECTED]> wrote: > > > On the second head, one could display just an empty window labelled > > > "On head 1". Maybe in a special colour or so. > > > > You're joking, right?... Right? > > Hmm, perhaps not :-) > > What about focus-following-mouse. > > The "inactive" head gets a static, perhaps greyed out version of the > window in question. The "active" head has the real window with focus, > input and output. > When you move your mouse to the "inactive" window or select it > otherwise, the inactive and active windows get swapped. > > So there would be an additional, static client window. > Hmm, perhaps not very clever when "active" and "inactive" have > different sizes. But perhaps worth a try. Might be interesting. Yes, that's more or less what I was thinking about. Might be better than windows appearing and disappearing when switching to the other head. ciao Stefan -- Dipl.-Ing. Stefan Märkl | [EMAIL PROTECTED] Institute of Microelectronic Systems | http://www.ims.uni-hannover.de Phone: +49-(0)-511-762-19657 | Fax: +49-(0)-511-762-19694 pgp6OZtXYPHhI.pgp Description: PGP signature
Re: [dwm] Xinerama support
On Fri, Jan 11, 2008 at 05:27:09PM +0100, Sander van Dijk wrote: > On Jan 11, 2008 5:16 PM, Stefan Maerkl <[EMAIL PROTECTED]> wrote: > > On the second head, one could display just an empty window labelled > > "On head 1". Maybe in a special colour or so. > > You're joking, right?... Right? Hmm, perhaps not :-) What about focus-following-mouse. The "inactive" head gets a static, perhaps greyed out version of the window in question. The "active" head has the real window with focus, input and output. When you move your mouse to the "inactive" window or select it otherwise, the inactive and active windows get swapped. So there would be an additional, static client window. Hmm, perhaps not very clever when "active" and "inactive" have different sizes. But perhaps worth a try. Might be interesting. Regards, Christian, who doesn't even have Xinerama -- Christian.Garbs.http://www.cgarbs.de Das Militaer ist eine Pflanze, die man sorgfaelltig pflegen muss, damit sie keine Fruechte traegt. -- Jaques Tati (1907-1982) signature.asc Description: Digital signature
Re: [dwm] Xinerama support
On Jan 11, 2008 5:16 PM, Stefan Maerkl <[EMAIL PROTECTED]> wrote: > On the second head, one could display just an empty window labelled > "On head 1". Maybe in a special colour or so. You're joking, right?... Right?
Re: [dwm] Xinerama support
Antoni Grzymala <[EMAIL PROTECTED]> schrieb am 11.01.2008 um 17:07: > pancake dixit (2008-01-11, 15:36): > > > maybe someone who is showing a window to another ppl on a external > > monitor or projector not visible by the one who is working on the "local" > > monitor. > > This has been discussed on the list previously. X does not allow to > display a window on both heads. Otherwise, yes, it could be fun. On the second head, one could display just an empty window labelled "On head 1". Maybe in a special colour or so. -- Dipl.-Ing. Stefan Märkl | [EMAIL PROTECTED] Institute of Microelectronic Systems | http://www.ims.uni-hannover.de Phone: +49-(0)-511-762-19657 | Fax: +49-(0)-511-762-19694 pgpxjD5v6kruW.pgp Description: PGP signature
Re: [dwm] Xinerama support
pancake dixit (2008-01-11, 15:36): > maybe someone who is showing a window to another ppl on a external > monitor or projector not visible by the one who is working on the "local" > monitor. This has been discussed on the list previously. X does not allow to display a window on both heads. Otherwise, yes, it could be fun. Best, -- [a] signature.asc Description: Podpis cyfrowy :: Digital signature
Re: [dwm] Xinerama support
On Fri, 11 Jan 2008 15:01:53 +0100 Kai Grossjohann <[EMAIL PROTECTED]> wrote: > Anselm R. Garbe wrote: > > 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) ;) > IMHO this is a non-problem. If the tags say that a window should be > visible on more than one head, then just display it on one of those > heads and omit it on the others. Who needs to see the same window twice? maybe someone who is showing a window to another ppl on a external monitor or projector not visible by the one who is working on the "local" monitor. But imho this is perfectly 'fixed' with the tagging concept. > Of course, that opens the question of which head to choose, but I > believe that a very simplistic approach of assigning a global order to > the heads would suffice. Make that order configurable. imho the order should be done in the same way of the zooming windows. > There is only one situation where I imagine that the user might be > surprised: Say the left head displays tags l1 and l2, and the right head > displays r1 and r2. And the window has tags l1 and r1. Say that the > left head is preferred. > > So the window is displayed on the left head. Suppose the user then > removes the tag l1 from the left head. This means that the window will > jump to the right head. This jumping of windows might be surprising. I would prefer to have an initial version to play with and get what's interesting and what's not. --pancake
Re: [dwm] Xinerama support
Anselm R. Garbe wrote: 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) ;) IMHO this is a non-problem. If the tags say that a window should be visible on more than one head, then just display it on one of those heads and omit it on the others. Who needs to see the same window twice? Of course, that opens the question of which head to choose, but I believe that a very simplistic approach of assigning a global order to the heads would suffice. Make that order configurable. There is only one situation where I imagine that the user might be surprised: Say the left head displays tags l1 and l2, and the right head displays r1 and r2. And the window has tags l1 and r1. Say that the left head is preferred. So the window is displayed on the left head. Suppose the user then removes the tag l1 from the left head. This means that the window will jump to the right head. This jumping of windows might be surprising. But I do not consider this a major hindrance. Kai
Re: [dwm] Xinerama support
Chris Webb dixit (2007-12-11, 13:11): > > This way you can achieve any of the possibilities (show the same client in > > both > > monitors, move a window from one to another, etc.. > > X doesn't give you a mechanism for showing the same client on both monitors. Ah, that solves my dilemma. I thought so, too. -- [a] signature.asc Description: Podpis cyfrowy :: Digital signature
Re: [dwm] Xinerama support
pancake dixit (2007-12-11, 14:08): > 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.. Does Xinerama (and X in general) support displaying the same client on multiple heads? Intuitively this could lead to a number of input handling problems, but maybe I'm wrong. > For me this approach looks the simpler one and fits all my needs. which > situations > are not handled by this approach? I think this is actually more complicated than what I wrote previously (as quoted below) as in my case you have two dwm's and a "display" or "head" variable for each client. My idea assumes that a client cannot be displayed on many heads. > > - 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); -- [a] signature.asc Description: Podpis cyfrowy :: Digital signature
Re: [dwm] Xinerama support
pancake <[EMAIL PROTECTED]> writes: > This way you can achieve any of the possibilities (show the same client in > both > monitors, move a window from one to another, etc.. X doesn't give you a mechanism for showing the same client on both monitors. Best wishes, Chris.
Re: [dwm] Xinerama support
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
Re: [dwm] Xinerama support
> - aim multihead setup (distinct bars, tag sets and layouts for > each screen) I think I like this idea, but can you explain how the tags will interact between the screens? it seems possible to tag a window to appear on both screens. the need for distinct layouts per head is a must i think, to be able to accommodate everyone. I think one interesting and useful function might be the ability to swap all the windows and tags between the physical heads, while retaining layout. this way I can swap in the things on my secondary screen if i need to address them for a short time, and then push them back to the second head afterwards. -Andrew
Re: [dwm] Xinerama support
On Dec 10, 2007 4:11 AM, Chris 'Ducky' Chapin <[EMAIL PROTECTED]> wrote: > > This is sort of what I've done. I run dwm at work with a 2 head xinerama > setup, so added a side attribute to the client struct and added a > function to toggle it. Then I just copied and adjusted the tile function > to display 2 mains and 2 stacks mirrored. This what a coworker has > dubbed the dumbbell layout: "[]==[]". =) > > -Ducky > I don't have a multi-head setup but I have used some at work. I think most of the time I had a notion of a primary screen and a secondary screen. Given that, I think it will be useful to designate one screen as the master screen displaying only master windows (with adjustable number of columns, I think a default of two is good) and the other screen as a stack screen with a multiple columns (I think three will be a good default). The rest remains the same except probably, restricting windows not to extend to the other screen automatically. Ritesh > Maarten Maathuis wrote: > > A shared tagging setup, but a flag to indicate primary or secondary > head. > > Sort of like adding an extra dimension to dwm. > > > > Maarten. > > > > On 12/9/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > > > >> Hi there, > >> > >> could you imagine that there is a way that dwm could be used in > >> a Xinerama environment and how that might look like? > >> Regardless if that is necessary or not for mainstream dwm, > >> I see the following possibilities: > >> > >> - aim multihead setup (distinct bars, tag sets and layouts for > >> each screen) > >> > >> - extend tile() into tile2() and tile3(), where tile2 assumes > >> one screen as master area (with the bar), and one screen as > >> stacking area (note, setmwfact won't have any effect here), and > >> tile3() would do similiar, but the third screen would be > >> stacking area as well. > >> > >> Are there other ideas? > >> > >> Regards, > >> -- > >> Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361 > >> > >> > >> > >
Re: [dwm] Xinerama support
Anselm R. Garbe dixit (2007-12-10, 10:18): > > 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? > > Yes, Christof Musik currently works on something like that. We > specified a good multihead concept during last weekend and I > believe you will like it! Cool! I currently have only one monitor (the one in my laptop), but I'm planning to buy an external one when I have some spare funds. Regards, -- [a] signature.asc Description: Podpis cyfrowy :: Digital signature
Re: [dwm] Xinerama support
On Sun, Dec 09, 2007 at 11:10:14PM +0100, Antoni Grzymala 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? Yes, Christof Musik currently works on something like that. We specified a good multihead concept during last weekend and I believe you will like it! Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Xinerama support
This is sort of what I've done. I run dwm at work with a 2 head xinerama setup, so added a side attribute to the client struct and added a function to toggle it. Then I just copied and adjusted the tile function to display 2 mains and 2 stacks mirrored. This what a coworker has dubbed the dumbbell layout: "[]==[]". =) -Ducky Maarten Maathuis wrote: A shared tagging setup, but a flag to indicate primary or secondary head. Sort of like adding an extra dimension to dwm. Maarten. On 12/9/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: Hi there, could you imagine that there is a way that dwm could be used in a Xinerama environment and how that might look like? Regardless if that is necessary or not for mainstream dwm, I see the following possibilities: - aim multihead setup (distinct bars, tag sets and layouts for each screen) - extend tile() into tile2() and tile3(), where tile2 assumes one screen as master area (with the bar), and one screen as stacking area (note, setmwfact won't have any effect here), and tile3() would do similiar, but the third screen would be stacking area as well. Are there other ideas? Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Xinerama support
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] signature.asc Description: Podpis cyfrowy :: Digital signature
Re: [dwm] Xinerama support
Seems like this would call for an alternative layout to be #included, which allows for the large-resolution screen-spanning desktop, and it could just emulate multihead by tiling / maximizing windows to those sections of the desktop which are displayed on each screen. These boundaries could be defined in config.h, and this mode could then be toggled on and off as you connect or disconnect the external monitor. I guess it would also require a two-dimensional tag set -- or else we go back to specific tags being assigned to specific boundaries. -- # Kurt H Maier
Re: [dwm] Xinerama support
On Sun, Dec 09, 2007 at 02:12:48PM +0100, Engin Tola wrote: > pancake <[EMAIL PROTECTED]> writes: > > > Recently I buyed a 20" 16:10 tft, and i really feel interesting to have > > xinerama with dwm. Thinking about that I got the idea that we should just > > store two variables: > > > > - selected tag for each monitor (static array?) > > - focused monitor index > > > > This way we can add some functions over these concepts to switch focus > > between monitors. > > > > This would be really nice if you're going to use an external monitor or > > a "projector" to give a talk, you can have different contents on each > > monitor and work "out" of the view for the public. > > > > What do you think about this behaviour? > > > > --pancake > > I work with 2 monitors at work and for this purpose I launch 2 dwm > instances one for each display. I also use switchscreen* utility to move > between the displays. One problem I have -as you can guess - is that I > cannot move a program launched in one display to the other one. > > 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) ;) So I only see the possibility to aim multihead. Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Xinerama support
pancake <[EMAIL PROTECTED]> writes: > Recently I buyed a 20" 16:10 tft, and i really feel interesting to have > xinerama with dwm. Thinking about that I got the idea that we should just > store two variables: > > - selected tag for each monitor (static array?) > - focused monitor index > > This way we can add some functions over these concepts to switch focus > between monitors. > > This would be really nice if you're going to use an external monitor or > a "projector" to give a talk, you can have different contents on each > monitor and work "out" of the view for the public. > > What do you think about this behaviour? > > --pancake I work with 2 monitors at work and for this purpose I launch 2 dwm instances one for each display. I also use switchscreen* utility to move between the displays. One problem I have -as you can guess - is that I cannot move a program launched in one display to the other one. 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. So, I agree with you pancake. having different contents on screens is really nice for presentations and like. * http://users.tkk.fi/~spniskan/switchscreen/ [snip] -- engin tola - http://cvlab.epfl.ch/~tola emacs - http://www.gnu.org/software/emacs/tour
Re: [dwm] Xinerama support
Recently I buyed a 20" 16:10 tft, and i really feel interesting to have xinerama with dwm. Thinking about that I got the idea that we should just store two variables: - selected tag for each monitor (static array?) - focused monitor index This way we can add some functions over these concepts to switch focus between monitors. This would be really nice if you're going to use an external monitor or a "projector" to give a talk, you can have different contents on each monitor and work "out" of the view for the public. What do you think about this behaviour? --pancake On Sun, 9 Dec 2007 13:20:04 +0100 "Maarten Maathuis" <[EMAIL PROTECTED]> wrote: > Rotating heads would also be desirable, so you can move task sets > around your screens (to the primary one for example). > > Maarten. > > On 12/9/07, Maarten Maathuis <[EMAIL PROTECTED]> wrote: > > Two bars, each containing the applications on that head. > > > > Personally i've been using per-tag layouts, so i kind of assumed that > > as well for this situation. > > > > Think it of as combining two dwm instances in a smart way, so workflow > > can be shifted from one head to the other. > > > > Maarten. > > > > On 12/9/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > > > On Sun, Dec 09, 2007 at 12:59:21PM +0100, Maarten Maathuis wrote: > > > > A shared tagging setup, but a flag to indicate primary or secondary > > > > head. > > > > Sort of like adding an extra dimension to dwm. > > > > > > That sounds like a simple solution, but still very similiar to > > > aiming the multihead setup. But how to combine that with > > > the bar and layout setup? A layout per screen, or a global > > > layout? A bar on the first screen only or a global bar? > > > > > > Regards, > > > -- > > > Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361 > > > > > > > > > --pancake
Re: [dwm] Xinerama support
Rotating heads would also be desirable, so you can move task sets around your screens (to the primary one for example). Maarten. On 12/9/07, Maarten Maathuis <[EMAIL PROTECTED]> wrote: > Two bars, each containing the applications on that head. > > Personally i've been using per-tag layouts, so i kind of assumed that > as well for this situation. > > Think it of as combining two dwm instances in a smart way, so workflow > can be shifted from one head to the other. > > Maarten. > > On 12/9/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > > On Sun, Dec 09, 2007 at 12:59:21PM +0100, Maarten Maathuis wrote: > > > A shared tagging setup, but a flag to indicate primary or secondary head. > > > Sort of like adding an extra dimension to dwm. > > > > That sounds like a simple solution, but still very similiar to > > aiming the multihead setup. But how to combine that with > > the bar and layout setup? A layout per screen, or a global > > layout? A bar on the first screen only or a global bar? > > > > Regards, > > -- > > Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361 > > > > >
Re: [dwm] Xinerama support
On Dec 9, 2007 11:54 AM, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > could you imagine that there is a way that dwm could be used in > a Xinerama environment and how that might look like? [A collective groan goes around as people realise I'm still around :-) ] Yes and http://www.personal.rdg.ac.uk/~sis05dst/desktop.jpg Seriously though, I think a better way to pose the question is: if you had a xinerama setup, what applications would you want simultaneously open and do their needed shapes affect how you'd like to interact with them. Personally, I tend to use mostly editor windows which are good in a narrow-tall shape so increasing the number of columns works for me, and sometimes sets of terminals, gnuplot windows and images which again work in grid mode. I also tend to just have related windows under a tag, so having multiple tag sets or bars doesn't really add anything for me. Narrow columns are bad for web browsers or ps/pdf doc's I find. [FWIW, I still intend to post some new patches when I get time to (i) update to modern dwm (I'm off a modified 4.3 still) and (ii) I figure up how my wmii-style stack-mode modification has screwed up the focussing code. Unfortunately I've been very busy recently.] -- cheers, dave tweed__ [EMAIL PROTECTED] Rm 124, School of Systems Engineering, University of Reading. "we had no idea that when we added templates we were adding a Turing- complete compile-time language." -- C++ standardisation committee
Re: [dwm] Xinerama support
Two bars, each containing the applications on that head. Personally i've been using per-tag layouts, so i kind of assumed that as well for this situation. Think it of as combining two dwm instances in a smart way, so workflow can be shifted from one head to the other. Maarten. On 12/9/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > On Sun, Dec 09, 2007 at 12:59:21PM +0100, Maarten Maathuis wrote: > > A shared tagging setup, but a flag to indicate primary or secondary head. > > Sort of like adding an extra dimension to dwm. > > That sounds like a simple solution, but still very similiar to > aiming the multihead setup. But how to combine that with > the bar and layout setup? A layout per screen, or a global > layout? A bar on the first screen only or a global bar? > > Regards, > -- > Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361 > >
Re: [dwm] Xinerama support
On Sun, Dec 09, 2007 at 12:59:21PM +0100, Maarten Maathuis wrote: > A shared tagging setup, but a flag to indicate primary or secondary head. > Sort of like adding an extra dimension to dwm. That sounds like a simple solution, but still very similiar to aiming the multihead setup. But how to combine that with the bar and layout setup? A layout per screen, or a global layout? A bar on the first screen only or a global bar? Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Xinerama support
On Sun, Dec 09, 2007 at 12:54:00PM +0100, Anselm R. Garbe wrote: > could you imagine that there is a way that dwm could be used in > a Xinerama environment and how that might look like? > Regardless if that is necessary or not for mainstream dwm, > I see the following possibilities: > > - aim multihead setup (distinct bars, tag sets and layouts for > each screen) > > - extend tile() into tile2() and tile3(), where tile2 assumes > one screen as master area (with the bar), and one screen as > stacking area (note, setmwfact won't have any effect here), and > tile3() would do similiar, but the third screen would be > stacking area as well. > > Are there other ideas? I got another idea. Assumed, that the column layout of wmii would have a revival in dwm, then one could define the number of columns per screen as a Xinerama scenario instead. Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Xinerama support
A shared tagging setup, but a flag to indicate primary or secondary head. Sort of like adding an extra dimension to dwm. Maarten. On 12/9/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > Hi there, > > could you imagine that there is a way that dwm could be used in > a Xinerama environment and how that might look like? > Regardless if that is necessary or not for mainstream dwm, > I see the following possibilities: > > - aim multihead setup (distinct bars, tag sets and layouts for > each screen) > > - extend tile() into tile2() and tile3(), where tile2 assumes > one screen as master area (with the bar), and one screen as > stacking area (note, setmwfact won't have any effect here), and > tile3() would do similiar, but the third screen would be > stacking area as well. > > Are there other ideas? > > Regards, > -- > Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361 > >