Re: [STUMP] The future of StumpWM

[J David Smith]

Re: other WMs moving to Wayland. The answer appears to be: not much.

XMonad had a GSoC application that does not appear to have panned out (due to lack of mentorship). i3 won't have any anytime soon (but does have an alternative implementation or two). There are a few 'inspired by dwm' wayland TWMs floating around.

It looks like there are a couple of compositor libraries (wlc and swc appear to be the most mature) that we could bind to with FFI.

On the whole it looks a lot like it did 8 months ago when I was hacking on Wayland stuff: reimplementations. Existing implementations were built for X and nobody seems interested in porting most of it (except in the case of XMonad maybe).

Enough about Wayland, though. Back to the original topic: The Future of StumpWM

On Tue, Aug 25, 2015 at 6:22 PM, David Bjergaard <address@hidden> wrote:

Hi David,

This is very reassuring as it confirms my somewhat foggy take on the whole
matter.  The clx manual [1] hasn't been modified since 1997, and a lot of the
entries on the CLiki relating to clx grew out of development of stumpwm
cl-truetype and some links to clx documentation.

I'm not sure how wayland will fit into CL going forward.  What I would see as
most likely is that FFI bindings would be written, and if there was incentive
for a company to do a native Wayland implementation there would be clw
equivalent of clx.  I agree with all of your points.  I too have played with the
idea of using Racket or Chicken scheme, but ultimately have decided (completely
biased of course) that CL is probably the best tool for the job.  (If no other
reason than SLIME is unbeatable)

Thinking out loud: I wonder how the other off-brand window managers are
preparing for wayland (xmonad, awesome)? Even if we didn't make something that
was easily wayland compatible, there is plenty of room for improving StumpWMs
internal window management (unit tests please!).

Cheers,

    David

[1] https://common-lisp.net/project/cmucl/doc/clx/

J David Smith <address@hidden> writes:

> 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
>
>
>
> _______________________________________________
> Stumpwm-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel