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
