Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Wed, Mar 05, 2008 at 05:00:22PM -0500, Jeremy O'Brien wrote: 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? It should work unfortunately :( Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Wed, Mar 05, 2008 at 05:42:27PM -0500, Ritesh Kumar wrote:
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.
Well, the design decision I made so far is, that there should
only be a single bar at a certain screen in a multihead setup.
Thus those new values in config.h which replace BARPOS. The bar
represents the internal state of dwm, the tags in use, the
layout algorithm, the title of the focused client and some
status text. I learned due to my experiments during the last
weeks, that several bars with duplicate information is not a
nice idea.
However, more complex layouts, especially layouts for
multiheads, need a separate layout function which can be
included using #include your_layout.c in config.h. I don't
want that a layout developer has to bother about drawing the
bar, he only has to bother about how to calculate window
geometries.
So it doesn't hurts that much, that there is M{X,Y,W,H} and
T{X,Y,W,H}, a more advanced layout which does Xinerama calls
does not need to make use of those definitions at all.
I think it is really the best to keep things as simple as they
are -- and keeping the layout algorithm as is. The above
decision to allow for more fine-grain bar positioning allows all this.
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.
I think that the tiled layout is a fundamental layout in dwm,
and it scales well two 2 screens already. It won't work for 3,
but the number of people using 3 screens is very low, so those
might prefer a separate layout algorithm 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 11:00:49PM -0500, John S. Yates, Jr. wrote:
I have not looked at the code in a good while but wanted to suggest
the following code concept. My thought sprang from Anselm writing
I propose using setlayout([M]) and setlayout([]=)
and then later
I plan to introduce 3 additional key bindings:
Mod1-f (Apply floating layout)
Mod1-m (Apply monocle layout)
Mod1-t (Apply tiled layout)
There already is a notion of the current layout. Imagine that
there is also a saved layout and the following function:
char *resolvelayout(char *proposed)
{
if (proposed == current)
proposed = saved;
else
saved = current;
current = proposed;
return proposed;
}
With this function I can have every target layout toggle:
setlayout( resolvelayout([M]) );
setlayout( resolvelayout([]=) );
setlayout( resolvelayout() );
Just a thought,
/john
john,
thanks for bothering. I'll have a look at this. I believe that
toggling back and forth is frequently much better than explicit
selection of the desired layout, even for the price of a few lines of
code :-).
joerg
Re: [dwm] visibility of focused windows
On Thu, Mar 06, 2008 at 03:35:08PM +0100, Joerg van den Hoff wrote:
On Wed, Mar 05, 2008 at 11:00:49PM -0500, John S. Yates, Jr. wrote:
I have not looked at the code in a good while but wanted to suggest
the following code concept. My thought sprang from Anselm writing
I propose using setlayout([M]) and setlayout([]=)
and then later
I plan to introduce 3 additional key bindings:
Mod1-f (Apply floating layout)
Mod1-m (Apply monocle layout)
Mod1-t (Apply tiled layout)
There already is a notion of the current layout. Imagine that
there is also a saved layout and the following function:
char *resolvelayout(char *proposed)
{
if (proposed == current)
proposed = saved;
else
saved = current;
current = proposed;
return proposed;
}
With this function I can have every target layout toggle:
setlayout( resolvelayout([M]) );
setlayout( resolvelayout([]=) );
setlayout( resolvelayout() );
Just a thought,
I agree, that's a nice solution in my eyes.
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Thu, Mar 06, 2008 at 09:31:22AM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 05:00:22PM -0500, Jeremy O'Brien wrote: 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? It should work unfortunately :( Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Well I must be doing something wrong then. Here's the two situations I've tried: http://pohl.ececs.uc.edu/~jeremy/dwm_config1.h http://pohl.ececs.uc.edu/~jeremy/screen1.png http://pohl.ececs.uc.edu/~jeremy/dwm_config2.h http://pohl.ececs.uc.edu/~jeremy/screen2.png Also, in both layouts, opening floating windows causes them to open over the bar, and the monocle layout behaves very strangely with floating windows. Basically, switching to a tiled window from a floating window using the mouse (no clicking) causes the floating window to become fullscreen and steal focus. Was this intended? It breaks the whole floating/tiled paradigm IMHO. So I'm thinking it's a bug. But correct me if I'm wrong. -- 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 pgpfSUkWQWr06.pgp Description: PGP signature
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Thu, Mar 06, 2008 at 12:13:50PM -0500, Jeremy O'Brien wrote: On Thu, Mar 06, 2008 at 09:31:22AM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 05:00:22PM -0500, Jeremy O'Brien wrote: 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? It should work unfortunately :( Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Well I must be doing something wrong then. Here's the two situations I've tried: http://pohl.ececs.uc.edu/~jeremy/dwm_config1.h http://pohl.ececs.uc.edu/~jeremy/screen1.png http://pohl.ececs.uc.edu/~jeremy/dwm_config2.h http://pohl.ececs.uc.edu/~jeremy/screen2.png Also, in both layouts, opening floating windows causes them to open over the bar, and the monocle layout behaves very strangely with floating windows. Basically, switching to a tiled window from a floating window using the mouse (no clicking) causes the floating window to become fullscreen and steal focus. Was this intended? It breaks the whole floating/tiled paradigm IMHO. So I'm thinking it's a bug. But correct me if I'm wrong. Well there were a lot of nitpicks. I hope they are fixed now, see my next mail. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] Xinerama in the right way, bar position, togglebar(), setmwfact()?
On Thu, Mar 06, 2008 at 08:09:40PM +0100, Anselm R. Garbe wrote: On Thu, Mar 06, 2008 at 12:13:50PM -0500, Jeremy O'Brien wrote: On Thu, Mar 06, 2008 at 09:31:22AM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 05:00:22PM -0500, Jeremy O'Brien wrote: 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? It should work unfortunately :( Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Well I must be doing something wrong then. Here's the two situations I've tried: http://pohl.ececs.uc.edu/~jeremy/dwm_config1.h http://pohl.ececs.uc.edu/~jeremy/screen1.png http://pohl.ececs.uc.edu/~jeremy/dwm_config2.h http://pohl.ececs.uc.edu/~jeremy/screen2.png Also, in both layouts, opening floating windows causes them to open over the bar, and the monocle layout behaves very strangely with floating windows. Basically, switching to a tiled window from a floating window using the mouse (no clicking) causes the floating window to become fullscreen and steal focus. Was this intended? It breaks the whole floating/tiled paradigm IMHO. So I'm thinking it's a bug. But correct me if I'm wrong. Well there were a lot of nitpicks. I hope they are fixed now, see my next mail. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Wow. Just updated, and the problems seem to be fixed 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 pgpRmFYBa1xtB.pgp Description: PGP signature
[dwm] recent changes
I investigated further today and refactored a lot. First of all
I got rid of dozoom, I extended Layout to contain a Bool
isfloating flag as well, which roughly tells dwm that the
layout algorithm is floating (hence there are no layers of tiled
windows being treated differently if isfloating is True in Layout).
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
I decided to add a tileh() layout which does the following in my
multiscreen setup (and which is pretty much similiar to
bstack, except that it expands on my second bigger screen), see
this screenshot:
http://www.suckless.org/shots/dwm-hstack.png
I also changed setlayout that it toggles to the previous layout,
if it is called twice. Due the fact of tileh, I changed the
setlayout keybindings slightly as you will notice on the
screenshot.
Also, monocle() now works like a floating layout, except that it
maximizes all windows to MOX, MOY, MOW, MOH. I decided against
rectangle restoring, this is a dynamic WM anyways.
I will be offline till Tuesday. Please test the stuff, report
bugs and feedback on this list, I will have a look then and
consider releasing the stuff next week.
Btw. I also changed dmenu yesterday, -b is gone, instead I
introduced -x x -y y -w w as command line options.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] recent changes
On 3/6/08, Anselm R. Garbe [EMAIL PROTECTED] wrote: I investigated further today and refactored a lot. First of all nice tileresize() is not in lexicographic order in dwm.c ;)
Re: [dwm] recent changes
On 3/6/08, Anselm R. Garbe [EMAIL PROTECTED] wrote:
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
yes finally i don't need extra layout.c to use bstack
comments:
there is an unnecessary whitespace after 'monocle(void) { '
tileresize(..) should be predeclared since it may be useful for other
layouts as well
imho there are a couple of unnecessary '('')' around M{X,Y,..} T{X,Y,..}
i still don't like the extra borders when only one window is shown so
i use a maximize(Client *c) which temporarily sets the border to 0
tileresize() then sets the border back.
Re: [dwm] recent changes
Szabolcs Nagy dixit (2008-03-06, 23:23):
On 3/6/08, Anselm R. Garbe [EMAIL PROTECTED] wrote:
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
yes finally i don't need extra layout.c to use bstack
However, this poses a problem that bottomstack layout would be the only
standard layout (apart from float and monocle), while it usually makes
sense to have bottomstack and standard tile interchangable.
To have both I'd have to have to hack two versions of tile(), with two
different sets of M{X,Y,W,H} and T{X,Y,W,H} values, right?
So this would still need a patch rather than be usable out of the box
the usual bottomstack way.
Best,
--
[a]
signature.asc
Description: Digital signature
Re: [dwm] recent changes
On 3/6/08, Antoni Grzymala [EMAIL PROTECTED] wrote:
To have both I'd have to have to hack two versions of tile(), with two
different sets of M{X,Y,W,H} and T{X,Y,W,H} values, right?
So this would still need a patch rather than be usable out of the box
the usual bottomstack way.
hm maybe one can use
const int MX =..;
void setbottomstack(void){
MX = ..;
}
void setrightstack(void){
MX = ..;
}
it is shorter than writing a whole layout
Re: [dwm] recent changes
On 3/6/08, Szabolcs Nagy [EMAIL PROTECTED] wrote: const int MX =..; ..that should be plain int, not const int
Re: [dwm] recent changes
My impressions about this commit are:
*) At the beggining I feel a bit confused until fixed the master and slave
resolutions on a single screen (because xinerama seems to crash my kernel
and I can't test it in all its glory atm)
*) Using this concept on a single screen looks a bit more claustrofobic
because of the lack of setmwfact.
- On my 20 screen, the lack of setmwfact doesnt affects to me, but
using a static mwfact with the proper values for the monocle layout
is imho much more clear than having a variable one which distracts.
- Dropping the statusbar from the slave area we can play with a bigger
area (we have some more pixels O:)
* We need a MOBW variable when single window is opened or using monocle layout.
*) I really miss the possibility to link mouse actions on the statusbar :(
it makes the use much more usable when you have a hand on the keyboard
and the another one in the mouse, so you don't have to move the pointer
to zoom, kill or select clients.
I would like to have this patch on mainstream too. I think my current patch
fits quite well for most uses and doesnt needs to be configurable, maybe
a little of feedback can help to adopt this functionality, which IMHO
for larger screen (or multiple ones) much more productive than moving the
mouse around the clients.
*) I also miss the clients per tag patch O:) but I will probably redesign it
for dwm 4.8, so we can probably change the concept of CPT to define the
number of windows to be shown in the master area.. But I understand that
this is not necessary in mainstream because can be replaced with correct
use of the tagging concept.
*) My general impression was a bit frustrating at the beggining, but after
reading some source, playing a bit with the configuration and thinking
in some solutions I come to the conclusion that I'm pretty happy with
this new concept.
Source comments:
* If we change these #defines to integer variables we will be able to write
external
commands to swap master and slave area between two monitors, join both areas,
manage
setmwfact or creating mixed layouts. And everything without touching the core :)
* We will be able to define a master layout, tile layout.
I know that not all layouts will work for all screen configurations, but we
can just
try to handle the most common uses.
* looks like the monocle layout doesnt works as expected so it eats some more
screen
than in should :) and the right/bottom borders are out of screen
* at line 1567 (nice number):
...
for(i = 0, c = nexttiled(clients); c; c = nexttiled(c-next), i++)
if(i 0) {
if(i 1 i == n) /* remainder */
...
This nested conditional looks ugly to my eyes, I would prefer to setup the
proper value for 'c' before starting the loop instead of checking the
conditional for every client.
Nice work!
--pancake
On Thu, 6 Mar 2008 20:20:00 +0100
Anselm R. Garbe [EMAIL PROTECTED] wrote:
I investigated further today and refactored a lot. First of all
I got rid of dozoom, I extended Layout to contain a Bool
isfloating flag as well, which roughly tells dwm that the
layout algorithm is floating (hence there are no layers of tiled
windows being treated differently if isfloating is True in Layout).
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
I decided to add a tileh() layout which does the following in my
multiscreen setup (and which is pretty much similiar to
bstack, except that it expands on my second bigger screen), see
this screenshot:
http://www.suckless.org/shots/dwm-hstack.png
I also changed setlayout that it toggles to the previous layout,
if it is called twice. Due the fact of tileh, I changed the
setlayout keybindings slightly as you will notice on the
screenshot.
Also, monocle() now works like a floating layout, except that it
maximizes all windows to MOX, MOY, MOW, MOH. I decided against
rectangle restoring, this is a dynamic WM anyways.
I will be offline till Tuesday. Please test the stuff, report
bugs and feedback on this list, I will have a look then and
consider releasing the stuff next week.
Btw. I also changed dmenu yesterday, -b is gone, instead I
introduced -x x -y y -w w as command line options.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] and now for something completely different...
On Thu, Mar 6, 2008 at 11:34 AM, y i y u s [EMAIL PROTECTED] wrote: Well, I have been thinking about the last dwm changes and I don't like the new monocle thing. I have decided that I don't use different layouts at all, so I have highly patched current hg tip to suit my needs. The patch is a bit dirty (there are things which can be improved, and I have included my personal configuration). I know official dwm won't behave this way, but maybe you can get some ideas from this patch. Basically it removes the layouts concept, for me togglefloating is enough. I also don't need monocle, a single function suffices (now it is called togglemax, it should be maximize, but ok). I have also included some mouse functions in the bar. Probably you can have problems in xinerama, but I cannot test it. I'd like to hear your opinion, because once 4.8 is released I plan to split it up in several patches if people have interest... slds, -- I would like to know how diverse are the people on the list in terms of the actual layouts and dwm features they use... that will be good feedback for all of us to know about the way dwm is patched and used by the community. I see value in allowing more people to be able to _easily_ patch dwm for their needs and be able to learn from it and incorporate essential features in dwm. I personally patch dwm so that I can easily restrict the *number* of windows that are shown in the stack layout. Its based on pancake's older clientspertag patches and shows in the status bar how many windows are hidden from view. Now, restricting the number of windows to 1 easily makes it full screen... and at the cost of a bit of elegance in the code I was able to hack in a monocle behavior for this particular case of limiting the number of displayed windows to 1. Now, the monocle behavior touched focusnext() and focusprev() and I also touched drawbar() to show the number of hidden windows... I couldn't get all this done cleanly separated in tile(). The point I am trying to make is that if a lot of people patch dwm.c for whatever functionality they need then we didn't do a good job in dwm.c to help abstract and modularize things. Also, the one thing that is modularized and abstracted out in dwm, through the variable layout[], is the function tile() which I haven't modified heavily. I am not suggesting delaying 4.8 but I guess a good strategy going forward will be to get a feel of what kind of things the audience on this list like to modify about dwm and what's dwm's core. We should do something to cleanly separate *those* things in dwm. IMHO tile is definitely not a good choice... I would even argue that fitting Xinerama layouts in core dwm is also a step in the wrong direction. _r
Re: [dwm] recent changes
Sorry when I dislike this solution, but it's far to complex. I wished
a solution which is simpler and without splitting tile.
Let me try to build a different idea.
2008/3/7, pancake [EMAIL PROTECTED]:
My impressions about this commit are:
*) At the beggining I feel a bit confused until fixed the master and slave
resolutions on a single screen (because xinerama seems to crash my kernel
and I can't test it in all its glory atm)
*) Using this concept on a single screen looks a bit more claustrofobic
because of the lack of setmwfact.
- On my 20 screen, the lack of setmwfact doesnt affects to me, but
using a static mwfact with the proper values for the monocle layout
is imho much more clear than having a variable one which distracts.
- Dropping the statusbar from the slave area we can play with a bigger
area (we have some more pixels O:)
* We need a MOBW variable when single window is opened or using monocle
layout.
*) I really miss the possibility to link mouse actions on the statusbar :(
it makes the use much more usable when you have a hand on the keyboard
and the another one in the mouse, so you don't have to move the pointer
to zoom, kill or select clients.
I would like to have this patch on mainstream too. I think my current patch
fits quite well for most uses and doesnt needs to be configurable, maybe
a little of feedback can help to adopt this functionality, which IMHO
for larger screen (or multiple ones) much more productive than moving the
mouse around the clients.
*) I also miss the clients per tag patch O:) but I will probably redesign it
for dwm 4.8, so we can probably change the concept of CPT to define the
number of windows to be shown in the master area.. But I understand that
this is not necessary in mainstream because can be replaced with correct
use of the tagging concept.
*) My general impression was a bit frustrating at the beggining, but after
reading some source, playing a bit with the configuration and thinking
in some solutions I come to the conclusion that I'm pretty happy with
this new concept.
Source comments:
* If we change these #defines to integer variables we will be able to write
external
commands to swap master and slave area between two monitors, join both
areas, manage
setmwfact or creating mixed layouts. And everything without touching the
core :)
* We will be able to define a master layout, tile layout.
I know that not all layouts will work for all screen configurations, but we
can just
try to handle the most common uses.
* looks like the monocle layout doesnt works as expected so it eats some
more screen
than in should :) and the right/bottom borders are out of screen
* at line 1567 (nice number):
...
for(i = 0, c = nexttiled(clients); c; c = nexttiled(c-next), i++)
if(i 0) {
if(i 1 i == n) /* remainder */
...
This nested conditional looks ugly to my eyes, I would prefer to setup the
proper value for 'c' before starting the loop instead of checking the
conditional for every client.
Nice work!
--pancake
On Thu, 6 Mar 2008 20:20:00 +0100
Anselm R. Garbe [EMAIL PROTECTED] wrote:
I investigated further today and refactored a lot. First of all
I got rid of dozoom, I extended Layout to contain a Bool
isfloating flag as well, which roughly tells dwm that the
layout algorithm is floating (hence there are no layers of tiled
windows being treated differently if isfloating is True in Layout).
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
I decided to add a tileh() layout which does the following in my
multiscreen setup (and which is pretty much similiar to
bstack, except that it expands on my second bigger screen), see
this screenshot:
http://www.suckless.org/shots/dwm-hstack.png
I also changed setlayout that it toggles to the previous layout,
if it is called twice. Due the fact of tileh, I changed the
setlayout keybindings slightly as you will notice on the
screenshot.
Also, monocle() now works like a floating layout, except that it
maximizes all windows to MOX, MOY, MOW, MOH. I decided against
rectangle restoring, this is a dynamic WM anyways.
I will be offline till Tuesday. Please test the stuff, report
bugs and feedback on this list, I will have a look then and
consider releasing the stuff next week.
Btw. I also changed dmenu yesterday, -b is gone, instead I
introduced -x x -y y -w w as command line options.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key:
