Stumpwm in 1 year, 5 years and 10 years

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Stumpwm in 1 year, 5 years and 10 years

David Bjergaard
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.

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

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. 

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

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stumpwm in 1 year, 5 years and 10 years

Lionel Flandrin-4
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

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Stumpwm in 1 year, 5 years and 10 years

Jason F. McBrayer
In reply to this post by David Bjergaard

David Bjergaard writes:
<Vision for Stumpwm on Wayland and beyond>

First, thank you for all the work you've done.

I'm actually pretty excited about this. I've tried many tiling window
managers, and Stumpwm is the only one I haven't "bounced off of". I
can't run it currently because my desktop environment is on Wayland, and
the only thing that really works properly on Wayland right now is Gnome
(which I *like*, it generally stays out of your way).

There's currently one tiling compositor for Wayland, which is Sway, a
port of i3wm. It's good, probably, but has some lacking features, like
syncing clipboards between Wayland and X, which I can't live without.
Also, I have trouble understanding its nested window layouts.

The hard thing about a transition to Wayland will be the fact that a
Wayland compositor has to do a lot more than an X11 window manager.
There are a lot of things that helper apps could do under X that can
only be done by the compositor under Wayland. There are a few libraries
to help doing this (swc, wlc, ewlc). But I don't think any of them work
all that well?

Oh, there are CL bindings for libwayland
(https://github.com/malcolmstill/cl-wayland). So that would probably be
the way forward. It's currently used to implement an FVWM-like
compositor.

--
+----------------------------------------------------------------+
| Jason F. McBrayer                         [hidden email]  |
| The scalloped tatters of the King in Yellow must hide Yhtill   |
| forever.                    R.W. Chambers _The King in Yellow_ |

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Stumpwm in 1 year, 5 years and 10 years

Javier Olaechea
David,

I agree with your assessment that CLX is abandon-ware, but it is even worse than that. It has code from the 70's (with no version control history beyond the early 2000's IIRC). It has a lot of code written with performance considerations that are no longer needed. Case in point: def-clx-class. Personally I've given up on CLX at this point. I've been the past month I've been working on XCB protocol implementation, that is what I intend to focus the next year. I hope to have something to show in 2-3 months. The Guile[0] and Emacs Lisp[1] xcb bindings are a good reference.

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

For the mid-term, 5ys, this is a direction would like to follow. factoring out into systems non-ui code which could be reused elsewhere. For ease of distribution we could keep the systems in the same repo. For example a completion backend so we can improve our completing-read and implement a reverse search history in our prompts. (I'm thinking something along the lines of helm-sources). Incorporate lineedit[2] or something similar to our input prompt. Having a C-R. And Ultimately having StumpWM be an 'Emacs for the Desktop', or at least blur the lines. In that line the new feature of interactive-keymaps by Caio Oliveira are a great addition! Maybe work on an help system along the lines of the Documentation Examiner of old[3].

Regarding Wayland, I'm sure Linux will move towards it, but will *BSDs? From what I remember when reading the SPEC, the Wayland protocol is centered around shared-memory-pools, which makes our network based approach, impossible. I understand this is due to OpenGL and that even today the way OpenGL drivers work is by writing directly to the memory instead of having the Server draw for them. Bu for regular desktop usage, I rather have no FFI code. Maybe a solution that could work would be an ECL based compositor and a CL RPC to control it?

On Fri, Jul 28, 2017 at 11:37 AM, Jason McBrayer <[hidden email]> wrote:

David Bjergaard writes:
<Vision for Stumpwm on Wayland and beyond>

First, thank you for all the work you've done.

I'm actually pretty excited about this. I've tried many tiling window
managers, and Stumpwm is the only one I haven't "bounced off of". I
can't run it currently because my desktop environment is on Wayland, and
the only thing that really works properly on Wayland right now is Gnome
(which I *like*, it generally stays out of your way).

There's currently one tiling compositor for Wayland, which is Sway, a
port of i3wm. It's good, probably, but has some lacking features, like
syncing clipboards between Wayland and X, which I can't live without.
Also, I have trouble understanding its nested window layouts.

The hard thing about a transition to Wayland will be the fact that a
Wayland compositor has to do a lot more than an X11 window manager.
There are a lot of things that helper apps could do under X that can
only be done by the compositor under Wayland. There are a few libraries
to help doing this (swc, wlc, ewlc). But I don't think any of them work
all that well?

Oh, there are CL bindings for libwayland
(https://github.com/malcolmstill/cl-wayland). So that would probably be
the way forward. It's currently used to implement an FVWM-like
compositor.

--
+----------------------------------------------------------------+
| Jason F. McBrayer                         [hidden email]  |
| The scalloped tatters of the King in Yellow must hide Yhtill   |
| forever.                    R.W. Chambers _The King in Yellow_ |

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel



--
"I object to doing things that computers can do." — Olin Shivers

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel