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
Received on Tue Apr 08 2008 - 12:09:07 UTC