Re: [STUMP] Stumpwm in 1 year, 5 years and 10 years

[Lionel Flandrin]

On Thu, Jul 27, 2017 at 09:58:32PM -0400, David Bjergaard wrote:
> Hi All,
> 
> It has been a pleasure to serve as StumpWM's maintainer for the past three
> years.  During my time here we've released two new versions, revamped the
> module system, added multithreaded i/o channels, and fixed countless bugs,
> crashes, and corner cases.

Than you for your work, it's greatly appreciated!

> StumpWM as a project began in 2003 and reached a fairly stable state around
> 2008.  The Lisp ecosystem has changed significantly in that time, and our
> current policy of only supporting SBCL stems from a broader attempt to
> consolidate the community around one distribution.  This will hopefully
> make it easier for new members to make meaningful contributions without
> being overwhelmed before getting in the door.
> 
> Since the project has been around for over a decade, I think it is useful
> to take a minute to look at where I see things going in the next 1, 5, and
> 10 years.
> 
> StumpWM has fairly minimal dependencies, but the most important is CLX.  At
> this point CLX is effectively abandonware and is being kept alive through a
> fork on github. CLX was written as a native implementation of X11 in Common
> Lisp in the early 90's.  Since it is independent of Xlib, it hasn't seen
> some of the modernization it otherwise would have.
> 
> Specifically, it is missing support for multibyte characters (essential for
> localizing StumpWM outside of the traditional ASCII character set) and it
> is missing support for XInput events.  The latter means that certain things
> are ignored (scrolling events and multitouch) when StumpWM is running.  In
> the next year, I would like to tackle adding XInput to CLX for the benefit
> of StumpWM. It would also be great if we could finish the "make everything
> a package" approach to organizing a modern Lisp project.  This would allow
> us to carve out bits of the StumpWM ecosystem for others to use.  I would
> also like to revisit some code I wrote to get anti-aliased/OpenType fonts
> running efficiently.
> 
> We have some really great contributions coming through! I would like to
> thank @jorams and @PuercoPop for doing an amazing job with assessing and
> code reviewing some of the larger PRs that have come down the pipe
> recently.  I've gone through quite a few life changes recently, and I
> haven't been as present with the project as I would like.  @jorams and
> @PuercoPop have kept up the pace and prevented PRs from languishing in the
> queue.
> 
> In 5 years, I expect that Wayland will be the new way to interact with a
> graphical environment.  This will mean a few things:
> - a lisp solution will rely on bindings through a foreign function
> interface. This will constrain our ability to stay "lispy" and will require
> adopting the paradigm of the underlying library.

I don't know much about Wayland and I know there's no such thing as a
perfect abstraction but how do you think it would impact StumpWM's
"lispyness"? In the end it's always about displaying windows on the
screen, is Wayland that much different from X that the architecture of
the WM would have to be remade from the ground up?

I think in a perfect world we'd want to have all X/Wayland specific
code in an abstract generic interface that would be used by the window
managing code. That might even let us add support for other systems
(maybe even Mac/Windows/...?) but of course it's easier said than
done. I know that currently Xlib thoroughly permeates the StumpWM
codebase so no matter what it won't be a cheap change to implement.

Are there features or limitations of Wayland that would be
StumpWM-unfriendly?

> - many of the bedrock pieces of stumpwm will need to be re-written
> - X11 support will likely remain strong as StumpWM won't be the only legacy
> application in production
> - As the line between tablet and laptop is continued to blur, a modern
> window manager will be expected to behave well with touch.  This presents
> challenges for a tiling window manager, but StumpWM can innovate here.

For me the whole point of a tiling WM is to be able to do everything
without having to reach for the mouse (after all StumpWM is an
offspring of Ratpoison...). IMO touch is just a "worse mouse" in terms
of usability. It's even slower than the mouse (you have to move your
way from the keyboard all the way to the screen) and it's less
precise.

It's great for smartphones and tablet when you want to use a small
device without a physical keyboard but I'm not sure what StumpWM would
bring in this context. And when I *do* have a keyboard available I
can't really imagine that I would start motioning at the screen just
for fun.

Not that I'm against adding support for touch interactions to StumpWM,
it's just that for me at least it's extremely minor and not that
important so I was suprised to see it feature prominently in your
list.

> In 10 years, things get a little hazier.  It is likely that Wayland will
> have the dominance that X11 has now and that the latest display paradigm
> will be on the horizon.  I hope that as long as I am using a Linux desktop,
> I will be able to run StumpWM.  I expect that if Wayland takes over, X11
> support will be in a legacy state at best, and non-existent at worst.  I
> hope that StumpWM will have the development manpower to overcome these
> changes, and will have positioned itself to adapt to a hybrid
> touch-screen/keyboard interface.

I'm sure as a community we'll manage to get StumpWM running on
whatever happens to replace X11 in the future. If two years from now
it turns out that I can't run Stump on my desktop that would be a
massive problem for me and I'm sure I'm not the only one in this
situation. I have about 10 years worth of muscle memory invested in
StumpWM, I won't give up on it easily!

I'm sure we'll figure something out, one way or an other.

> Let me know what you guys think of this vision, and if you have any big
> ideas about where you would like to see the project in the near, medium,
> and distant futures!
> 
> Sincerely,
> 
> David

Thank you again for your work and your dedication!

-- 
Lionel Flandrin

signature.asc
Description: PGP signature