Let's come back to objective technical discussions... (and leave the rest to IRC or whatever, but out of mailbox please)
On Tue, 31 Oct 2006 06:22:17 +0100 Denis Grelich: > increment handling > it was complained often and by many about how windows who rely on > incrementation are handled. I would suggest to get rid of the margins > around increment-handled windows by simply fitting the window inside > the frame and filling the space inside the frame with black. Also, > let's just get rid of the relaxation altogether, since increment > handling doesn't fit into the dynamic wm paradigm anyway and those > apps should be avoided/replaced. Is ok for me. Currently some clients get resized several times, when de- and recofusing them, this is very annoying. This simple solution may waste more space, but treats all clients the same and seems to be less error-prone. > mouse focus model/borders > raise-on-focus has been identified as annoying. Even though > it might simplify things, it would be more useful to > have raise-on-click. To make this feasible, it is important to give > back some functionality to the title bars and the borders, but that > would raise even more questions. I suppose to postpone this issue to > after 3.5, since the complete focus model is due to discussion anyway > for wmii-4. Well...I don't need raise-on-focus, if the just the mouse is moved into the client's area. Raise-on-click is ok, but clients should still be raised when focusing them via keyboard-shortcuts. And I'd like to see click-through then... It's very annoying if you have the mouse over your client, it's defocused by keyboard-movement and you want to click a button, but you have to click twice. BTW this applies to the left button only, middle and right button have click-through! (and ever had) > compiler compatibility > Stefan Tibus sent in a patch working around some incompatibilities. It > is applied to current tip, but it introduced some problems. I'll look > into it on Thursday. The code should be cleaned up to standard C for > the release. Well...that certainly was quick'n'dirty, just to get it work. > re-adding swap > even though this adds yet another set of shortcuts, it is missed by > many. Yes - unless you can convince me of something better ;-) > column/frame resizing > visual aids when resizing frames and columns don't correspond to > reality. And there should be a proper interface regarding the resizing in managed mode by keyboard-shortcuts as well then. > some changes on the wmiirc. Especially the fact that you have > duplicated shortcut definitions is not ideal. Hm, yes, but this is somewhat related to the fact of wmiirc being a sh-script, isn't it? A somewhat configurable C-replacement could offer a simple and fast replacement. If somebody needs more flexibility the options are modifying the source or using a more powerful scripting language (and coping with their overhead). And: I don't need editable tagbars as long as I can do that via keyboard (and dmenu). It would probably be enough to attach "modify tag" (via dmenu) to e.g. right-click in the title-bar. (Also, most often it would be a waste of space having the tag in the title-bar (for me).) Regards, Stefan -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
