These days my dwm has converted on a layout testing environment, and
i have been playing with them a lot mostly working with terminals
and epiphany (faster and less buggy than firefox).
My experience these days has concluded on reducing the number of
layouts to three:
- tiled
- floating
- monocle
1) monocle vs cpt
I have not ported my clients-per-tag patch to the {h,v}ratio concept,
so i have been using monocle. None of them completely satisfy my needs.
(talking about monocle vs cpt). Both of them tries to fix the same
problem in two manners:
- monocle: layout
- cpt: patch for layouts (only tiled atm)
The problem with monocle is that you can't switch between two
modes easily (float-monocle, tile-monocle, spiral-monocle...),
and the good thing of these patches is taht allows you to focus
a window in fullscreen, and swap again to the previous mode (mostly
tiled).
The cpt patch adds some new options. It allows you to bind a key
to view only a certain number of clients, or make this key a
toggable one to view N clients or all of them, so you can easily
swap between "monocle" (one client) or all of them with a single
keybinding.
The problem with the CPT patch is that if you change to a new
client, it doesn't raises.
This fix can be easily done by adding two lines in the prev/nextclient
function checking if cpt != 0..but this looks ugly to me..maybe dwm
have to raise the current selected window at top automatically?
If cpt (or dwm?) fixes this, the monocle patch will not be required
anymore to fit this. The "problem" is that all the rest of layouts
require modification to use the 'cpt' concept.
2) floating and swapping layouts
About the floating layout I think it's useful, but only when you are
predisposed to use the mouse. btw, the moveresize patch is not as usable
as it should.
These comes again on the toggable dilema. Should a layout can be
toggable? something like ^floating, so you could put/drop a layout
with the same keybinding.
A similar approach would be to implement something like setlayout(NULL)
but allowing '-1'. To be able to go forward or backward when changing
between layouts. IMHO it's problematic when you have >2 layouts.
3) {h,v}factor
After testing it some days I can agree that it's probably not a good
approach, why not trying with a percentatge instead of a factor?
I think dwm should be as simple as possible, and with splitting clients
at a proportional size is nice and effective, but can probably not
fit all the needs. (at least my owns O:)
Using a percentatge approach it could be possible to change the
percentatge of the height size of the first client in the slave
area. This way you can 'simulate' the cpt patch by showing two
windows or all using a single key ('^' prefix).
Don't know if it could be better to have the rest of clients splitted
proportionally or equal to the left space in the slave area. Maybe
a proportional approach will make more sense.
Having a bigger client on the slave area is imho a nice idea.
Actually I'm using a factor that makes the first window be a 50%
of the screen's height. And that's useful, but if I temporally open
a terminal or have more than N opened clients, dwm removes the
"small" clients giving a strange sensation. IMHO clients should not
magically dissapear. They should be there if the user wants. So
giving a cpt or proportional approach that could be fixed.
Read this email as a bunch of random ideas and feel free to discuss them :)
--pancake
Received on Sat Aug 11 2007 - 20:30:42 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 14:48:58 UTC