Re: [dwm] visibility of focused windows

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 <j.van_den_hoff_AT_fzd.de> 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
>
Received on Wed Mar 05 2008 - 15:36:53 UTC