Re: [STUMP] The future of StumpWM

[J David Smith]

I have done some work on building a wayland TWM in Racket and one of the problems that I forsee for Stump2 is that Wayland operates totally differently.

For those that aren't familiar with Wayland's structure: Wayland is a protocol, not a library. This unfortunately means that we will need a compositor. There are some C compositors floating around that have decent bindings for FFI, but no CL ones (to my knowledge). There are presently (to my knowledge) no implementations of the Wayland protocol for CL. I was working on one for Racket but got bogged down in the details and let the project stagnate. If we want to support *both* Wayland and X, then we will absolutely need an abstraction layer between the display layer and the management layer. 

This will require more work, but it also presents the opportunity to have a more sane (from a user standpoint) API for managing which windows are displayed where. We could, for example, start by deciding what the TWM primitive operations are and then base the abstraction layer on *those* instead of on what the display library provides as primitives.

To circle around to what I originally wanted to say: the current codebase would have to be *very* heavily refactored to support Wayland. If we *ever* want Wayland support (and, IMO, that is a desirable thing to have), then the tear-down and rebuild approach that David is suggesting is the best path in my opinion (for whatever my opinion counts as...).

I'm also super excited at the possibility of having a WM with ace-window and hydra.

 - J David Smith

P.S. I know I mention Racket several times. I'm not suggesting that Stump2 be in Racket (although that would be cool...). Stump is in CL, it makes sense for Stump2 to be in CL.

On Tue, Aug 25, 2015 at 5:13 AM, David Bjergaard <address@hidden> wrote:

Hi Guys,

For those following along I sent a separate email whose content didn't match the
subject line. In order to have a better discussion I'm splitting out the parts
that effect the greater StumpWM community.  From the other thread I proposed the
question putting StumpWM in maintenance mode:
> In either case, stumpwm would be done.  Whats the future of tiling window
> managers written in lisp? Well, I would like to take a stab at writing my own,
> modernizing things in the process.  And of course stealing as much from stumpwm
> as possible.

> A lot of stumpwm was informed by ratpoison, and further by constraints of clx.
> It would be nice to implement something that had enough layers of abstraction
> that the window system didn't matter as much.  Specifically something that could
> change from clx to whatever wayland does.  Another goal would be to use whatever
> available libraries there are for gui/input stuff so that unicode and ttf fonts
> could be used from the start.  This would introduce dependencies which is
> something stumpwm has eschewed, but something a future window manager should
> (IMHO) embrace.
Scott Jaderholm wrote:
> I was very surprised by the suggestion of "no further development" and
> "In either case, stumpwm would be done." If that's the direction you
> want to go perhaps a separate thread should be created for discussing
> that since I'm not particularly interested in utf8 input but I am
> definitely interested in that topic and I suspect there are others
> that feel similarly who might have skipped this thread.

> I'm very grateful for all the work you've done as the
> maintainer/developer. I can understand if you're not interested in
> further development but only bug fixes. I assume by freeze you mean of
> features others implement not just that you don't personally plan to
> implement new features. Perhaps though it would be still worthwhile to
> have people submitting pull requests for new features and just accept
> them to an unstable branch or make it clear that you're waiting for a
> new maintainer to step up for new features to be merged, and see if
> anyone wants to take over that part of stumpwm. It would be a shame
> for people to have the idea that stumpwm is finished or to miss out on
> receiving pull requests if in a year someone steps up to continue
> development. I think making the freeze conditional (on a new
> maintainer) or temporary is better than declaring the project is done.

> I agree a new wm (or major revision of stumpwm) with a layer of
> separation from the underlying windowing system is very exciting and I
> look forward to it. I can totally understand if you want to use more
> of your personal time in that area. But let's not kill enthusiasm for
> improving the project we currently have for something that may or may
> not exist in the future.

So, let me flesh out my ideas a bit more than say "Hey guys, well, StumpWM is
done, long live StumpWM":

StumpWM has some really great features (the .stumpwmrc, the module system, the
manual built from doc-strings, the build system, and the tiling aspect of window
management).  It also has some half-baked stuff (floating windows and float
groups).

While the code base is relatively well structured, it is monolithic in the sense
that other projects don't benefit from some of the innovations StumpWM has made
(keysyms and kbd related stuff, the gui related things etc) and StumpWM doesn't
benefit from progress made externally.  It also maintains internal copies of
cl-fad (granted this is a stable package) rather than relying on an external
version.  All of this results in StumpWM occupying an interesting bubble which
is relatively insulated from the outside world.

There are even projects that are moving from xlib to xcb at the clx level, which
StumpWM won't see since it works with clx.

With all that said, I find it difficult to extend and hack on the codebase
itself.  There is no testing system and you never know when your going to change
something and have it affect something completely different (9 times out of 10
you'll revert a bug or cause a new one in my experience).  This is as much a
function of StumpWM's design as it is all the duct-tape code used to work around
bugs and issues people have reported/patched over the years.

As I write, I'm beginning to realize what I'm ultimately proposing is to jump
from StumpWM 1.0 to 2.0 by tearing it down and re-assembling it with the
following design goals:
- Use an external gui toolkit (with support for anti aliased fonts, its the 21st
  century!)
- Unit tests, every function gets a test, and every PR must pass these tests. If
  a commit adds a new function, it adds a new test.  This is a hard rule.
- Tiling windows based around emacs's ace-window [1] and a common lisp port of
  hydras two of the most innovative things to come out of the (e)lisp community
  in a long time
- Floating/tiling in one work space baked in with the ability to resize tiles
  with the mouse.  It drives me nuts that if I want to split in a more
  complicated way that half I have to enter a special mode with heretical vim
  key bindings! And its painstakingly slow!
- A window model that is abstract enough to allow multiple backends (wayland,
  mir, whatever replaces clx/x11).  This last one is debatable since you
  interact with clx in the lisp ecosystem and that's been shelf-stable since the
  mid 90s as far as I can tell.  On the other hand, if you build the right
  abstractions, there's no reason someone can't write a MacOS backend or a
  Windows backend (clearly spoken from someone who has never touched either)

What will happen to StumpWM while all this is happening? Well, I'm happy to keep
maintaining it, incorporating pull requests, adding modules, and keeping it
building on the latest sbcl/clisp/ccl images.  Of course as bugs are uncovered
and fixed there would be periodic bug fix releases, but I don't see myself doing
significant development on new features in the 1.0 line.

If I'm a little frank: I feel obligated to address the issues that have been
reported on the issue tracker before I work on new features.  Some of the issues
I can't reproduce, and others stem from problems in the codebase I don't have
the expertise handle.  The result is that I usually find something else to work
on when I want to hack code which isn't fair to StumpWM.

Please let me know what you guys think.

Sincerely,

    David

[1] http://oremacs.com/2015/05/13/ace-window-0.9.0/

_______________________________________________
Stumpwm-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel