Re: [wmii] answers to IRC comments

On Fri, May 12, 2006 at 12:54:17PM +0200, Denis Grelich wrote:
> On Fri, 12 May 2006 09:39:59 +0200
> "Anselm R. Garbe" <garbeam_AT_wmii.de> wrote:
> > > 23:13 < uriel> - Allow resize by drag on borders
> > Get used to the current way. This is not planned anymore. Focussing a 2px
> > border with the pointer is much harder, than pressing Alt and performing a
> > resize or move.
> Here, I agree to uriel. Having to press MOD is very
> inconvenient, and getting that border is not as hard as it is
> said to be. (in other wm's it works?!) It has nothing to do
> with getting used to it, as—at least to me this happens quite
> often—there just are a lot of those situations where you miss
> that, especially in floating mode. Yes, I /am/ used to
> mod-drag, and I like it a lot (I hate gnome for not supporting
> that, as I fail miserably every time sitting before my
> brother's desktop), but it is somthing that it is missing in
> wmii.
> Also, /moving/ by mouse-only should be there, which is even
> more important imho. There's absolutely no need to hit a small
> border, and as it is impossible to turn of window bars at all,
> they should be good for interaction. Don't know if it would be
> better to use all of the bar for tagbars, or if it would be
> better to just use the tag's label, as I never worked with
> tagbars or something similar. But I suppose using only the
> tag's label and using the rest of the bar to move the window
> would be a very good compromise.
Well, we can talk about this for wmii-4. If there are many
people missing this feature, it might be worth to be readded
again, with some exceptions for tagbars.

> This is also linked to the fact that empty views are
> impossible. They would not only be convenient when windows are
> distroyed (mostly by accident or when dialogue boxes and
> windows are opening one after another–like it is the case with
> splash screens or opening dialogues. And you can't consider
> this always broken behaviour, as it is often justified!), but
> also it is highly convenient for opening windows with a tag
> without writing a rule for that. IIRC the only reason to not
> allow them was a technical one. And, frankly speaking, those
> »rules« are completely orthogonal to the idea of dynamic
> window management, as they need /a lot/ of predefinition and
> force me to quite a fixed layout. (I'm sure there are better
> options for that, but this needs LOTS of more discussion and a
> giant overall concept, and is here totally out of place)
Allowing empty views (at least 1 per time) would at least need
special handling for the nil view, which is the internal
fallback. /def/rules defines the default tag, but without
auto-destroying empty views until a select, one has to at least
auto-destroy the nil view if it is empty, otherwise you always
end up in that view on startup.
Might be a better way for wmii-4. I can agree with the need for
more predictability with view destroying.

> > > 02:27 < uriel> about keybindings: I refuse to change the defaults, if the
> > > defaults suck so much that are unusable, they should not be the defaults
> > > 02:27 < uriel> 2) the problem is not to have to type it two times, the problem
> > > is that you have two lists of items to keep in sync, which can create all kinds
> > > of hard-to-debug errors
> > > 02:28 < uriel> it is just too error-prone
> >
> > I'm not satisfied with the way it is, but after having considered all kinds of
> > alternatives, it is the least sucking way so far, in wmiirc. See the mailing
> > list archives for details.
> Here, again, I totally agree with uriel. The sync errors /did/
> and /do/ occur, and they /are/ hard to debug. To many, many
> peolpe. I am convinced that the current way is one of the
> worse solutios. But this discussion has already be held in
> another thread, and without a working alternative to show off,
> it is unneccessary to talk about that any further.
Exactly. I haven't seen yet a better way. The awk-based approach
with an associative array looked quite good, though it was
rather cryptic. An m4-based approach might be better which
creates a temporary sh-script instead, but I'm not sure at all.
(I also dunno if m4 is installed on every box where sh and awk is
present).
The main problem here is, that shortcuts have to be grabbed on a
window (in our case on the root window OR (this is done in some
other WMs on all frame/client windows) to being reported by X.
We cannot grab the keyboard and send a synthetic keypress event
for each keypress (also because many clients won't accept this).
The way is as it is, the only more-cryptic and less flexible
alternative which has been showed off so far was the awk-based
approach. If anyone has a nice idea and shows up something
better, I'm the last one who won't accept it.

> I think discussions are stiffled too often. It is good that
> they are held at all (which is really not a matter of course),
> but they are too often ended after some shallow stirring.
This often depends of the people involved in discussion. As
example for Uriel, he rarely argues, he tells his opinion too
often without giving any reasons. And nearly always I point this
out, he stops conversation due the lack of convincing arguments...
It would be much easier to accept critics about the software, if
it is based on reasons.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361