Re: [wmii] Preparations for 3.5

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