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
