On Tue, 31 Oct 2006 12:16:18 +0100 "Stefan Tibus" <[EMAIL PROTECTED]> wrote:
> 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. Full ACK on the keyboard part. > 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) Yes, but that haunted us since wmi, and no-one seemed to find the problem. As far as I have looked into it, other wm's don't have any code for this »feature,« this must rather be some oddity of wmii. Anyway, it would be enough to raise a window only after a click to the bar for now, since it will have focus anyway when the mouse entered its area. Click-to-focus can be discussed for wmii-4. > > 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. It would be nice though if you could lend a hand here. > > 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. I can live pretty fine without it, but if you want to see it implemented, I'm open for any more or less concrete suggestion. > > 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). If you want a C wmiirc, you could as well have all of the config in-source, or have a config file in some special format that is read and parsed by wmiiwm. These could be options for wmii-4 though. For 3.5 I definitely don't want to change the well-tested current concept. Another approach would need much design and many iterations. > 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).) There I agree fully. Denis
pgpsA8cz4YJci.pgp
Description: PGP signature
