The future of StumpWM

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

The future of StumpWM

David Bjergaard-2
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel


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

Re: The future of StumpWM

David Bjergaard
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 <[hidden email]> 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 <[hidden email]>
> 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
>     [hidden email]
>     https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>    
>
>
> _______________________________________________
> Stumpwm-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

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

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


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

Re: The future of StumpWM

Robert Taylor
In reply to this post by David Bjergaard
I agree with all of your goals (the ace-window / hydra stuff is really
exciting).  My only concern would be the toolkit and the work to
support Wayland.

Some thoughts:

* ESPECIALLY agreed on your vi comments.  Hillarious!

* Agreed on all of the Wayland comments in thread.   Hasn't it been
around for about 5 years (3 years since initial release) if not
longer?  It should take another 5 years before we really start to see
serious use of Wayland.

On the other hand, maybe that is just the right amount of time for us!

* You have summarized the vision for the 2.0 of StumpWM very well.

* My only concern would be with the use of a toolkit.  I am not sure
that getting font rendering to be a bit nicer outweighs the
co-depenency of a toolkit.  From what I can see, the only real option
is QT and that just seems gratuitous.

The only option that seems aesthetically pleasing is Mcclim, but, that
is not being maintained so that is not an option.

Does a window manager need a toolkit anyway?  I am not so sure.  They
way I visualized Stump development was basically what you described
except the Stump panel deal, Stump console and Stump help would be
ripped out and would instead become modules / standalone apps.
Stumpwm would be aware of them and know what to do if the apps were
started (help of course is just a single page app but could be expaned
upon, a panel app would be accommodated appropriately along the edges,
etc.).  Those that want those features would never have them taken
away, those that don't use them don't really need to even load them
(not that it is even an issue, just saying).

In addition, I was thinking about a generalized standalone helper app
that would draw an overlay over the monitors and let you draw / slice
the windows with your mouse.  The slices / deletes would simply be the
helper app sending Stump the commands that you could do manually
anyway.

The helper app would behave like the current ? menu, it would always
be hidden unless called for.  The helper app could be expanded to
include panel like funcionality (time, date, widgets for system
status, notifications, etc).  That way, the inevitable QT vs GTK vs
whatever debate can be modularized away from the window manager.  We
can keep on using the Window manager even if we don't like the choice
of toolkit.

In other words, I was visualising slimming Stumpwm down to JUST a
window manager as much as possible and push everything else out into
modules and standalone apps and leave the default rendering as it is
now.

I think that Stumpwm has managed to really grab the essence of what a
tiling wm should be, I think it should retain that essence.

* Lastly, your floating tiling thoughts are correct too.  There are
times where a floating window is useful and having a reasonably good
version of that in Stump would really help a lot of users.


David, my thanks for all of the work that you have done and the time
you have put into thinking about where to go next with the project.
Most of the time I REALLY hate where people take ideas (witness Gnome
and KDE), this time sanity prevails.

Above is a bit rambling, let me know if I am wrong on any assumption
or if I need to clarify part of my post.

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

Re: The future of StumpWM

J David Smith
Your point about fonts/toolkit/helper apps is good.

I will point out that some other projects (notably XMonad via contrib) do have XFT support. XMonad has a contrib module that depends on the X11-xft library. However, this seems like it'd be a strict dependency on X11 that would have to at least be disabled for Wayland.

Using helper apps seems a reasonable take on it. xmobar and i3bar are already excellent status bars / mode lines. They can be communicated with in any language, so it doesn't seem like there would be a tremendous need for that functionality to be baked into stump.

 - J David Smith

On Sat, Sep 5, 2015 at 6:39 PM, Robert Taylor <[hidden email]> wrote:
I agree with all of your goals (the ace-window / hydra stuff is really
exciting).  My only concern would be the toolkit and the work to
support Wayland.

Some thoughts:

* ESPECIALLY agreed on your vi comments.  Hillarious!

* Agreed on all of the Wayland comments in thread.   Hasn't it been
around for about 5 years (3 years since initial release) if not
longer?  It should take another 5 years before we really start to see
serious use of Wayland.

On the other hand, maybe that is just the right amount of time for us!

* You have summarized the vision for the 2.0 of StumpWM very well.

* My only concern would be with the use of a toolkit.  I am not sure
that getting font rendering to be a bit nicer outweighs the
co-depenency of a toolkit.  From what I can see, the only real option
is QT and that just seems gratuitous.

The only option that seems aesthetically pleasing is Mcclim, but, that
is not being maintained so that is not an option.

Does a window manager need a toolkit anyway?  I am not so sure.  They
way I visualized Stump development was basically what you described
except the Stump panel deal, Stump console and Stump help would be
ripped out and would instead become modules / standalone apps.
Stumpwm would be aware of them and know what to do if the apps were
started (help of course is just a single page app but could be expaned
upon, a panel app would be accommodated appropriately along the edges,
etc.).  Those that want those features would never have them taken
away, those that don't use them don't really need to even load them
(not that it is even an issue, just saying).

In addition, I was thinking about a generalized standalone helper app
that would draw an overlay over the monitors and let you draw / slice
the windows with your mouse.  The slices / deletes would simply be the
helper app sending Stump the commands that you could do manually
anyway.

The helper app would behave like the current ? menu, it would always
be hidden unless called for.  The helper app could be expanded to
include panel like funcionality (time, date, widgets for system
status, notifications, etc).  That way, the inevitable QT vs GTK vs
whatever debate can be modularized away from the window manager.  We
can keep on using the Window manager even if we don't like the choice
of toolkit.

In other words, I was visualising slimming Stumpwm down to JUST a
window manager as much as possible and push everything else out into
modules and standalone apps and leave the default rendering as it is
now.

I think that Stumpwm has managed to really grab the essence of what a
tiling wm should be, I think it should retain that essence.

* Lastly, your floating tiling thoughts are correct too.  There are
times where a floating window is useful and having a reasonably good
version of that in Stump would really help a lot of users.


David, my thanks for all of the work that you have done and the time
you have put into thinking about where to go next with the project.
Most of the time I REALLY hate where people take ideas (witness Gnome
and KDE), this time sanity prevails.

Above is a bit rambling, let me know if I am wrong on any assumption
or if I need to clarify part of my post.

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


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

Re: The future of StumpWM

Robert Taylor
Makes sense and that would be a reasonable compromise.

Robert

On 9/5/15, J David Smith <[hidden email]> wrote:

> Your point about fonts/toolkit/helper apps is good.
>
> I will point out that some other projects (notably XMonad via contrib) do
> have XFT support. XMonad has a contrib module that depends on the X11-xft
> library. However, this seems like it'd be a strict dependency on X11 that
> would have to at least be disabled for Wayland.
>
> Using helper apps seems a reasonable take on it. xmobar and i3bar are
> already excellent status bars / mode lines. They can be communicated with
> in any language, so it doesn't seem like there would be a tremendous need
> for that functionality to be baked into stump.
>
>  - J David Smith
>

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