Hi All,
I've started a separate repo on the github's stumpwm organization named
paulownia. This is the code-name I've chosen for StumpWM 2.0.0. The design
goals etc are listed there. In short:
1. Use as much of stumpwm as possible
2. Separate out parts of stumpwm into their own packages (distributed via
quicklisp)
3. Project out clx/xlib parts of the code so that code is less coupled to the
underlying display server (eye towards wayland, mir, dare I say
MacOS/Windows)
The repo has a CI set up to run test with prove and roswell, this already
simplifies the build process for various lisps since roswell provides a uniform
interface for building images.
So what I need input from this list is on:
1. What's broken (in your mind)?
2. What can be moved into its own package (cl-xkeysym has already been made
external) or can depend on exernal packages?
3. What are the clear conceptual breaks in the stumpwm ecosystem?
4. What should be removed or reworked completely?
Let me answer with my opinions for each one:
1. Internationalized input. This means handling non-ascii characters in dialog
boxes and responding to them being bound to keys.
2. Modeline, keysym (in fact all the the code "(kbd ...)" touches),
debugging/logging can be moved externally, time.lisp, timers in stumpwm.lisp,
module.lisp, the info manual can be moved to external programs
3. I see this falling into three categories:
- Backend :: anything that interacts with clx or the xlib package
- Core :: the parts that define the window model, and primatives, kbd stuff
- Gui :: the stuff that draws the mode-line, takes user input and echos it
back, and draws the help window/welcome screen
I would like to restructure it so that you could swap out one gui toolkit for
another. Specifically, if someone wrote one that used cl-gtk-cffi and another
that used qtools, they should still work with the rest of stumpwm. The same
goes for the backend parts of the code. For now and the foreseeable future, the
only backend we'll have to support is clx since wayland and mir have X11 servers
implemented in them.
4. I think the support for floats should be dropped initially and re-worked in a
different way. If we're going to have floats, I envision being able to
toggle windows between being tiled and floating on top of the tiles. In a
sense making the float group sit on top of the tiled group and being able to
move windows between the two as needed. This would ideally be done
automagically for dialog boxes that often are placed in awkward positions
when tiled.
I'm sure some of what I plan to do will be controversial or will break someone's
preferred method of interacting with stumpwm. If that's the case, please
continue to use the 1.0 line. If something is easy to merge back to 1.0 and
doesn't change the user experience I will. I will also continue to accept
contrib modules and bug fixes for stumpwm 1.0, so it will continue to be
maintained.
Paulownia is an experiment to see if I can re-write stumpwm they way I want it
while fixing some of it warts along the way. I don't know how far I'll get or
if it will be a success, but it should be an adventure and I'll be a better
maintainer after auditing the current stumpwm codebase in detail.
Cheers,
Dave
_______________________________________________
Stumpwm-devel mailing list
Stumpwm-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
