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? [0]: https://github.com/mwitmer/guile-xcb [1]: https://github.com/ch11ng/xelb [2]: https://github.com/nikodemus/linedit [3]: https://en.wikipedia.org/wiki/Symbolics_Document_Examiner On Fri, Jul 28, 2017 at 11:37 AM, Jason McBrayer <jmcb...@carcosa.net> 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 jmcb...@carcosa.net | > | The scalloped tatters of the King in Yellow must hide Yhtill | > | forever. R.W. Chambers _The King in Yellow_ | > > _______________________________________________ > Stumpwm-devel mailing list > Stumpwm-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel > -- "I object to doing things that computers can do." — Olin Shivers
_______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
