Re: [wmii] Dynamicness, Window Sizes (again, sorry) and Xinerama.

What I notice in your mail is a feature request which can be
summarized as:

"Provide some way to define the default column widths which are
used at creation time", ie '70:30'

Would that help?

Regards,
Anselm

On Thu, Apr 13, 2006 at 06:15:32AM +1000, Adrian Ratnapala wrote:
> OK, I had a planned detailed and thoughtful reply, but that
> was messy, so let's cut to the chase. I have been using
> the new snaps for a few weeks now, and after getting
> used to them, I am still dissatisfied. This is because I think
> wmii (or at least it's default key bindings?) only works well when
>
> (a) You are happy with one full screen column or two equal
> columns, AND
>
> (b) You only want basic operations for moving clients between cols.
>
> When these conditions are met, you just keep yourself
> in stacked or max mode and let $MODKEY-j/k do the
> rest, occasionally you do something more fancy.
> This is similar to the preferred way of using MS-Windows,
> which is to maximise everything and cycle with Alt-Tab.
>
> Surprisingly, I find my trouble lies with (a). I want
> to manage column sizes from within wmiirc. At
> work this is because my screen is small so I always
> want the most important column to be big, at home
> I want it so I can implement better Xinerama support.
>
> When I started scripting I ran into problems because
> could not know when a new column was created,
> (well presumably it's after Alt-Shift-n, but is it synchronous?).
> Really I don't want to know when a new col is created,
> the easiest thing for a script writer is to simply tell
> wmii "when columns come up, prefer these boundaries", rather
> than catching and redoing every column-shifting event.
>
> Suppose I solve my problems with restriction (a), one way or
> another. This brings in restriction (b). When all columns
> were equal I am happy to keep clients where they are, most
> of the time, but if one column is "better" than the others,
> I want easy ways of moving clients in and out of that column.
> This is the "old usage pattern" that Alt-Enter and Alt-Tab
> gave me in 2.5, they corresponded to powerful operations
> over the *whole view*, rather than a single column.
>
> > Anyway, I don't recommend to use the column layout in such old
> > usage patterns, instead I recommend to unlearn what you knew and
> > try to get used to the column layout. You'll notice after some
> > time, once you got familiar especially with the shortcuts:
> >
> > $MODKEY-h/j/k/l
> > $MODKEY-Shift-n (new column)
> > $MODKEY-Shift-h/l (move prev/next)
> > $MODKEY-Control-h/l (swap prev/next)
> > $MODKEY-d
> > $MODKEY-s
> > $MODKEY-m
> >
> > You'll notice that column layout is adaptable more efficiently
> > to each situation, than the layouts we got before. Not only
> > because tiled or grid layout scaled badly, also because the
> > basic mechanisms are reduced to a bunch of core key bindings.
>
> I agree the column layout is beautifully expressive, but the
> fact is that if we care about the whole view as a single entity,
> there are now 12 low level operations which you compose to get
> what you want. This composition must take into account the
> particular placement of your windows on the screen right now
> (you didn't care about that when you just cycled with
> $MODKEY-j/k, or Alt-Tab).
>
> For this reason lifting restriction (b) requires higher level
> operations, ones that can operate on the whole view. Such
> can probably be scripted easily as things stand now. But
> that will only be useful after restriction (a) is lifted.
>
> My ramblings about a "fixed landscape" (where fixed means scriptable)
> brings in both of these. The "landscape" gives hints to wmii
> about where to place future column borders. If such a landscape
> is known, the high level (b)-lifting shell routines might also
> be easier to write.
>
> P.S. when I get around to putting my time&effort where my mouth
> is, what is the preferred development method? Work with
> anon-access to the repository and then send a patch to Anselm?

> _______________________________________________
> wmii_AT_wmii.de mailing list
> http://wmii.de/cgi-bin/mailman/listinfo/wmii

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