Re: [dwm] togglemax substiute in 4.9?
On Tue, Apr 08, 2008 at 07:52:03PM +0200, Matthias-Christian Ott wrote: yy [EMAIL PROTECTED] wrote: Well, this is my proposal in patch form. I'm not sure about the convenience of setting fx and fy in tileresize, but you get the idea. I posted a similar patch on 31st March, so it is wasted effort. Hehe, indeed your both solutions are very close. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] togglemax substiute in 4.9?
2008/4/9, Anselm R. Garbe [EMAIL PROTECTED]: On Tue, Apr 08, 2008 at 07:52:03PM +0200, Matthias-Christian Ott wrote: yy [EMAIL PROTECTED] wrote: Well, this is my proposal in patch form. I'm not sure about the convenience of setting fx and fy in tileresize, but you get the idea. I posted a similar patch on 31st March, so it is wasted effort. Hehe, indeed your both solutions are very close. I'm not a fan of restoring floating geometries, that's why I didn't look at Matthias' patch; I just wanted to show how once you implement it, you don't need to change geometries in focus() to have the wanted behaviour in monocle. The difference between his patch and mine is that mine also restore geometries when coming back from monocle. Anyway, I have already done some changes (but I have them in my laptop, which I don't have at hand now). One is a check to not modify geometries with the mouse while in monocle layout when lt-isfloating is true, the other ones are some little improvements in the previous patch (I think I even removed some loc). If you are interested I will send them to the list this afternoon. greets, -- - yiyus || JGL .
Re: [dwm] togglemax substiute in 4.9?
On Wed, Apr 09, 2008 at 11:40:09AM +0200, yy wrote: 2008/4/9, Anselm R. Garbe [EMAIL PROTECTED]: On Tue, Apr 08, 2008 at 07:52:03PM +0200, Matthias-Christian Ott wrote: yy [EMAIL PROTECTED] wrote: Well, this is my proposal in patch form. I'm not sure about the convenience of setting fx and fy in tileresize, but you get the idea. I posted a similar patch on 31st March, so it is wasted effort. Hehe, indeed your both solutions are very close. I'm not a fan of restoring floating geometries, that's why I didn't look at Matthias' patch; I just wanted to show how once you implement it, you don't need to change geometries in focus() to have the wanted behaviour in monocle. The difference between his patch and mine is that mine also restore geometries when coming back from monocle. Anyway, I have already done some changes (but I have them in my laptop, which I don't have at hand now). One is a check to not modify geometries with the mouse while in monocle layout when lt-isfloating is true, the other ones are some little improvements in the previous patch (I think I even removed some loc). If you are interested I will send them to the list this afternoon. Yea just send me the bundle diff to 4.9 tonight. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] togglemax substiute in 4.9?
On Tue, Apr 08, 2008 at 07:16:03PM +0200, yy wrote: Well, this is my proposal in patch form. I'm not sure about the convenience of setting fx and fy in tileresize, but you get the idea. I think about your solution. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] togglemax substiute in 4.9?
On Mon 07-04-2008 13:55 +0200, Joerg van den Hoff wrote: question: any chance of making `dwm' remember any `floating' positioning information on a per-window basis which would enable restoration of positions when coming back to floating layout? Hi, I'd also like to see such a functionality for the monocle layout .. but the current layout architecture is not prepared for this. In my configuration I deactivated the monocle layout and reactivated the togglemax function that is part of the maximize patch anyway. Cheers. -- Jan Christoph Ebersbach But by the grace of God I am what I am. 1. Cor 15,10 signature.asc Description: Digital signature
Re: [dwm] togglemax substiute in 4.9?
On Mon, Apr 07, 2008 at 01:55:29PM +0200, Joerg van den Hoff wrote: as `togglemax' seems gone in 4.9: I agree, that `monocle' is very useful (and superior). the only problem is (seems?) that one cannot easily toggle back and forth to the previous layout. rather, one needs to cycle through all 4 layouts right now, it seems. this is not so nice... question: is their a chance to get a kind of `togglemonocle' functionality into dwm without writing it myself? this would seem a frequent demand: activate monocle for some time than switch back to tiling (or whatever layout was in effect previously). What about direct layout activation using the layout symbol as setlayout argument? As for setlayout() I consider having (const char *)-1 for the previous layout, (const char *)1 for the next and NULL for toggling between the current and previous one, if any. The same concept might be adapted for setgeom as well. Any complains? w.r.t. to `floating': I find it always rather annoying that leaving `floating' layout, i.e. going to some tiling layout, there is no way of going back to floating while getting back the previously manually selected arrangements of windows. I admit, I use `floating' rarely, but when I do, the above behaviour comes into the way quite often. the problem with destroying floating arrangements by selecting a diferent layout is, of course, especially severe because layout changes act global. question: any chance of making `dwm' remember any `floating' positioning information on a per-window basis which would enable restoration of positions when coming back to floating layout? Actually, I consider making an exception for floating and monocle alltogether. Monocle in 5.0 will only work on the focused client and restore after each unfocus to the previous geometry. So each client will have two geometries, the current and the previous one. This allows restoring the geometry when switching from tiled to monocle and back, resp. when switching from floating to tiled and back or vice versa. At manage() time I consider, that the previous geometry is the initial geometry as it would be for the floating case. Any complains? Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] togglemax substiute in 4.9?
On Tue, Apr 08, 2008 at 10:50:56AM +0200, Anselm R. Garbe wrote: On Mon, Apr 07, 2008 at 01:55:29PM +0200, Joerg van den Hoff wrote: as `togglemax' seems gone in 4.9: I agree, that `monocle' is very useful (and superior). the only problem is (seems?) that one cannot easily toggle back and forth to the previous layout. rather, one needs to cycle through all 4 layouts right now, it seems. this is not so nice... question: is their a chance to get a kind of `togglemonocle' functionality into dwm without writing it myself? this would seem a frequent demand: activate monocle for some time than switch back to tiling (or whatever layout was in effect previously). What about direct layout activation using the layout symbol as setlayout argument? yes, exactly what I do at the moment as a workaround. still this means hitting two different keys to go back and forth between two layouts. As for setlayout() I consider having (const char *)-1 for the previous layout, (const char *)1 for the next and NULL for toggling between the current and previous one, if any. The same concept might be adapted for setgeom as well. maybe too fast for me. meaning what from the user side? if I bind a key to setlayout(NULL) it toggles layouts, right? that would be perfect. Any complains? w.r.t. to `floating': I find it always rather annoying that leaving `floating' layout, i.e. going to some tiling layout, there is no way of going back to floating while getting back the previously manually selected arrangements of windows. I admit, I use `floating' rarely, but when I do, the above behaviour comes into the way quite often. the problem with destroying floating arrangements by selecting a diferent layout is, of course, especially severe because layout changes act global. question: any chance of making `dwm' remember any `floating' positioning information on a per-window basis which would enable restoration of positions when coming back to floating layout? Actually, I consider making an exception for floating and monocle alltogether. Monocle in 5.0 will only work on the focused client and restore after each unfocus to the previous again too fast. `client' means what in this context? a screen? a tag-workspace? geometry. So each client will have two geometries, the current and the previous one. This allows restoring the geometry when switching from tiled to monocle and back, resp. when switching from floating to tiled and back or vice versa. tiling implying `monocle' in the last sentence? At manage() time I consider, that the previous geometry is the initial geometry as it would be for the floating case. Any complains? as far as I get it I think your proposal sounds good. perfect in my view would be the following behaviour: each client (correct word?) remembers _permanently_ it's last floating geometry (if `floating' has been activated at all, yet). if I come back to floating from a different layout, most of the time probably directly, (i.e. this would be toggling back and forth) but probably only after switching to several different tiling layouts, the last floating geometry is restored. in other words this would single out `floating' as the only exceptional case. If furthermore apart from the current global change of layout _and_ `mwfact'an _optional_ change of these settings on a per- tag/workspace would be implemented in mainstream I probably would stop upgrading anymore, since nothing remains to be wished :-) Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 same to you, joerg
Re: [dwm] togglemax substiute in 4.9?
2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]: On Mon, Apr 07, 2008 at 01:55:29PM +0200, Joerg van den Hoff wrote: as `togglemax' seems gone in 4.9: I agree, that `monocle' is very useful (and superior). the only problem is (seems?) that one cannot easily toggle back and forth to the previous layout. rather, one needs to cycle through all 4 layouts right now, it seems. this is not so nice... question: is their a chance to get a kind of `togglemonocle' functionality into dwm without writing it myself? this would seem a frequent demand: activate monocle for some time than switch back to tiling (or whatever layout was in effect previously). What about direct layout activation using the layout symbol as setlayout argument? As for setlayout() I consider having (const char *)-1 for the previous layout, (const char *)1 for the next and NULL for toggling between the current and previous one, if any. The same concept might be adapted for setgeom as well. Any complains? I think that using the proposedlayout function as it was done in the past would be a better idea (and like it happens with tags if you use the last patch I've sent to the list), but I don't use different layouts any more, so my opinion is not important. w.r.t. to `floating': I find it always rather annoying that leaving `floating' layout, i.e. going to some tiling layout, there is no way of going back to floating while getting back the previously manually selected arrangements of windows. I admit, I use `floating' rarely, but when I do, the above behaviour comes into the way quite often. the problem with destroying floating arrangements by selecting a diferent layout is, of course, especially severe because layout changes act global. question: any chance of making `dwm' remember any `floating' positioning information on a per-window basis which would enable restoration of positions when coming back to floating layout? Actually, I consider making an exception for floating and monocle alltogether. Monocle in 5.0 will only work on the focused client and restore after each unfocus to the previous geometry. So each client will have two geometries, the current and the previous one. This allows restoring the geometry when switching from tiled to monocle and back, resp. when switching from floating to tiled and back or vice versa. At manage() time I consider, that the previous geometry is the initial geometry as it would be for the floating case. Any complains? If we are coming back to reverse geometries per client, what's the point of resizing clients in focus changes? I think this will add unnecesary complexity. But again, I don't think my opinion is important. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 -- - yiyus || JGL .
Re: [dwm] togglemax substiute in 4.9?
On Tue, Apr 08, 2008 at 01:35:40PM +0200, yy wrote: 2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]: On Mon, Apr 07, 2008 at 01:55:29PM +0200, Joerg van den Hoff wrote: as `togglemax' seems gone in 4.9: I agree, that `monocle' is very useful (and superior). the only problem is (seems?) that one cannot easily toggle back and forth to the previous layout. rather, one needs to cycle through all 4 layouts right now, it seems. this is not so nice... question: is their a chance to get a kind of `togglemonocle' functionality into dwm without writing it myself? this would seem a frequent demand: activate monocle for some time than switch back to tiling (or whatever layout was in effect previously). What about direct layout activation using the layout symbol as setlayout argument? As for setlayout() I consider having (const char *)-1 for the previous layout, (const char *)1 for the next and NULL for toggling between the current and previous one, if any. The same concept might be adapted for setgeom as well. Any complains? I think that using the proposedlayout function as it was done in the past would be a better idea (and like it happens with tags if you use the last patch I've sent to the list), but I don't use different layouts any more, so my opinion is not important. You mean if the setlayout is called with the same argument as at the last time reverting to the pre-previous one? Well, with the proposed layout browsing using (const char*)1 (currently NULL) people would like to change the layout with one key combination only. And using NULL for the behavior seems more flexible in this regard, otherwise you always have to remember, which layout you are using atm to toggle back to the previously used one. Though I see the use-case of haven Mod1-m twice, maybe NULL and second-time-same-argument should do the same to allow both solutions? Any complains? If we are coming back to reverse geometries per client, what's the point of resizing clients in focus changes? I think this will add unnecesary complexity. But again, I don't think my opinion is important. What if monocle is used to work on floating clients as well? I pretty much prefer the solution of only preserving the previous window geometry of a client window and not treating floating and managed geometries differently. If monocle works on all clients, this would lead to unrevertable maximised floating clients, which I dislike. On the other hand, preserving the geometry for each layout seems to be too memory-consuming, especially because the layout algorithms are heavily dynamic. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] togglemax substiute in 4.9?
2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]: On Tue, Apr 08, 2008 at 01:35:40PM +0200, yy wrote: 2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]: Any complains? If we are coming back to reverse geometries per client, what's the point of resizing clients in focus changes? I think this will add unnecesary complexity. But again, I don't think my opinion is important. What if monocle is used to work on floating clients as well? I pretty much prefer the solution of only preserving the previous window geometry of a client window and not treating floating and managed geometries differently. If monocle works on all clients, this would lead to unrevertable maximised floating clients, which I dislike. On the other hand, preserving the geometry for each layout seems to be too memory-consuming, especially because the layout algorithms are heavily dynamic. I think I didn't explain myself very well. Let's try again... To restore all the clients to their previous position and size when you change to the floating layout you will need a per client reverse geometry where you store that data, I would call it floating geometry (e.g.: fx, fy, fw, fh), setted to the initial value by manage() like you suggested or by a mouse action. Then, when you change to floating layout, all the clients are resized to that value; when you change to tiled layout, floating clients are resized to that value and tiled clients are tiled; and when you select the monocle layout all the clients (or just the tiled ones, depending on the lt-isfloating value) are resized to mox, moy, mow, moh. As a personal preference, I wouldn't restore x and y values in non floating windows. I hope to have explained my idea better this time, I can write the patch if you want to give it a try. And about the setlayout behaviour, you are right that I was thinking in the maximize toggle with Mod1-m (or the float toggle with Mod1-Space), but as I told I don't really matter. slds, -- - yiyus || JGL .
Re: [dwm] togglemax substiute in 4.9?
yy [EMAIL PROTECTED] wrote: 2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]: On Tue, Apr 08, 2008 at 01:35:40PM +0200, yy wrote: 2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]: Any complains? If we are coming back to reverse geometries per client, what's the point of resizing clients in focus changes? I think this will add unnecesary complexity. But again, I don't think my opinion is important. What if monocle is used to work on floating clients as well? I pretty much prefer the solution of only preserving the previous window geometry of a client window and not treating floating and managed geometries differently. If monocle works on all clients, this would lead to unrevertable maximised floating clients, which I dislike. On the other hand, preserving the geometry for each layout seems to be too memory-consuming, especially because the layout algorithms are heavily dynamic. I think I didn't explain myself very well. Let's try again... To restore all the clients to their previous position and size when you change to the floating layout you will need a per client reverse geometry where you store that data, I would call it floating geometry (e.g.: fx, fy, fw, fh), setted to the initial value by manage() like you suggested or by a mouse action. Then, when you change to floating layout, all the clients are resized to that value; when you change to tiled layout, floating clients are resized to that value and tiled clients are tiled; and when you select the monocle layout all the clients (or just the tiled ones, depending on the lt-isfloating value) are resized to mox, moy, mow, moh. I vote for the floating geometry idea and prefer the interpretation that monocle only maximises one client at the same time, so you have only 4 variables containing the previous position and size, because just one client can be maximised at the same time. If you switch to another client which is going to be maximised, the geometry of the previously maximised client is restored and the values of the current client are stored and can be restored, so it adds no runtime overhead and still makes per layout storage possible. Regards Matthias-Christian
Re: [dwm] togglemax substiute in 4.9?
Well, this is my proposal in patch form. I'm not sure about the
convenience of setting fx and fy in tileresize, but you get the idea.
--
- yiyus || JGL .
diff -r 595ed1a4447c dwm.c
--- a/dwm.c Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c Tue Apr 08 18:59:12 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
struct Client {
char name[256];
int x, y, w, h;
+ int fx, fy, fw, fh;
int basew, baseh, incw, inch, maxw, maxh, minw, minh;
int minax, maxax, minay, maxay;
long flags;
@@ -285,8 +286,11 @@ arrange(void) {
Client *c;
for(c = clients; c; c = c-next)
- if(isvisible(c))
+ if(isvisible(c)) {
unban(c);
+ if(!lt-isfloating c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+ }
else
ban(c);
@@ -676,7 +680,7 @@ floating(void) { /* default floating lay
for(c = clients; c; c = c-next)
if(isvisible(c))
- resize(c, c-x, c-y, c-w, c-h, True);
+ resize(c, c-fx, c-fy, c-fw, c-fh, True);
}
void
@@ -996,8 +1000,8 @@ manage(Window w, XWindowAttributes *wa)
/* geometry */
c-x = wa-x;
c-y = wa-y;
- c-w = wa-width;
- c-h = wa-height;
+ c-w = c-fw = wa-width;
+ c-h = c-fh = wa-height;
c-oldbw = wa-border_width;
if(c-w == sw c-h == sh) {
c-x = sx;
@@ -1015,6 +1019,8 @@ manage(Window w, XWindowAttributes *wa)
c-y = wy;
c-bw = BORDERPX;
}
+ c-fx = c-x;
+ c-fy = c-y;
wc.border_width = c-bw;
XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1110,8 +1116,11 @@ movemouse(Client *c) {
ny = wy + wh - c-h - 2 * c-bw;
if(!c-isfloating !lt-isfloating (abs(nx - c-x) SNAP || abs(ny - c-y) SNAP))
togglefloating(NULL);
- if((lt-isfloating) || c-isfloating)
+ if((lt-isfloating) || c-isfloating) {
resize(c, nx, ny, c-w, c-h, False);
+c-fx = nx;
+c-fy = ny;
+ }
break;
}
}
@@ -1273,8 +1282,11 @@ resizemouse(Client *c) {
nh = 1;
if(!c-isfloating !lt-isfloating (abs(nw - c-w) SNAP || abs(nh - c-h) SNAP))
togglefloating(NULL);
- if((lt-isfloating) || c-isfloating)
+ if((lt-isfloating) || c-isfloating) {
resize(c, c-x, c-y, nw, nh, True);
+c-fw = nw;
+c-fh = nh;
+ }
break;
}
}
@@ -1657,6 +1669,8 @@ tileresize(Client *c, int x, int y, int
if((RESIZEHINTS) ((c-h bh) || (c-h h) || (c-w bh) || (c-w w)))
/* client doesn't accept size constraints */
resize(c, x, y, w, h, False);
+ c-fx = x;
+ c-fy = y;
}
void
@@ -1856,6 +1870,8 @@ view(const char *arg) {
memcpy(seltags, tmp, TAGSZ);
arrange();
}
+ else
+ viewprevtag(NULL);
}
void
Re: [dwm] togglemax substiute in 4.9?
yy [EMAIL PROTECTED] wrote: Well, this is my proposal in patch form. I'm not sure about the convenience of setting fx and fy in tileresize, but you get the idea. I posted a similar patch on 31st March, so it is wasted effort. Regards Matthias-Christian
[dwm] togglemax substiute in 4.9?
hi, as `togglemax' seems gone in 4.9: I agree, that `monocle' is very useful (and superior). the only problem is (seems?) that one cannot easily toggle back and forth to the previous layout. rather, one needs to cycle through all 4 layouts right now, it seems. this is not so nice... question: is their a chance to get a kind of `togglemonocle' functionality into dwm without writing it myself? this would seem a frequent demand: activate monocle for some time than switch back to tiling (or whatever layout was in effect previously). w.r.t. to `floating': I find it always rather annoying that leaving `floating' layout, i.e. going to some tiling layout, there is no way of going back to floating while getting back the previously manually selected arrangements of windows. I admit, I use `floating' rarely, but when I do, the above behaviour comes into the way quite often. the problem with destroying floating arrangements by selecting a diferent layout is, of course, especially severe because layout changes act global. question: any chance of making `dwm' remember any `floating' positioning information on a per-window basis which would enable restoration of positions when coming back to floating layout? regards, joerg
Re: [dwm] togglemax substiute in 4.9?
Hi Joerg,
question: is their a chance to get a kind of `togglemonocle'
functionality into dwm without writing it myself? this would
seem a frequent demand: activate monocle for some time than
switch back to tiling (or whatever layout was in effect
previously).
I had a similar demand, and I solved it by using a custom defgeom, as
the following in config.h :
DEFGEOM(full, 0, sh,sw, 0, 0, sw,sh, wx, wy, sw, sh, mx+mw, wy,
ww-mw, wh, wx, wy, ww, wh)
Geom geoms[] = {
/* symbol function */
{ [], single }, /* first entry is default */
{ [f],full },
};
With this configuration, I got something similar to togglemax() by
using Ctrl+Mod+Space.
HTH,
--
Julien
Re: [dwm] togglemax substiute in 4.9?
On Mon, Apr 07, 2008 at 02:07:04PM +0200, Julien Barnier wrote:
Hi Joerg,
question: is their a chance to get a kind of `togglemonocle'
functionality into dwm without writing it myself? this would
seem a frequent demand: activate monocle for some time than
switch back to tiling (or whatever layout was in effect
previously).
I had a similar demand, and I solved it by using a custom defgeom, as
the following in config.h :
DEFGEOM(full, 0, sh,sw, 0, 0, sw,sh, wx, wy, sw, sh, mx+mw, wy,
ww-mw, wh, wx, wy, ww, wh)
Geom geoms[] = {
/* symbol function */
{ [], single }, /* first entry is default */
{ [f],full },
};
With this configuration, I got something similar to togglemax() by
using Ctrl+Mod+Space.
HTH,
--
Julien
julien,
thanks for responding. I've not dived into the new `geom'
stuff yet, but tried your patch simply as is. I find that it
always maximizes the master area, irrespective of current
focus (but keeps the focused window in the foreground). is
that as it should be?
so, this patch helps some, but a real `togglelayout' would
be nicer :-)
joerg
