Re: [wmii] "Rows" of columns? (feature/behaviour suggestion)

On 12/02/07, Kris Maglione <bsdaemon_AT_comcast.net> wrote:
> The problem lies in how it would muddy up the navigation.

Perhaps. Although I've imagined at least two possibilites...

METHOD 1:

The keys N and U are used to manage rows (in this example, anyway) - N
for dowN and U for Up (and they are conveniently near to the other
default nav keys).

To create a new row below, use Mod1-Shift-n to move the current frame
down into a new row of its own. Or Mod1-Shift-u to create a new row
above.

Each row behaves just like a normal screen - you can split the rows
into columns, assign the usual window management models to each
column, and the normal frame navigation keys will still "wrap" frames
within the same row at the top and bottom of each column.

Mod1-u and Mod1-n are used to navigate up and down between rows - the
Shift key being added to move frames between rows.

METHOD 2:

An alternative to this, I thought, would be to support multiple "tags"
to be shown on a single screen. You could replace the U and N keys
suggested above with a 'Row Management Mode', accessible a bit like
Tagging Mode through, say, Mod1-r. In Row Management Mode, you'd type
"1+2" & Enter to combine tags 1 and 2 on the same screen. Your bar at
the bottom might then look something like:
______________________________________
| 1:2 3 4 5:6:7 8 etc etc

When you combine tags, they are displayed top to bottom on the screen
in the order you enter them - eg, 1+2 would place 1 at the top, 2+1
would place 2 at the top, etc. You can only combine tags that are
assigned to existing frames, and when you destory the last frame with
a particular tag, it's "row" would be destroyed and that tag removed
from any tag combinations.

I feel I like Method 2 the best as it uses what appears to be existing
functionality for navigation, and extends the potential of tagging.

For both methods, resizing a row would be the same as resizing a
column currently: if the right-click/mouse-move is started near to a
row boundary, it'll resize the relevant rows - as well as the frame
and column, if appropriate.

As for usefulness, I don't think this would be a "killer feature",
hence I can accept Uriel's viewpoint about cost/benefit. I *can*
already use unmanaged frames to achieve a better layout; except that
navigation between frames - and the placement of floating/fixed-size
frames - breaks down from the elegant ideal of a managed, dynamic and
tiled workspace.

I think rows would be useful to an extent on screens <= 1024px wide.
And I can also imagine potential on larger screens for having
different numbers of columns in each row.

Best wishes,
M.
Received on Mon Feb 12 2007 - 22:20:59 UTC