Re: [dwm] visibility of focused windows
On Tue, Mar 04, 2008 at 05:11:02PM +0100, Anselm R. Garbe wrote: On Tue, Mar 04, 2008 at 04:44:34PM +0100, Joerg van den Hoff wrote: On Tue, Mar 04, 2008 at 05:51:30PM +0300, Alexander Polakov wrote: * Joerg van den Hoff [EMAIL PROTECTED] [080304 17:21]: question 1: should not the focused window be always brought to the foreground irrespective of whether it is currently maximized or not? it's even more irrating when you already have a few maximized windows and then open another one: the new window again will never be visible if you cycle the focus with mod1-j as long as it is not maximized first. Just use monocle layout for that. thanks for this hint. I'll have a look at that. question remains, whether, if the current behaviour is seen as not desirable, it can't be fixed in the main branch of `dwm', instead. monocle will be in mainstream dwm tonight. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 thanks a lot! this works nicely. question: why is `togglemax' gone? it sure is useful (despite 'monocle') in the standard tiling layout for maximizing/restoring a single window in turn. joerg
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 12:54:33PM +0100, Joerg van den Hoff wrote: On Tue, Mar 04, 2008 at 05:11:02PM +0100, Anselm R. Garbe wrote: On Tue, Mar 04, 2008 at 04:44:34PM +0100, Joerg van den Hoff wrote: On Tue, Mar 04, 2008 at 05:51:30PM +0300, Alexander Polakov wrote: * Joerg van den Hoff [EMAIL PROTECTED] [080304 17:21]: question 1: should not the focused window be always brought to the foreground irrespective of whether it is currently maximized or not? it's even more irrating when you already have a few maximized windows and then open another one: the new window again will never be visible if you cycle the focus with mod1-j as long as it is not maximized first. Just use monocle layout for that. thanks for this hint. I'll have a look at that. question remains, whether, if the current behaviour is seen as not desirable, it can't be fixed in the main branch of `dwm', instead. monocle will be in mainstream dwm tonight. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 thanks a lot! this works nicely. question: why is `togglemax' gone? it sure is useful (despite 'monocle') in the standard tiling layout for maximizing/restoring a single window in turn. Well, I propose using setlayout([M]) and setlayout([]=) instead. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 01:21:14PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 12:54:33PM +0100, Joerg van den Hoff wrote: On Tue, Mar 04, 2008 at 05:11:02PM +0100, Anselm R. Garbe wrote: On Tue, Mar 04, 2008 at 04:44:34PM +0100, Joerg van den Hoff wrote: On Tue, Mar 04, 2008 at 05:51:30PM +0300, Alexander Polakov wrote: * Joerg van den Hoff [EMAIL PROTECTED] [080304 17:21]: question 1: should not the focused window be always brought to the foreground irrespective of whether it is currently maximized or not? it's even more irrating when you already have a few maximized windows and then open another one: the new window again will never be visible if you cycle the focus with mod1-j as long as it is not maximized first. Just use monocle layout for that. thanks for this hint. I'll have a look at that. question remains, whether, if the current behaviour is seen as not desirable, it can't be fixed in the main branch of `dwm', instead. monocle will be in mainstream dwm tonight. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 thanks a lot! this works nicely. question: why is `togglemax' gone? it sure is useful (despite 'monocle') in the standard tiling layout for maximizing/restoring a single window in turn. Well, I propose using setlayout([M]) and setlayout([]=) instead. yes, I discovered this already (and without pestering the list...). it sure helps do avoid the cycling through all three layouts. but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). I know you are approaching the self-imposed 2000 loc limit, but maybe this can be relaxed a bit? :-). best regards, joerg Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] visibility of focused windows
On 3/5/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). can you please describe a common scenario when the two is different? (eg if you only want a quick maximize+revert then it can be achieved by toggling layout between monocle and tile)
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 01:47:16PM +0100, Szabolcs Nagy wrote: On 3/5/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). can you please describe a common scenario when the two is different? (eg if you only want a quick maximize+revert then it can be achieved by toggling layout between monocle and tile) Another possibility is, use some tag as max tag, e.g. 5, then toggletag(tags[4]) and do view(tags[4]) for a temporarily maximised window, viewprev() can be used now as togglemax()-replacement. The decision to remove togglemax is related to the fact, that there should only be one way to achieve a certain functionality. And togglemax is a special case of using tagging in a powerful way. I see your point that monocle does not solve the issue at all. Btw. I plan to introduce 3 additional key bindings: Mod1-f (Apply floating layout) Mod1-m (Apply monocle layout) Mod1-t (Apply tiled layout) Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 02:18:25PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 01:47:16PM +0100, Szabolcs Nagy wrote: On 3/5/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). can you please describe a common scenario when the two is different? (eg if you only want a quick maximize+revert then it can be achieved by toggling layout between monocle and tile) Another possibility is, use some tag as max tag, e.g. 5, then toggletag(tags[4]) and do view(tags[4]) for a temporarily maximised window, viewprev() can be used now as togglemax()-replacement. The decision to remove togglemax is related to the fact, that there should only be one way to achieve a certain functionality. And togglemax is a special case of using tagging in a powerful way. I see your point that monocle does not solve the issue at all. Btw. I plan to introduce 3 additional key bindings: Mod1-f (Apply floating layout) Mod1-m (Apply monocle layout) Mod1-t (Apply tiled layout) Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Not sure if this is desired or not, but in monocle layout, I can have two windows open, and if I open a window floating, the focus of the underlying monocle window is shifted to the other window. Bug? Or feature? -- Jeremy O'Brien aka neutral_insomniac GPG key: 0xB1140FDB http://pohl.ececs.uc.edu/~jeremy/jeremy.asc Linux lucifer 2.6.24-ARCH #1 SMP PREEMPT i686 Intel(R) Pentium(R) M processor 1400MHz pgp0pTqXCfMqp.pgp Description: PGP signature
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 02:18:25PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 01:47:16PM +0100, Szabolcs Nagy wrote: On 3/5/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). can you please describe a common scenario when the two is different? (eg if you only want a quick maximize+revert then it can be achieved by toggling layout between monocle and tile) Another possibility is, use some tag as max tag, e.g. 5, then toggletag(tags[4]) and do view(tags[4]) for a temporarily maximised window, viewprev() can be used now as togglemax()-replacement. The decision to remove togglemax is related to the fact, that there should only be one way to achieve a certain functionality. And togglemax is a special case of using tagging in a powerful way. yes, I see that this could be a work-around. but still it complicates things. maybe you think this over again? I see your point that monocle does not solve the issue at all. Btw. I plan to introduce 3 additional key bindings: Mod1-f (Apply floating layout) Mod1-m (Apply monocle layout) Mod1-t (Apply tiled layout) very good. did'nt dare to ask for this and was prepared (with clenched teeth) to patch this into config.h myself :-). and without reiterating my complaints about not having a config file: what do you think could be a user-friendly and minimal invasive strategy to add certain patches to the core of `dwm' without getting completely locked to a specific version (or being forced to continually recreate the patches for every release)? e.g., some helpful soul showed me how to implement cycling through tags. since prototypes _and_ definition of the corresponding function(s) are deep inside dwm.c, migration to the upcoming 4.8 means manual intervention again (and again and again...). could not this simple-minded strategy help: insert (once and forever) #include dwm_addons.h below the standard prototypes in dwm.c into `dwm.c' and provide and (initially empty) file dwm_addons.h. and further insert #include dwm_addons.c (again provided as empty file initially) immediately before `int main(...' (or modify the Makefile to always link `dwm_addons.c'). and finally the same approach for config.h to define keybindings for the additional functions. of course this won't be adquate for patches which really mess with the `dwm' code, but for a certain sup-group of patches (those which actually are independent functions providing some functionality, e.g. the cycling through tags mentioned above) it would suffice. migration to a new release would then not necessitate _any_ modifications to the newly arrived `dwm.c'. is this nonsense? joerg Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] visibility of focused windows
Btw. I plan to introduce 3 additional key bindings: Mod1-f (Apply floating layout) Mod1-m (Apply monocle layout) Mod1-t (Apply tiled layout) I agree with that Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Do you have a quick solution for maximizing floating windows? Maybe the monocle layout shuold handle floating and nonfloating windows in the same way.
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 03:45:09PM +0100, Szabolcs Nagy wrote: On 3/5/08, Jeremy O'Brien [EMAIL PROTECTED] wrote: Do you have a quick solution for maximizing floating windows? an ugly solution would be a key binding for: togglefloat() monocle() togglefloat() tile() but this way you cannot restore the original size to restore the original state you should save the size before maximizing and the current client struct has no space for that if you want to implement a correct togglemax for floating windows then you have to extend the client struct (i guess floating win maximization is a rare use case among dwm users so it doesn't worth the extra attributes in client, but i can be wrong) depends. I, too, usually avoid floating layout, but sure there are situations where you want it (otherwise it would'nt be there in the first place). and _if_ you use it, it sure would be really good to have correct togglemax (including size/position restoration). and I firmly believe that layout should be a per-tag property (at least if the user decides this), not global: while using `ion3' I usually had a few tiled/tabbed workspaces and a single floating one for things like scribus, e.g.. that worked very well. but no misunderstanding: `dwm' is very good right now. joerg
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 03:45:09PM +0100, Szabolcs Nagy wrote: On 3/5/08, Jeremy O'Brien [EMAIL PROTECTED] wrote: Do you have a quick solution for maximizing floating windows? an ugly solution would be a key binding for: togglefloat() monocle() togglefloat() tile() but this way you cannot restore the original size to restore the original state you should save the size before maximizing and the current client struct has no space for that if you want to implement a correct togglemax for floating windows then you have to extend the client struct (i guess floating win maximization is a rare use case among dwm users so it doesn't worth the extra attributes in client, but i can be wrong) Well, what about a different monocle, which only maximizes the focused window, and restores the previously focused window again. With this, we could make it work on all clients. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 02:18:25PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 01:47:16PM +0100, Szabolcs Nagy wrote: On 3/5/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). can you please describe a common scenario when the two is different? (eg if you only want a quick maximize+revert then it can be achieved by toggling layout between monocle and tile) Another possibility is, use some tag as max tag, e.g. 5, then toggletag(tags[4]) and do view(tags[4]) for a temporarily maximised window, viewprev() can be used now as togglemax()-replacement. The decision to remove togglemax is related to the fact, that there should only be one way to achieve a certain functionality. And togglemax is a special case of using tagging in a powerful way. I see your point that monocle does not solve the issue at all. Btw. I plan to introduce 3 additional key bindings: Mod1-f (Apply floating layout) Mod1-m (Apply monocle layout) Mod1-t (Apply tiled layout) on second thought: could'nt `mod1-m' be made to toggle between monocle and tiling, instead (omitting `mod1-t' completly, maybe)? this would more or less emulate the old `mod1-m'. such rapid switching back and forth with one key would seem useful. joerg
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 04:37:23PM +0100, Joerg van den Hoff wrote: On Wed, Mar 05, 2008 at 02:18:25PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 01:47:16PM +0100, Szabolcs Nagy wrote: On 3/5/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). can you please describe a common scenario when the two is different? (eg if you only want a quick maximize+revert then it can be achieved by toggling layout between monocle and tile) Another possibility is, use some tag as max tag, e.g. 5, then toggletag(tags[4]) and do view(tags[4]) for a temporarily maximised window, viewprev() can be used now as togglemax()-replacement. The decision to remove togglemax is related to the fact, that there should only be one way to achieve a certain functionality. And togglemax is a special case of using tagging in a powerful way. I see your point that monocle does not solve the issue at all. Btw. I plan to introduce 3 additional key bindings: Mod1-f (Apply floating layout) Mod1-m (Apply monocle layout) Mod1-t (Apply tiled layout) on second thought: could'nt `mod1-m' be made to toggle between monocle and tiling, instead (omitting `mod1-t' completly, maybe)? this would more or less emulate the old `mod1-m'. such rapid switching back and forth with one key would seem useful. Well, I'd like to get rid of the toggling at all, just directly applying a certain layout. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] visibility of focused windows
On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: Well, I'd like to get rid of the toggling at all, just directly applying a certain layout. i always used layouts that way and it works fine (except i use mod-q mod-w mod-e ..) but it's a config.h thing..
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 05:28:50PM +0100, Szabolcs Nagy wrote: On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: Well, I'd like to get rid of the toggling at all, just directly applying a certain layout. i always used layouts that way and it works fine (except i use mod-q mod-w mod-e ..) but it's a config.h thing.. Well not at all, we can get rid of some LOC as well, if the toggling is removed. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
I think that if these changes will let you to release now, it is ok. We can see later if there is something we can get rid of. Without having a look at the current code it seems reasonable to me. So: thumbs up! -- - yiyus || JGL .
[dwm] Strange tiny window with firefox-current.
Hi guys, I already asked on IRC, but the ML may be more appropriate for the problem. This concerns very recent builds of firefox-current (3.0_pre_blabla). Since a few days it has been exhibiting very strange behaviour with dwm. I get a tiny one-pixel-wide and 19-pixels-tall omnipresent window. No matter which tags I'm viewing. It appears a few seconds after starting firefox and disappears a few seconds after quitting. Here's a shot (see the top-left corner) with relevant xwininfo: http://tkabber.tk/firefox.png Any ideas? Best, -- [a] signature.asc Description: Digital signature
Re: [dwm] Strange tiny window with firefox-current.
Antoni Grzymala dixit (2008-03-05, 19:13): Here's a shot (see the top-left corner) with relevant xwininfo: http://tkabber.tk/firefox.png http://theka.tk/firefox.png Sorry about the screwup. -- [a] signature.asc Description: Digital signature
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Wed, Mar 05, 2008 at 07:12:49PM +0100, y i y u s wrote: I think that if these changes will let you to release now, it is ok. We can see later if there is something we can get rid of. Without having a look at the current code it seems reasonable to me. So: thumbs up! I implemented the stuff already, if you want to give it a try, remove the -DWORK from CFLAGS and check it out! Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Strange tiny window with firefox-current.
Jeremy O'Brien dixit (2008-03-05, 13:27):
Off topic slightly, but could you possibly share your screenrc? I like
the layout at the bottom. :-D
Sure, I'll just post it inline:
escape ^gg
deflogin on
shell -/bin/bash
altscreen on
defscrollback 4096
nethack on
defutf8 on
bind s
caption always %{= kw} %{y}%?%-Lw%?%{w}(%{R}%n*
%t%?(%u)%?%{w})%{y}%?%+Lw%?%?%=%{w} [ %{.c}%M %d %{y}%0c:%s%{w} ]
startup_message off
Best,
--
[a]
signature.asc
Description: Digital signature
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Wed, Mar 05, 2008 at 07:12:49PM +0100, y i y u s wrote: I think that if these changes will let you to release now, it is ok. We can see later if there is something we can get rid of. Without having a look at the current code it seems reasonable to me. So: thumbs up! I implemented the stuff already, if you want to give it a try, remove the -DWORK from CFLAGS and check it out! Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Hardcoding the resolution into a window manager is not nice.
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Wed, Mar 05, 2008 at 07:34:17PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 07:12:49PM +0100, y i y u s wrote: I think that if these changes will let you to release now, it is ok. We can see later if there is something we can get rid of. Without having a look at the current code it seems reasonable to me. So: thumbs up! I implemented the stuff already, if you want to give it a try, remove the -DWORK from CFLAGS and check it out! Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Whoa. I'm assuming I should be changing some of these new values in config.h, because dwm is acting VERY weird now. :-/ -- Jeremy O'Brien aka neutral_insomniac GPG key: 0xB1140FDB http://pohl.ececs.uc.edu/~jeremy/jeremy.asc Linux lucifer 2.6.24-ARCH #1 SMP PREEMPT i686 Intel(R) Pentium(R) M processor 1400MHz pgpily4Bh7RfR.pgp Description: PGP signature
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Wed, Mar 05, 2008 at 07:50:32PM +0100, Maarten Maathuis wrote: On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Wed, Mar 05, 2008 at 07:12:49PM +0100, y i y u s wrote: I think that if these changes will let you to release now, it is ok. We can see later if there is something we can get rid of. Without having a look at the current code it seems reasonable to me. So: thumbs up! I implemented the stuff already, if you want to give it a try, remove the -DWORK from CFLAGS and check it out! Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Hardcoding the resolution into a window manager is not nice. Well, you usually hardcode the resolution in x.org as well. But you can always use sx, sy, sw, sh, bh to avoid hardcoding. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
Anselm R. Garbe dixit (2008-03-05, 20:14): And here is my setup in action (btw. my dwm has 28000 bytes as binary): http://www.suckless.org/shots/dwm-4.8-xinerama.png Not using vimperator? :) Sad to see so much space wasted for the useless firefox widgets. Best, -- [a] signature.asc Description: Digital signature
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On 3/5/08, Antoni Grzymala [EMAIL PROTECTED] wrote: Not using vimperator? :) off topic pff vimperator didn't even have any usable navigation last time i checked which makes it pretty unusable even w3m is easier to handle
Re: [dwm] [OT] vimperator
Szabolcs Nagy dixit (2008-03-05, 20:44): On 3/5/08, Antoni Grzymala [EMAIL PROTECTED] wrote: Not using vimperator? :) off topic pff vimperator didn't even have any usable navigation last time i checked Actually I'm using Opera as my main browser, but what do you mean by usable navigation? I use it vimperator occasionally with firefox and consider it an excellent piece of software :). If only firefox weren't such a bloat, I would happily start using it as my main browser. Best, -- [a] signature.asc Description: Digital signature
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Wed, Mar 05, 2008 at 07:50:32PM +0100, Maarten Maathuis wrote: On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Wed, Mar 05, 2008 at 07:12:49PM +0100, y i y u s wrote: I think that if these changes will let you to release now, it is ok. We can see later if there is something we can get rid of. Without having a look at the current code it seems reasonable to me. So: thumbs up! I implemented the stuff already, if you want to give it a try, remove the -DWORK from CFLAGS and check it out! Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Hardcoding the resolution into a window manager is not nice. Well, you usually hardcode the resolution in x.org as well. But you can always use sx, sy, sw, sh, bh to avoid hardcoding. I don't see how this could be done dynamically without querying xinerama. Display configurations are not always static and it is ugly to assume that. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] [OT] vimperator
On 3/5/08, Antoni Grzymala [EMAIL PROTECTED] wrote: I use it vimperator occasionally with firefox and consider it an excellent piece of software :). If only firefox weren't such a bloat, I would happily start using it as my main browser. iirc there is a nice feature of listing the urls of a page or listing bookmarked urls or listing tabs, but you cannot navigate this list, so navigation is left to the mouse which means no gain over plain ff.
Re: [dwm] [OT] vimperator
Szabolcs Nagy dixit (2008-03-05, 21:16): I use it vimperator occasionally with firefox and consider it an excellent piece of software :). If only firefox weren't such a bloat, I would happily start using it as my main browser. iirc there is a nice feature of listing the urls of a page or listing bookmarked urls or listing tabs, but you cannot navigate this list, so navigation is left to the mouse which means no gain over plain ff. No, obviously this would be usuless if you had to touch the mouse. If you look at the links, they have little symbols like [aa] [ab] [ac] and so on. You just *type* the symbol and the link gets opened. If you type with shift it gets opened in a new tab. Wish I had this kind of link selection in Opera. Best, -- [a] signature.asc Description: Digital signature
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Wed, Mar 5, 2008 at 8:54 PM, Maarten Maathuis [EMAIL PROTECTED] wrote: On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Wed, Mar 05, 2008 at 07:50:32PM +0100, Maarten Maathuis wrote: On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Wed, Mar 05, 2008 at 07:12:49PM +0100, y i y u s wrote: I think that if these changes will let you to release now, it is ok. We can see later if there is something we can get rid of. Without having a look at the current code it seems reasonable to me. So: thumbs up! I implemented the stuff already, if you want to give it a try, remove the -DWORK from CFLAGS and check it out! Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Hardcoding the resolution into a window manager is not nice. Well, you usually hardcode the resolution in x.org as well. But you can always use sx, sy, sw, sh, bh to avoid hardcoding. I don't see how this could be done dynamically without querying xinerama. Display configurations are not always static and it is ugly to assume that. AFAIR, with newer Xorg releases you are supposed to hardcode much less in xorg.conf than was done before Xorg 7.3/7.4 as values which can be detected are meant to be auto-configured with defaults like an LCD's native resolution.
Re: [dwm] [OT] vimperator
The web is full of visual bloat. That's why your web browser must be compatible, thus be bloat, too. Vimperator is no big win. If you want a better web, provide mountable interfaces to the important services... And regarding firefox: I tried to print ten pages from firefox yesterday. It slowly grew to 200mb in ram, and used all the cpu power, before i killed it and instantly installed opera. Congratulations to firefox and all those oss fine arts suckers.
Re: [dwm] [OT] vimperator
hiro dixit (2008-03-05, 17:02): And regarding firefox: I tried to print ten pages from firefox yesterday. It slowly grew to 200mb in ram, and used all the cpu power, before i killed it and instantly installed opera. Congratulations to firefox and all those oss fine arts suckers. I totally agree, unfortunately. I'd just like to have Opera with the frontend interface of vimperator. Which doesn't seem likely :). Best, -- [a] signature.asc Description: Digital signature
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Wed, Mar 05, 2008 at 08:06:11PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 07:50:32PM +0100, Maarten Maathuis wrote: On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Wed, Mar 05, 2008 at 07:12:49PM +0100, y i y u s wrote: I think that if these changes will let you to release now, it is ok. We can see later if there is something we can get rid of. Without having a look at the current code it seems reasonable to me. So: thumbs up! I implemented the stuff already, if you want to give it a try, remove the -DWORK from CFLAGS and check it out! Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Hardcoding the resolution into a window manager is not nice. Well, you usually hardcode the resolution in x.org as well. But you can always use sx, sy, sw, sh, bh to avoid hardcoding. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Alright, I'm using your latest hg tip, and I'm just trying to get the old bar/tiling layout back... I changed the bar width alright, and I changed TY to be sy + bh, but when I change TH to be sh - bh, it won't tile windows in the tile area, and I can't figure out how to fix it. How should I be doing it? -- Jeremy O'Brien aka neutral_insomniac GPG key: 0xB1140FDB http://pohl.ececs.uc.edu/~jeremy/jeremy.asc Linux lucifer 2.6.24-ARCH #1 SMP PREEMPT i686 Intel(R) Pentium(R) M processor 1400MHz pgpYZcF5kRHgZ.pgp Description: PGP signature
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Wed, Mar 5, 2008 at 12:38 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: First of all I want to get rid of setmwfact, MWFACT and mwfact, because I'd like to supply a saner way to setup the bar more freely. Actually I consider the following values in config.h (instead of BarPos): -- /* bar position */ #define BX sx #define BY sy #define BW sw #define BH bh /* master area */ #define MX sx #define MY sy + bh #define MW ((int)(((float)sw) * 0.6)) #define MH sh - bh /* tile area, might be on a different screen */ #define TX sx + MW #define TY MY #define TW sw - MW #define BH MH /* monocle area, might be restricted to a specific screen */ #define MOX sx #define MOY MY #define MOW sw #define MOH MH -- The flexibility is definitely good, however, it clutters the config.h with a lot of dwm internals, may be unnecessarily. Worse of all, it may still not be flexible enough for another person to modify it for a Xinerama layout of his own. I still think it will be a good decision to not give Xinerama first class status in dwm. IMHO dwm should enable just enough abstraction (I suggest tile()/drawbar() delegates in layout[]) so that Xinerama layouts can be developed additionally along with regular old-fashioned layouts. This might mean that there is no code overlap between Xinerama tile() and plain old tile()... but IMO that's a better way to go with than putting Xinerama at the core of dwm. Dual screen or a multiscreen setups are more related to the layout than dwm's core of tagging and focus control. Plus, I think it is a good idea to go to a direction where many people can take the dwm codebase and hack a new Xinerama layout onto it. The way you are proceeding with Xinerama seems to focus a lot more on the tile stack / monocle layout way doing things than just giving a mechanism for newer Xinerama layouts. I will suggest that you contain as many Xinerama changes as possible into drawbar() and tile() and push it as an alternative layout along with other dwm layouts. Ultimately, it depends on how fundamental you think the stack/monocle layout is to dwm. I really think that multihead setups offer many more feasible design choices than the highly popular stack/monocle layout for single monitor setups. _r I know that are some LOCs in the config.h, but they will allow to set dwm being used with Xinerama and without linking against -lXinerama, and also without reimplementing tile() or monocle() right NOW! I also plan to get rid of togglebar(), if you see not much use in the bar, put it on top of the T-area or M-area -- or move it offscreen. But this way, also the dzen-integration will be much easier and in a Xinerama setup you can make sure to let the bar appear only on a specific screen (or to let the T-area appear on a specific screen only). Actually the concept does only work up to 2 screens, but usually most people don't have more than 2 screens, and if someone has 3 or more screens, he might want to write his own version of tile() anyways. So I ask, do you think this decision is right? It will make dwm much simplier, Xinerama-capable and quite flexible in my eyes. Getting rid of mwfact, togglebar for the prize of Xinerama and monocle should be worth the effort, right? Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On 3/5/08, Ritesh Kumar [EMAIL PROTECTED] wrote: On Wed, Mar 5, 2008 at 12:38 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: First of all I want to get rid of setmwfact, MWFACT and mwfact, because I'd like to supply a saner way to setup the bar more freely. Actually I consider the following values in config.h (instead of BarPos): -- /* bar position */ #define BX sx #define BY sy #define BW sw #define BH bh /* master area */ #define MX sx #define MY sy + bh #define MW ((int)(((float)sw) * 0.6)) #define MH sh - bh /* tile area, might be on a different screen */ #define TX sx + MW #define TY MY #define TW sw - MW #define BH MH /* monocle area, might be restricted to a specific screen */ #define MOX sx #define MOY MY #define MOW sw #define MOH MH -- The flexibility is definitely good, however, it clutters the config.h with a lot of dwm internals, may be unnecessarily. Worse of all, it may still not be flexible enough for another person to modify it for a Xinerama layout of his own. I still think it will be a good decision to not give Xinerama first class status in dwm. IMHO dwm should enable just enough abstraction (I suggest tile()/drawbar() delegates in layout[]) so that Xinerama layouts can be developed additionally along with regular old-fashioned layouts. This might mean that there is no code overlap between Xinerama tile() and plain old tile()... but IMO that's a better way to go with than putting Xinerama at the core of dwm. Dual screen or a multiscreen setups are more related to the layout than dwm's core of tagging and focus control. Plus, I think it is a good idea to go to a direction where many people can take the dwm codebase and hack a new Xinerama layout onto it. The way you are proceeding with Xinerama seems to focus a lot more on the tile stack / monocle layout way doing things than just giving a mechanism for newer Xinerama layouts. I will suggest that you contain as many Xinerama changes as possible into drawbar() and tile() and push it as an alternative layout along with other dwm layouts. Ultimately, it depends on how fundamental you think the stack/monocle layout is to dwm. I really think that multihead setups offer many more feasible design choices than the highly popular stack/monocle layout for single monitor setups. _r I know that are some LOCs in the config.h, but they will allow to set dwm being used with Xinerama and without linking against -lXinerama, and also without reimplementing tile() or monocle() right NOW! I also plan to get rid of togglebar(), if you see not much use in the bar, put it on top of the T-area or M-area -- or move it offscreen. But this way, also the dzen-integration will be much easier and in a Xinerama setup you can make sure to let the bar appear only on a specific screen (or to let the T-area appear on a specific screen only). Actually the concept does only work up to 2 screens, but usually most people don't have more than 2 screens, and if someone has 3 or more screens, he might want to write his own version of tile() anyways. So I ask, do you think this decision is right? It will make dwm much simplier, Xinerama-capable and quite flexible in my eyes. Getting rid of mwfact, togglebar for the prize of Xinerama and monocle should be worth the effort, right? Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Maybe it's time to make dwm a little more modular.
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On 3/5/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: And here is my setup in action (btw. my dwm has 28000 bytes as binary): http://www.suckless.org/shots/dwm-4.8-xinerama.png The left screen is the master, the right screen is the stack (though, I'd really like to rotate that screen, but this is not possible -- maybe I will consider a vstack now as well) i don't like how monocle is treated specially in focus() the rational is that all my tiled layouts used monocle as a fallback if n=1 tiled window is visible so i don't have to reimplement all the hacks for this special case (eg avoiding /(n - 1), removing border, ..) right now i don't have nice solution (except checking n=1 in focus), i'll let you know when i have something better 'mc' is not necessary in tile() and 'i' can be eliminated as well (use n-- instead of i++)
