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.

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.

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.


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...)

bugs:
  o DnD with gtk does not work
  o starting in the NULL view despite of rules that say otherwise
  o there are some seldom crashes with windows that misbehave badly,
    but that is shouldn't happen in nature anyway, so this is low
    priority.

general code cleanups and refactoring, and finishing some stuff pending
from Kris' and Anselm's changes.

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.

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)

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

uriel

Reply via email to