Re: [wmii] Column Layouts

Hi David,

On Thu, Apr 27, 2006 at 08:33:00PM -0400, David Arroyo wrote:
> So, instead of treating each column as being in a specific
> "mode", it should just be a matter of geometry. "The window in
> this column has been sized so large that only the titlebars of
> the other windows are visible." So instead of changing a
> columns mode, alt-s would push windows other than the selected
> one to the top and bottom of the columns. alt-m would go
> farther. This frees up alt-d, which could possibly be bound to
> "grow" a client in its column by a set (perhaps configurable)
> amount. Clients selected with 0 height can also be grown in
> this amount, so you can cycle over windows as one cycles over
> folders in a filing cabinet, looking at the sliver of window
> that peeps up. To get the current behaviour would require you
> to select the window and use the stack action, which is
> arguably not as ideal, but you'd get the benefit of more
> flexibility with columns. I have heard a few people on #wmii
> ask if they could have more than one window viewable in a
> stacked column.

I also thought about simplifying the mode concept of columns,
but with a quite different approach. What you describe is
already possible to some extend in default mode (even through
writing to geom files, though I plan to remove the geom syntax
as it is now (with the +- stuff, and only allowing explicit
coordinates, instead additionally resize +/-<w> +/-<h> and move
+/-<x> +/-<y> actions are needed in the associated ctl devices
of clients. This will make the blitz_strtorect() function less
cumbersome and provide a more flexible interface after all).
Normally you'd use the mouse for resizals in default mode (which
actually also keeps track of scaling if clients (dis)appear.

Anyway. Your approach has the big disadvantage, that it sounds
to need much more interactions than pressing a simple key or
clicking a tag and arranging the clients of a column
differently. You always need to invoke a resize action, in the
end this feels less dynamic than the current approach.

Instead of throwing the different modes completely over board, I
found a way to generalize the behavior. The key idea is that all
columns are in stacking mode all the time, and that the 'mode'
file in the column namespace is replaced with a 'stack' file,
which takes following special syntax:

  0: means no space for stacks, thus maximize all windows
  n: n visible stacked clients (focused client defines the center
     of the visible clients which is calculated through n/2).
     All other clients only get a titlebar (fallback to 0 if too
     many clients appear like in wmii-3)
100: make all clients visible (like current default), fallback
     to 0 if too many clients appear)

For n > 1 it is allowed to resize the heights of visible clients
(though unless the stacking is not *, this arrangement might
be changed on focus change).

This allows to have for example 3 clients always visible in a
column, all others are accessible through their titlebar and
wmii keeps track of them.

To clarify what happens on focus change imagine 6 clients with
stacking set to 2 visible clients per time. The center of two
visible clients is always the 1st client (2/2 == 1), thus if the
first of client of the column is focused, also the second is
visible, if the second is focused also the third is visible, but
the first is invisible, etc. The only exception will be on
boundaries, if the last client is selected, also the fifth
client will be visible.

When choosing an adequate value for your screen proportions,
this should work most of the time perfectly without further
manual arrangements like growing needed, but as I told, growing
would be still possible.

> To reiterate, the current implementation of column "modes" is
> overengineered.

Agreed, and if you think about my proposal, you will notice that
there is a single algorithm which keeps track of the above
arrangements based on the stack value.

> I know little of wmii under the hood, but perhaps making the
> geometry file more robust and eliminating column modes would
> be save some lines and some sanity. Note that if this is
> properly implemented, there will be little difference from the
> current behaviour, which is still very acceptable. This
> request enters the realm of fine-tuning; the stuff that will
> turn wmii from a window manager into a lovingly crafted work
> of art, and is probably better off in queue for wmii-4, if the
> proposal is to be considered at all. I'm not saying what you
> aught; I just feel the issue deserves some thought.

Sure it is a wmii-4 TODO, we already had feature freeze for
wmii-3 a week ago (with very small exceptions).

Thanks for your feedback!

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361