Re: [wmii] Preparations for 3.5

On Tue, 31 Oct 2006 07:18:56 +0100
Uriel <lost.goblin_AT_gmail.com> wrote:

> > 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.
>
> What the hell is "relaxation"? Either way, apps that request
> increment handling should work, inc handling is an abomination, but
> it is part of X, and apps depend on it. At some point someone (JG?)
> was planning the most obvious solution: after sizes are assigned with
> inc-handling constraints in mind, stack all apps towards the end of
> the window, whatever space is left is distributed between the apps if
> it is enough to add an extra increment until nothing is left. I don't
> see why this is a problem at all.

What dwm does is exactly what I wanted for wmii -- it still obeys the
incrementation wishes of the apps by shrinking the client to fit into
the frame. All of this relaxation stuff is way too complex for the
little benefit it gives. »Traditional« terms will still work, and the
gaps will be gone. Looks fine to me.

> > 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.
>
> The current focus model is completely broken(as always), I think JG
> had an idea about how to fix it, but I forgot, maybe check mailing
> list or irc archives.

I'd love to hear suggestions. The list archives didn't reveal anything
revolutionary. The primary problems I see now are mostly about the
mouse.

> > addressing clients by session-unique IDs
> > this is a somewhat more intricate issue. There have already been
> > suggestions and patches, and it would be very good if some people
> > could report about their efforts and what they thought of. There
> > was a discussion about identifying windows by their X window id,
> > which I think would be a usable solution. I hope to have the fs
> > settled more or less for the release, so that extensions and
> > scripts for 3.5 wouldn't need a rewrite for wmii-4 (or at least not
> > too much).
>
> I'm very skeptical about how much sense this makes, there are tons of
> stuff in the fs interface that need to be completely redone, so
> worrying about backwards compat between 4.0 and 3.5 is quite
> pointless.

It is definitely a bad thing that users have to screw all of their nice
scripts and configuration for every release, but very likely you are
right. Let's put that back for wmii-4.

> > column/frame resizing
> > visual aids when resizing frames and columns don't correspond to
> > reality.
>
> This all comes from the whole column model implementation being
> fundamentally broken. There are tons of hacks, like col0 being the
> float layer and other crap. Once more JG had plans for the obvious
> solutions(details should be in archives too), which was along the
> lines of: managed windows have x position and height, cols have width
> and y poss. You can't resize managed windows horizontally, you only
> resize columns. I think JG had even worked out the datastructures for
> floating layer stuff and such, but really, this should all be rather
> trivial. (Makes you wonder, like with everything else, why the hell it
> is so fucked up...)

I don't like the idea of splitting the action of resizing frames into
resizing horizontally and resizing vertically. How it is handled now
(from a design POV) is fine with me; the internals could definitely be
nicer though.

> > some changes on the wmiirc. Especially the fact that you have
> > duplicated shortcut definitions is not ideal.
>
> JG and I had completely reworked the design for the keybindings
> interface and wmiirc, the new design was simpler, more elegant, more
> extensible and most importantly, it was not completely braindamaged
> like the current one. Details as usual in archives and logs.

This idea is definitely interesting, but would be quite radical. I'd
like to get 3.5 out asap, so this I'd put back as well.

> > It is also needed to update the documentation to at least reflect
> > the new fs. Porting the old wiki to the new format is not of topmost
> > priority either, since 3.5 is only an intermediary release, but also
> > because the new taggi doesn't look feature-stable yet.
> Oh, really? Who would have thought, just wait for having to move to
> yet another wiki next week, what a waste of time. Lets just forget
> docs until 4.0 and feature completely. (If someone wants to work on it
> in the meantime, good for them)

A release without documentation is an absolute no-go. There's too much
old documentation out there that will confuse people if there are no
updated docs.

> Also lets not forget editable tag bars and plumbing...

This is definitely not trivial to do correctly. I didn't plan to have
editable tag bars in 3.5. At least being able to select the text would
be useful, but again, let's wait with that for post-3.5. Then we'll
have some solid code base to work with.

Denis