I didn't plan on ranting either, but I got started and kept enjoying it. It's satisfying to put ideas into words, and we don't really have explicit spaces where these abstract discussions can belong. There is a subject here I don't really have a name for, like a frontier whose edge sits between all of us. Imposing, yet just out of reach. I guess I should really start that blog I've been procrastinating...
In the mean time, here's some more rant:
A framework is not quite what I want. The pieces are tied too closely together. AwesomeWM is great, and so is xmomad, but they both suffer from difficult configuration. Configuration needs to be trivial to approach, but not limited in extensibility. I settled on i3 because I prefer the underlying structure and don't find much to be missing. The i3 devs guessed a lot right about what I would want in a tiling wm. Even so, I do get excited at the idea of configuring Xmonad to perfection. I'm just not that good at Haskell yet.
The exciting thing about window managers is the way they fit into the Xorg ecosystem. They are decoupled enough both from the software they window, and from the xserver they draw to, that you can swap out the entire window manager process - even in a running xsession - and everything will continue working. That's a quality I want in the modules I was talking about.
Emacs gets close, but the approach is still pretty confusing. There is plenty of documentation, but you have to learn too much context to get started.
And most of that context is the way that different functionalities are tangled together. The power of lisp is that you can pull on a thread and stretch it - without breaking it away from other components - then tie your new functionality in; but you have to know where to pull, and any update to Emacs or its packages might change the pattern such that you have to pull on new threads.
That's the point I am struggling to articulate most. Modules need to exist in a neat predictable data structure. The substance of what a module is has to be self contained. As soon as a module cares about what's inside another module, that can go both ways and create a circular dependency.
But silos have their own limitations. Neither window managers nor Xorg know how to do display scaling. That put the onus on every GUI software package, which didn't go over well. Some sort of introspection is really useful, which is why Wayland moved the compositor into the window manager.
But Wayland made a fatal flaw: They started without a framework. They made the Weston reference compositor, and just waited for people to copy or fork it. That's begging for repeated (and incomplete) work, and incompatibility. Eventually someone made the wlroots library to encapsulate that repeated work.
Having a library means changes can be made that propagate up. But the exciting thing about configurable software is the ability to put changes on the top that propagate down.
There are a few places where I've seen that kind of bi-directional introspection at work. One is Photoshop layers. Layers can be stacked above or below each other. A layer's pixels can be added, subtracted, multiplied, etc. to the next. You can use a mask to stencil away parts of a layer. If we treat modules as layers, we can decide what order they are stacked, and what function "stacking" does.
Another place is Nix derivations. There are no variables in Nix, only constants. But constants can be overridden anywhere. That's a lot like drawing on a new layer. The trouble with Nix is that that is done with a pinch of pure-functional magic, and an embarrassing amount of boilerplate. As a user, I often find myself standing in the middle of the stack, unsure how to look up. And I'm not quite sure what's at the bottom, either. There's also not a clear consensus on how new derivations should be structured.
Something like NixOS on the text editor scale would be great. Most good text editors have some kind of package manager. I would love to take that to its extreme, and have every part of the editor be a package. All that's left is to decide what domain a package can encompass, and what data structure stacks them together.
In the mean time, here's some more rant:
A framework is not quite what I want. The pieces are tied too closely together. AwesomeWM is great, and so is xmomad, but they both suffer from difficult configuration. Configuration needs to be trivial to approach, but not limited in extensibility. I settled on i3 because I prefer the underlying structure and don't find much to be missing. The i3 devs guessed a lot right about what I would want in a tiling wm. Even so, I do get excited at the idea of configuring Xmonad to perfection. I'm just not that good at Haskell yet.
The exciting thing about window managers is the way they fit into the Xorg ecosystem. They are decoupled enough both from the software they window, and from the xserver they draw to, that you can swap out the entire window manager process - even in a running xsession - and everything will continue working. That's a quality I want in the modules I was talking about.
Emacs gets close, but the approach is still pretty confusing. There is plenty of documentation, but you have to learn too much context to get started.
And most of that context is the way that different functionalities are tangled together. The power of lisp is that you can pull on a thread and stretch it - without breaking it away from other components - then tie your new functionality in; but you have to know where to pull, and any update to Emacs or its packages might change the pattern such that you have to pull on new threads.
That's the point I am struggling to articulate most. Modules need to exist in a neat predictable data structure. The substance of what a module is has to be self contained. As soon as a module cares about what's inside another module, that can go both ways and create a circular dependency.
But silos have their own limitations. Neither window managers nor Xorg know how to do display scaling. That put the onus on every GUI software package, which didn't go over well. Some sort of introspection is really useful, which is why Wayland moved the compositor into the window manager.
But Wayland made a fatal flaw: They started without a framework. They made the Weston reference compositor, and just waited for people to copy or fork it. That's begging for repeated (and incomplete) work, and incompatibility. Eventually someone made the wlroots library to encapsulate that repeated work.
Having a library means changes can be made that propagate up. But the exciting thing about configurable software is the ability to put changes on the top that propagate down.
There are a few places where I've seen that kind of bi-directional introspection at work. One is Photoshop layers. Layers can be stacked above or below each other. A layer's pixels can be added, subtracted, multiplied, etc. to the next. You can use a mask to stencil away parts of a layer. If we treat modules as layers, we can decide what order they are stacked, and what function "stacking" does.
Another place is Nix derivations. There are no variables in Nix, only constants. But constants can be overridden anywhere. That's a lot like drawing on a new layer. The trouble with Nix is that that is done with a pinch of pure-functional magic, and an embarrassing amount of boilerplate. As a user, I often find myself standing in the middle of the stack, unsure how to look up. And I'm not quite sure what's at the bottom, either. There's also not a clear consensus on how new derivations should be structured.
Something like NixOS on the text editor scale would be great. Most good text editors have some kind of package manager. I would love to take that to its extreme, and have every part of the editor be a package. All that's left is to decide what domain a package can encompass, and what data structure stacks them together.