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 <https://faq.i3wm.org/question/687/i3-support-for-wayland/> (but does have an alternative implementation <http://swaywm.org/> or two). There are a few 'inspired by dwm' wayland TWMs floating around.
It looks like there are a couple of compositor libraries (wlc <https://github.com/Cloudef/wlc> and swc <https://github.com/michaelforney/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 <dbjerga...@gmail.com> 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 <emall...@archlinux.us> 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 <davi...@duke.edu> > > 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 > > Stumpwm-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel > > > > > > > > _______________________________________________ > > Stumpwm-devel mailing list > > Stumpwm-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel >
_______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
