Re: [dwm] We need a different Xinerama implementation
I'm using xmonad now, because hg tip isn't usable with Xinerama yet. And their model is what i wanted, except window swapping
Re: [dwm] We need a different Xinerama implementation
+1 On 2/21/08, hiro [EMAIL PROTECTED] wrote: I'm using xmonad now, because hg tip isn't usable with Xinerama yet. And their model is what i wanted, except window swapping
Re: [dwm] We need a different Xinerama implementation
On Thu, 21 Feb 2008 14:06, hiro wrote: I'm using xmonad now, because hg tip isn't usable with Xinerama yet. And their model is what i wanted, except window swapping There's a contrib module that emulates dwm window swapping behaviour: http://hackage.haskell.org/packages/archive/xmonad-contrib/0.6/doc/html/XMonad-Actions-DwmPromote.html Regards, -- Ricardo Martins * scarybox.net * GPG key: 0x1308F1B4 pgpiWEBsIvDIX.pgp Description: PGP signature
Re: [dwm] We need a different Xinerama implementation
On Thu, Feb 21, 2008 at 02:06:34PM -0500, hiro wrote: I'm using xmonad now, because hg tip isn't usable with Xinerama yet. And their model is what i wanted, except window swapping Yea hg tip is still experimental, but there are a lot of efforts during the last days, that I expect a preview for Sunday. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] We need a different Xinerama implementation
On 2/15/08, Ralph E. Carter [EMAIL PROTECTED] wrote: I'm not sure about this idea. I don't like this idea so much because it would increase complexity and decrease predictability. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Yes. I vote for simplicity and predictability. Thanks. _ Climb to the top of the charts! Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan Simplicity has become too much of a religion here. The differences are quite small, and the only really simple solution is not changing everything. You shouldn't just believe! I vote for thoughtfulness. -- hiro
Re: [dwm] We need a different Xinerama implementation
My proposal about xinerama would be: you have the same set of tags in each monitor, but you can have selected a tag only in one monitor. So, if for example you have tag 2 selected in monitor a and you select tag 2 in monitor b it will be in unselected in a. You would need the possibility of not having any selected tag for this to work. The obious problem: what if a window has more than one tag and it is selected in two monitors? I think you could just put it in the first monitor. I don't have 2 monitors now, but when I did one of them was the main one and the other some sort of secondary screen, so this would have sense, but I'm not sure all you are using xinerama this same way. Anyway, I don't have a strong opinion about this, I would need a second monitor to test my ideas. A proposal: what if you release some sort of 4.8 and we implement different xinerama approachs and after some testing you decide which one is better? I'm glad to see some movement in dwm again. Greets, -- - yiyus || JGL .
Re: [dwm] We need a different Xinerama implementation
greetings, - we could do something more interesting in the case where multiple monitors show the same tags. For example, if monitor 1 and monitor 2 both show tag 1, we might treat monitor 2 as a part of the right hand side. Divide it into two columns and effectively have a main column + three residuals layout. I haven't seen this idea in these discussions so far, and I must say I like it a whole lot. (Even though, of course, you can never be sure you have two monitors beside each other. That's just the most popular configuration.) Mate
Re: [dwm] We need a different Xinerama implementation
- we could do something more interesting in the case where multiple monitors show the same tags. For example, if monitor 1 and monitor 2 both show tag 1, we might treat monitor 2 as a part of the right hand side. Divide it into two columns and effectively have a main column + three residuals layout. I haven't seen this idea in these discussions so far, and I must say I like it a whole lot. (Even though, of course, you can never be sure you have two monitors beside each other. That's just the most popular configuration.) The approach falls down a little if monitor 1 is showing tag A and monitor 2 is showing tags A and B. What should monitor 2 look like? It would seem odd for it not to have a 'master' column. Maybe the arrangement algorithm would have to consider the entire set of windows to be viewed and the constraints for each before placing them. In the case above, how about the two stacks (i.e. residuals on 1 and 2) having an equal number of windows, with those on monitor 2 being the windows from tag B plus enough windows (possibly none) from tag A to balance with the stack on monitor 1. To be honest, most of these schemes seem overly complicated. The approach I prototyped works well for me (big surprise!), even if it has lots of loose ends to tidy up. dme.
Re: [dwm] We need a different Xinerama implementation
On Thu, Feb 14, 2008 at 01:42:26PM -0600, Kurt H Maier wrote: What is the reason tags can't have flags? :) Think of it as tagging the tags themselves. Assigning the screen 1 flag to a tag is just like assigning a net tag to a client. The difference would be that flags would be mutually exclusive; assigning a flag to a specific tag would first clear any other flags. Well I read through all responds and my favorit looks as the following: I agree on Kurts approach. Having only 1 tagset (say 1,..,9) for all screens, but have per-screen layouts and separate bars on each screen (to avoid complexity). Now one can select certain tags on any screen, but this selection will be mutiual exclusive to other screens. Which might have the result that a certain screen might not have any tags selected, hence only displaying the wallpaper and its specific bar. This concept allows to keep navigation and tagging as simple as it is atm. A question regarding xmonad, do you warp the mouse to a specific screen if a specific client is focussed by keyboard or tagging rules? Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] We need a different Xinerama implementation
2008/2/15, Anselm R. Garbe [EMAIL PROTECTED]: On Thu, Feb 14, 2008 at 01:42:26PM -0600, Kurt H Maier wrote: What is the reason tags can't have flags? :) Think of it as tagging the tags themselves. Assigning the screen 1 flag to a tag is just like assigning a net tag to a client. The difference would be that flags would be mutually exclusive; assigning a flag to a specific tag would first clear any other flags. Well I read through all responds and my favorit looks as the following: I agree on Kurts approach. Having only 1 tagset (say 1,..,9) for all screens, but have per-screen layouts and separate bars on each screen (to avoid complexity). Now one can select certain tags on any screen, but this selection will be mutiual exclusive to other screens. Which might have the result that a certain screen might not have any tags selected, hence only displaying the wallpaper and its specific bar. This concept allows to keep navigation and tagging as simple as it is atm. Well, this is more or less the same thing I was proposing (clearier explained, my mails before mid day are a mess), but you still have the same problem: what if a client is tagged with tags in more than one monitor? I reckon you will need a compromise here, but maybe there is a good solution I haven't thought about. I have also thought that you should take a different approach with floating clients. You should be able to move it wherever, don't matter in which monitor its tag it is. This could be confusing... Have a nice weekend, -- - yiyus || JGL .
Re: [dwm] We need a different Xinerama implementation
On Fri, Feb 15, 2008 at 01:24:05PM +0100, y i y u s wrote: 2008/2/15, Anselm R. Garbe [EMAIL PROTECTED]: On Thu, Feb 14, 2008 at 01:42:26PM -0600, Kurt H Maier wrote: What is the reason tags can't have flags? :) Think of it as tagging the tags themselves. Assigning the screen 1 flag to a tag is just like assigning a net tag to a client. The difference would be that flags would be mutually exclusive; assigning a flag to a specific tag would first clear any other flags. Well I read through all responds and my favorit looks as the following: I agree on Kurts approach. Having only 1 tagset (say 1,..,9) for all screens, but have per-screen layouts and separate bars on each screen (to avoid complexity). Now one can select certain tags on any screen, but this selection will be mutiual exclusive to other screens. Which might have the result that a certain screen might not have any tags selected, hence only displaying the wallpaper and its specific bar. This concept allows to keep navigation and tagging as simple as it is atm. Well, this is more or less the same thing I was proposing (clearier explained, my mails before mid day are a mess), but you still have the same problem: what if a client is tagged with tags in more than one monitor? I think during all tag-related operations conflicting tags need to be removed with the preference of the currently active screen. Which means during view() or toggleview() conflicting tags of clients are dropped with the preference of the screen acquiring the specific tag (e.g. say on screen 2 one views 2, while screen 1 has acquired tag 1 and there is a client being tagged 1+2 -- hence it will loose tag 1). During tag() or toggletag() the same mechanism applies, but with the preference of the screen of the new tag instead -- which might move a window to a different screen and drop conflicting tags. I reckon you will need a compromise here, but maybe there is a good solution I haven't thought about. I have also thought that you should take a different approach with floating clients. You should be able to move it wherever, don't matter in which monitor its tag it is. This could be confusing... I consider implicit tagging of floating clients based on their center point after a mouse-based move/resize operation. That's the only sane solution I can come up with. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] We need a different Xinerama implementation
On Fri, Feb 15, 2008 at 10:31:30AM +0100, Nagy Mate wrote: greetings, - we could do something more interesting in the case where multiple monitors show the same tags. For example, if monitor 1 and monitor 2 both show tag 1, we might treat monitor 2 as a part of the right hand side. Divide it into two columns and effectively have a main column + three residuals layout. I haven't seen this idea in these discussions so far, and I must say I like it a whole lot. (Even though, of course, you can never be sure you have two monitors beside each other. That's just the most popular configuration.) I'm not sure about this idea. I don't like this idea so much because it would increase complexity and decrease predictability. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] We need a different Xinerama implementation
I have been using dwm with an external monitor for a while, just as is...using only the external monitor losing the screen resolution on my laptop screen. These days im rather busy and can take much care about dwm, but I hope to have some time to test all the xinerama changes in dwm 4.8. I have some ideas really closer to the ones exposed by you and yiyus, but I don't want to think on it until i have something to test and check how i feel with it. btw, maybe i'll have to check the repository instead of waiting for the release :) On Fri, 15 Feb 2008 09:21:18 +0100 y i y u s [EMAIL PROTECTED] wrote: My proposal about xinerama would be: you have the same set of tags in each monitor, but you can have selected a tag only in one monitor. So, if for example you have tag 2 selected in monitor a and you select tag 2 in monitor b it will be in unselected in a. You would need the possibility of not having any selected tag for this to work. The obious problem: what if a window has more than one tag and it is selected in two monitors? I think you could just put it in the first monitor. I don't have 2 monitors now, but when I did one of them was the main one and the other some sort of secondary screen, so this would have sense, but I'm not sure all you are using xinerama this same way. Anyway, I don't have a strong opinion about this, I would need a second monitor to test my ideas. A proposal: what if you release some sort of 4.8 and we implement different xinerama approachs and after some testing you decide which one is better? I'm glad to see some movement in dwm again. Greets, -- - yiyus || JGL . --pancake
Re: [dwm] We need a different Xinerama implementation
I'm not sure about this idea. I don't like this idea so much because it would increase complexity and decrease predictability. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Yes. I vote for simplicity and predictability. Thanks. _ Climb to the top of the charts! Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
Re: [dwm] We need a different Xinerama implementation
What is the reason tags can't have flags? :) Think of it as tagging the tags themselves. Assigning the screen 1 flag to a tag is just like assigning a net tag to a client. The difference would be that flags would be mutually exclusive; assigning a flag to a specific tag would first clear any other flags. -- # Kurt H Maier
Re: [dwm] We need a different Xinerama implementation
arg: I agree that the current approach has flaws and I'd like to address them before dwm-4.8. Actually I'd like to hear your opinions first to what you think might be the best solution of supporting multihead setups? I more and more come to the conclusion that classical multihead support is not worth the effort anymore. The DISPLAY= variable should do the trick for those setups (meaning running separate instances of dwm for each screen) -- but Xinerama provides much more possibilities so that I see a different use case here. I consider different tagsets for each screen, which can't be selected in a join way, to prevent the basic problem of being unable to display the same window on different screens. Maybe somewhat into the direction of having a 2D tagset, with y addressing different screens (yiyus or pancake came up with this idea if I remember correctly) for the Xinerama case, and y addressing different virtual screens for the non Xinerama case. Hence, say tags 1-4 address screen 1, tags 5-9 address screen 2 or so, but tagging a client 1+5 is not possible. This should give you a rough idea. Please let me know what you think. This is essentially the approach we chose for xmonad. No union of window sets, and display one set per physical screen. You can then index phsyical screens, and window sets separately We use mod-w,e,r to select a physical screen as current. Then mod-1..9 to load a window set onto that physical screen. If the set is visible on another physical screen already, you either switch the current screen, or swap window sets. -- Don
[dwm] We need a different Xinerama implementation
I agree that the current approach has flaws and I'd like to address them before dwm-4.8. Actually I'd like to hear your opinions first to what you think might be the best solution of supporting multihead setups? I more and more come to the conclusion that classical multihead support is not worth the effort anymore. The DISPLAY= variable should do the trick for those setups (meaning running separate instances of dwm for each screen) -- but Xinerama provides much more possibilities so that I see a different use case here. I consider different tagsets for each screen, which can't be selected in a join way, to prevent the basic problem of being unable to display the same window on different screens. Maybe somewhat into the direction of having a 2D tagset, with y addressing different screens (yiyus or pancake came up with this idea if I remember correctly) for the Xinerama case, and y addressing different virtual screens for the non Xinerama case. Hence, say tags 1-4 address screen 1, tags 5-9 address screen 2 or so, but tagging a client 1+5 is not possible. This should give you a rough idea. Please let me know what you think. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] We need a different Xinerama implementation
I consider different tagsets for each screen, which can't be selected in a join way, to prevent the basic problem of being unable to display the same window on different screens. It doesn't really fix that problem, but limits the user to make it seem more logically. And specially if one of your monitor is bigger than the other, you sometimes want to move your clients between them. Maybe somewhat into the direction of having a 2D tagset, with y addressing different screens (yiyus or pancake came up with this idea if I remember correctly) for the Xinerama case, and y addressing different virtual screens for the non Xinerama case. This visualization makes things more complicated than they are. It definitely doesn't fit with numbered tags. Hence, say tags 1-4 address screen 1, tags 5-9 address screen 2 or so, but tagging a client 1+5 is not possible. This should give you a rough idea. This solves problems of the current approach, but i.e. not being able to tag a client 1+5 will bring other confusion instead. Moreover, how will that work with 3 screens? I remembered, that a lot of you use the keyboard only. Your version would make it easier to change focus to an other monitor, whereas with david's patch you would either have to use the mouse, or bind a special key for that.
Re: [dwm] We need a different Xinerama implementation
On Thu, Feb 14, 2008 at 7:14 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: I more and more come to the conclusion that classical multihead support is not worth the effort anymore. The DISPLAY= variable should do the trick for those setups (meaning running separate instances of dwm for each screen) -- but Xinerama provides much more possibilities so that I see a different use case here. I've no interest in classic multihead (today!). Are there many reasons why having a single window manager for multiple DISPLAYs is compelling? I consider different tagsets for each screen, which can't be selected in a join way, to prevent the basic problem of being unable to display the same window on different screens. A couple of things occur to me about this: Maybe somewhat into the direction of having a 2D tagset, with y addressing different screens (yiyus or pancake came up with this idea if I remember correctly) for the Xinerama case, and y addressing different virtual screens for the non Xinerama case. Hence, say tags 1-4 address screen 1, tags 5-9 address screen 2 or so, but tagging a client 1+5 is not possible. This should give you a rough idea. Please let me know what you think. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] We need a different Xinerama implementation
(Sigh, send before finished, sorry) On Fri, Feb 15, 2008 at 6:44 AM, David Edmondson [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 7:14 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: I more and more come to the conclusion that classical multihead support is not worth the effort anymore. The DISPLAY= variable should do the trick for those setups (meaning running separate instances of dwm for each screen) -- but Xinerama provides much more possibilities so that I see a different use case here. I've no interest in classic multihead (today!). Are there many reasons why having a single window manager for multiple DISPLAYs is compelling? I consider different tagsets for each screen, which can't be selected in a join way, to prevent the basic problem of being unable to display the same window on different screens. A couple of things occur to me about this: - whether it is a problem depends on how people expect to use their system. I my case I find the distinct tagsets per monitor very confusing (tested with awesome - not tried dwm tip yet). I tend to remember which applications have a particular tag, so it's easy to make those applications come 'here' (to the monitor I'm looking at) easily. The 'partitioned' tagset (1-4 on monitor 1, 5-8 on monitor 2) would make this more difficult, particularly if I decide that I'd like to see tagsets 1 and 3 side by side. - we could do something more interesting in the case where multiple monitors show the same tags. For example, if monitor 1 and monitor 2 both show tag 1, we might treat monitor 2 as a part of the right hand side. Divide it into two columns and effectively have a main column + three residuals layout. dme.
Re: [dwm] We need a different Xinerama implementation
On Fri Feb 15, 2008 at 06:44:56AM +, David Edmondson wrote:
On Thu, Feb 14, 2008 at 7:14 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote:
I more and more come to the conclusion that classical multihead
support is not worth the effort anymore. The DISPLAY= variable
should do the trick for those setups (meaning running separate
instances of dwm for each screen) -- but Xinerama provides much
more possibilities so that I see a different use case here.
I've no interest in classic multihead (today!). Are there many reasons
why having a single window manager for multiple DISPLAYs is
compelling?
im going to vote a big 'why bother' as well. been using a dwm per DISPLAY for a
long time without any problem
{ MODKEY, XK_q,spawn, exec xwarppointer screen + }, \
switches fast and easy..
