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? > _______________________________________________ > [email protected] mailing list > http://wmii.de/cgi-bin/mailman/listinfo/wmii -- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
