Re: [wmii] Preparations for 3.5

On Tue, Oct 31, 2006 at 07:18:56AM +0100, Uriel wrote:
> >increment handling
> > it was complained often and by many about how windows who rely on
> > incrementation are handled. I would suggest to get rid of the margins
> > around increment-handled windows by simply fitting the window inside
> > the frame and filling the space inside the frame with black. Also,
> > let's just get rid of the relaxation altogether, since increment
> > handling doesn't fit into the dynamic wm paradigm anyway and those
> > apps should be avoided/replaced.
>
> What the hell is "relaxation"? Either way, apps that request increment
> handling
> should work, inc handling is an abomination, but it is part of X, and
> apps depend on it. At some point someone (JG?) was planning the most
> obvious solution: after sizes are assigned with inc-handling
> constraints in mind, stack all apps towards the end of the window,
> whatever space is left is distributed between the apps if it is enough
> to add an extra increment until nothing is left. I don't see why this
> is a problem at all.

What you describe is called 'relaxation' (this term is borrowed
from Donalds TeX typesetting algorithm, when aligning boxes).

However, in dwm I made good results with dropping inrement
handling for managed apps, and supporting it only for floating
apps - that works quite well, also regarding to st which won't
depend on inc handling. If you handle inremental resizals for
managed apps you will always get gaps if all apps in a specific
column request incremental resizals (which is the majority,
because wmii users are terminal users). Thus keep the column
layout algorithm as simple as possible and simply drop
incremental resizals from managed mode.

> JG and I had completely reworked the design for the keybindings
> interface and wmiirc, the new design was simpler, more elegant, more
> extensible and most importantly, it was not completely braindamaged
> like the current one. Details as usual in archives and logs.

See wmii-hackers archives for JGs RFC.

> >It is also needed to update the documentation to at least reflect the
> >new fs. Porting the old wiki to the new format is not of topmost
> >priority either, since 3.5 is only an intermediary release, but also
> >because the new taggi doesn't look feature-stable yet.

Obviously I need to repeat what I told: I asked for converting
the old wiki pages into markdown syntax. How taggi will arrange
the pages/tags is a different question. First we need the
available information in one place.

Regards,

-- 
 Anselm R. Garbe  ><><  http://suckless.org/~arg/  ><><  GPG key: 0D73F361