On Tue, Jun 13, 2006 at 09:10:09AM +0200, Anselm R. Garbe wrote:
> I can agree once we allow border based resizals, that vertical
> borders might affect the colums and horizontal borders the
> clients in managed mode. But if we do so, we should drop the
> current way completely. I don't see the need having several ways
> of resizing things, it confuses the concept and people to much.
> There should always be one and only one way to do something.
Well...if I want to resize a column, I should drag it's border
which consists of the vertical borders of the clients. So dragging
nearby a vertical border should bring up a vertical line representing
the border (between two columns) that I'm going to move.
Similarly for window heights within columns - move the horizontal
line seperating two clients.
> > Clients should only allow grow/shrink/move vertically, cols the same
> > bug horizontally, I'm afraid cols will need their own form of
> > pseudo-drag-boxes. I have a GUI thought out to do this while wasting
> > as little screen space as possible, and probably allowing managed area
> > resize with the mouse. But this is getting far ahead of ourselves,
> > lets fix client resizing first.
There's no need for special drag boxes or whatever then. Trying to
drag a border is very intuitive. It just needs some "grabbing"
distance to not need to point too precisely.
At the corner of a managed client one could either disallow resizes
or allow moving a horizontal and a vertical border at once. Or find
a better default (e.g. corner=vertical border).
> I don't think we need a special representation of colums if we
> define dragging vertical borders affects the column, horizontal
> borders affects the client. Exception: floating/sticky layers.
Floating layers will need some standard move/resize. Either
the current quadrant-based one or the classical border/title-bar
base one.
Regards,
Stefan
Received on Tue Jun 13 2006 - 11:07:17 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:09:18 UTC