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 >
