Re: [wmii] Preparations for 3.5

On Tue, 31 Oct 2006 12:16:18 +0100
"Stefan Tibus" <sjti_AT_gmx.net> 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