I don't think the way columns work right now should be changed much. It is neither a good idea to restrict the numbers of columns (welcome back to larswm then... and btw I sometimes use 3 columns on 1280x1024) nor to add an additional tagging layer by applying tags to columns. The first one would just decrease flexibility and I just can't see the advantage (maybe we want 'select next column' to wrap around instead). The latter one is an implementation of nesting and there already has been some discussion on the problems arising with it (additional navigation layer, additional shortcuts, etc.) No, I think columns and views are fine as they are, however the screen and the applications are not as dynamic as wmii is and that's the problem. It is only because of this, that we ask for predefining/fixing column widths, client positions, layouts... But this is making things more static, which I believe is not wanted.
Splitting columns instead of adding columns is not just a matter of taste, but it depends on the situation which method is better. Splitting preserves the other columns widths, yes. But in any case where I don't have this requirement adding a column and rearranging widths appears better. Unfortunately the window manager has little knowledge of the needs of the applications, so it's hard to find a good general solution. I'm fine with the current method very often. Screen edges, however, are probably somehow known to the window manager and should be respected. I.e. other than by explicit user request a column should not span across a screen edge. (Besides some presentation purposes I would not expect anybody to want a single window spread across multiple screens.) Is it possible to have a single instance of a wm manage multiple X-screens/displays? This could help solving the issue. And regarding those screen edges - wasn't there a geometry file for the workspaces in the past? The views currently don't have this, but it would allow the user to shrink the area occupied by managed clients and place floating clients of fixed size within the free space so they don't cover the managed ones. This would require a default geometry and one per cached view. Regards, Stefan _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
