Boring stuff mostly today.

I did a lot of code cleanup and refactors, fixed a few bugs, but no huge changed code wise just yet.

I spent a lot of time planning the plugin system and inter process communication. I’ve typed up some of it and created mock files/directories here https://github.com/DJ-Laser/n16-shell/tree/design-docs

I settled on a design inspired by noctalia shell. Plugins will be shipped as folders containing a manifest (plugin.kdl), plugin binary, and resources (images, translation files, etc…)

Like noctalia, I plan to write a runtime to abstract over the communication protocol, but in rust instead of lua.
Each plugin will also be a single binary instead of one file per capability.

For the protocol itself, I looked at shared memory solutions, but deemed them to be unnecessary complexity and completely overkill for my scenario.

I will communicate over unix socket, passed to the plugin as argv[1] when spawning the plugin process.

The actual messaging will be a request-response protocol. Because I want to support long-running asynchronous operations, each request sent by the shell will have a message id, which can be used to send a response, fulfilling said message.

Also, messages can invalidate previous messages. The best example of this is a dynamic launcher provider.

If I’m making a provider that runs a web search on the query input, I will get lots of requests to update my matches list. If I have to run a (absurdly long for demonstration purposes) 5 second web search, my plugin will appear to freeze for a long time after the user types just a few characters. If instead it is allowed to cancel the web search early and not return results for an outdated query, the plugin will run much faster, only the normal 5 second delay after the last character, instead of 5*num_chars.

Major internals rewrite

I just completed a major rewrite of the internals.
Most significantly, each desktop shell component now has it’s own gui runtime. Previously, they were all managed by a single iced (the gui toolkit i use) runtime, but the need to separate state for each component and isolate keyboard/window events required lots of hacky code that messed with the runtime’s internals.
Also, the implementation of xdg-layer-shell (wayland protocol for making desktop shell components instead of regular windows) has an issue where window unfocus events aren’t handled properly between two windows in one iced runtime.

The switch to independent gui runtimes fixed a lot of the strange bugs I was having. I had learned to just avoid behaviors that caused them, but it should be a lot friendlier for new users now.

In anticipation for the plugin system, I rewrote the api for launcher providers to be more in line with the final API i envision.

Now, providers can dynamically create items to show the user based on the text entered. This allowed me to make the calculator feature a simple dynamic provider instead of a bespoke feature with lots of unique code.
It also opens up the opportunity for more kinds of providers in the future, such as a translator, web search, or file fuzzy finder.

I still have a lot to rewrite, but I want to approach the creation of the plugin and config system carefully, unlike my last iteration.

A major inspiration for me is the noctalia shell v5 rewrite, it’s plugin system is extremely cool, and each plugin can be configured in it’s settings editor.

While i don’t currently plan to make a full desktop experience like noctalia, having plugins that can add launcher providers and bar widgets, and specify configuration options for them is really cool, and I hope to be able to create something similar.