Re: [STUMP] Flipping heads in group to groups in head!

[Lionel Flandrin]

On Wed, May 25, 2011 at 12:55:09AM +0400, Michael Raskin wrote:
> <address@hidden>
> <address@hidden>)
> Mime-Version: 1.0
> Content-type: text/plain; charset="UTF-8"
[...]
> >Well, I must say that I too have found many workarounds that end up
> >making my dual-head experience pretty smooth and I don't really miss
> >independent heads so much anymore.
> 
> With tags I try to have at least a semblance of some conceptual system,
> not a mere workaround. Whether I succeed is another question.
> 
> >The problem is that I don't see anyone volunteering to make such a
> >drastic change to the stumpwm codebase. Sabbets or Male are the only
> >two contributors to the project that I've ever seen making such huge
> >modigications (Male, by the way, wrote most of the current
> >Xinerama/multi-head code, and it was no small chore).
> 
> Does it have to be a huge rewrite? I don't volunteer because it will not
> fit _my_ usage patterns that is well-served by tags; but tags allow to 
> have completely different experiences without being a lot of code - this
> change should probably be a smaller change.
> 
> >Maybe the morale is that the current behaviour is the Stumpwm Way and
> >such a fundamental change would belong to a whole new WM? After all,
> >stumpwm started as a rewrite of ratpoison, and I've seen several
> >people complain of a certain code rot in the stumpwm codebase. Maybe
> >it'd be simpler to just start a new WM, having learned of the
> >strengths and weaknesses of stumpwm. Of course then the question would
> >be: what language next? :)
> 
> Until we write next WM in the language that StumpWM becomes, we haven't
> succeeded in writing StumpWM in Common Lisp... 

Ah, fair enough :). However there are some other fields that would
benefit from a deep stumpwm re-engineering, to cite a few:

- The mode line: I don't use it myself but it seems it suffers from
  many limitations for some people (yourself included, it
  seems). Refresh rate, docked applications and icons come to mind.

- float groups: they've always been a second class citizen in the
  stumpwm world. The abstraction on top of tile-group is nice in
  principle, but when you try to implement some new group mechanics
  it's not very convenient and it's hard not to break something. If we
  were to write stumpwm anew, would we drop float altogether and focus
  on perfecting the tiling WM, or would we make some kind of a WM
  "framework" allowing for all kinds of management schemes? Or just
  allow exactly two distinct modes: float and tiling (I think dwm does
  that?)

- Builtin menus, messages, mode-line: we can't use antialiased fonts,
  we can't use pictures; maybe we could rely on some external library
  (Tk, GTK, Qt or whatever) to do that and not reinvent the wheel.

There are probably others, but these issues come up very often in
#stumpwm, and there's no satisfying quick workaround that don't
involve naughty hacks. You know what *could* warrant a full rewrite?
Porting Stumpwm to Wayland[1]. If it succeeds in superseding X11
(crossing fingers) we'll have to do it sooner or later and Wayland's
"clx" will likely bring its lot of changes.

Anyway, that's just my 2 cents,I won't bury our good old Stumpwm yet,
so happy hacking everyone!

[1] http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)
-- 
Lionel Flandrin

pgpOxP8dk0tVv.pgp
Description: PGP signature