diff options
| author | Matt Kosarek <matt.kosarek@canonical.com> | 2025-12-29 13:03:38 -0500 |
|---|---|---|
| committer | Matt Kosarek <matt.kosarek@canonical.com> | 2025-12-29 13:03:38 -0500 |
| commit | 3262dd2648ac3ec64ca2405ec94fe6a77fa9bd7d (patch) | |
| tree | 22bd5f2505f3bd6adc518a3c761d10f1f5324ef5 /posts/dec_29_2025.html | |
| parent | 3b823cdb0b398b8365138bbcf5df60871dfcd61c (diff) | |
Diffstat (limited to 'posts/dec_29_2025.html')
| -rw-r--r-- | posts/dec_29_2025.html | 122 |
1 files changed, 122 insertions, 0 deletions
diff --git a/posts/dec_29_2025.html b/posts/dec_29_2025.html new file mode 100644 index 0000000..9e4ee07 --- /dev/null +++ b/posts/dec_29_2025.html @@ -0,0 +1,122 @@ +<?xml version="1.0" encoding="utf-8"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" +"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> +<head> +<meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> +<meta name="viewport" content="width=device-width, initial-scale=1" /> +<title>Update December 29, 2025</title> +<meta name="generator" content="Org Mode" /> + +<link rel="stylesheet" href="/index.css" /> +<link rel="stylesheet" href="/posts/post.css" /> +<link rel="shortcut icon" href="/favicon/favicon.ico" type="image/x-icon"> +<script src='/posts/post.js'></script> +</head> +<body> +<div id="org-div-home-and-up"> + <a accesskey="h" href="/posts/sitemap.html"> UP </a> + <a accesskey="H" href="/"> HOME </a> +</div><div id="preamble" class="status"> + + <div class="org-article-title"> + <h1>Update December 29, 2025</h1> + <span>Last modified: 2025-12-29 Mon 10:27</span> + <span><a href="/posts/feed.xml">RSS Feed</a></span> + </div> +</div> +<div id="content" class="content"> +<div id="outline-container-orgbac5ed0" class="outline-2"> +<h2 id="orgbac5ed0">What have I been up to?</h2> +<div class="outline-text-2" id="text-orgbac5ed0"> +<p> +2025 has been one busy year for me! I feel as though I've been working on a dozen things at once and have spent much of my working (and personal) days productively. Miracle finally feels like it's getting somewhere fast, the Flutter multi-window work is landing at a solid pace, and Mir is feeling like a truly solid option for Wayland compositor development. I will refrain from speaking too much on the Flutter and Mir work in this post, as those are best left in the hands of Canonical. +</p> +</div> +</div> +<div id="outline-container-orgb1a98f7" class="outline-2"> +<h2 id="orgb1a98f7">Miracle Update</h2> +<div class="outline-text-2" id="text-orgb1a98f7"> +<p> +Miracle has come a long way this past year. I now feel entirely confident using it as my daily driver, minus a few hiccups that I encounter in-between releases. A lot of great things are cooking for 2026 too, +</p> + +<p> +One of the major upcoming features in Miracle is a <b>plugin system</b>. Having a plugin system in Miracle will empower 3rd party authors to extend the compositor in ways that I haven't currently imagined while also providing me with the flexibility to iterate quickly on designs. Many compositors already have plugin systems. For example, GNOME does this via JavaScript and Hyprland does this by dynamically loading shared libraries at runtime (note: this is my understanding as of writing this). Both of these solutions are reasonable, but they come with a few downsides. +</p> + +<p> +The "true" scripting language solution comes with the overhead of shipping a complicated interpreter inside of the compositor. In addition to this, plugin developers are forced to use a particular language, perhaps one that they are unfamiliar with. While you get increased programming flexibility from using a scripting language, you have to balance this with the introduced complexity of that language. +</p> + +<p> +The shared library approach also has its downsides. While dynamically loading a shared library at runtime is lightweight, it prevents users of the compositor from safely running plugins unless they first trust the plugin author. The shared library will be running inside of the same process as your very priveleged compositor. This increases the attack surface to an extent that I would feel uncomfortable shipping to users. +</p> + +<p> +For these reasons, I decided that Miracle plugins will be written in <b>WebAssembly</b> with the help of <a href="https://wasmedge.org">WasmEdge</a>. The benefits of this approach are: +</p> + +<ol class="org-ol"> +<li>WebAssembly runs in a lightweight bytecode engine</li> +<li>Many languages can compile down to WebAssembly (Rust will have first-class support to start)</li> +<li>WebAssembly plugins will only be able to access APIs that we provide (reducing the requirement of "trusting" the plugin author)</li> +</ol> + +<p> +The WebAssembly modules will implement certain functions by signature. Miracle will search for a particular signature in the module. If that signature is found, Miracle will delegate the function call defined by that signature to the WebAssembly module instead of Miracle's internal implementation. In this way, the WASM plugin will only have the data that it needs to perform an action. It is perfectly isolated from the rest of the process while also running quickly in the bytecode engine. Here is an example of an animation plugin that will linearlly fade in a window: +</p> + +<div class="org-src-container"> +<pre class="src src-rust"><span class="org-preprocessor">#[</span><span class="org-rust-unsafe">unsafe</span><span class="org-preprocessor">(no_mangle)]</span> +<span class="org-keyword">pub</span> <span class="org-keyword">extern</span> <span class="org-string">"C"</span> <span class="org-keyword">fn</span> <span class="org-function-name">animate</span>( + <span class="org-variable-name">data</span>: <span class="org-type">MiracleAnimationFrameData</span>, +) -> <span class="org-type">MiracleAnimationFrameResult</span> { + + <span class="org-keyword">let</span> <span class="org-variable-name">progress</span> = data.runtime_seconds / data.duration_seconds; + <span class="org-keyword">let</span> <span class="org-variable-name">opacity</span> = data.opacity_start + (data.opacity_end - data.opacity_start) * progress; + <span class="org-type">MiracleAnimationFrameResult</span> { + <span class="org-variable-name">completed</span>: 0, + <span class="org-variable-name">has_area</span>: 1, + <span class="org-variable-name">area</span>: [data.destination[0], data.destination[1], data.destination[2], data.destination[3]], + <span class="org-variable-name">has_transform</span>: 0, + <span class="org-variable-name">transform</span>: [0.0; 16], + <span class="org-variable-name">has_opacity</span>: 1, + opacity, + } +} +</pre> +</div> + +<p> +While this is still in a prototype phase, the types defined here will be provided by a Rust crate in the future. The system should be very easy to use from Rust. +</p> + +<p> +In parallel with this work, I have been working on improving the <b>shell authoring</b> experience in Miracle. The beginning of this has been the initial <a href="https://github.com/miracle-wm-org/miracle-wm/pull/745">implementation of a background on floating containers</a>, but work is proceeding to things like built-in context menus, workspace overview modes, and much more. The idea is to have simple, built-in versions for many shell components while allowing users to provide their own custom clients for each shell element. To this end, I have been working on <a href="https://github.com/miracle-wm-org/miracle.dart">miracle.dart</a>, which is a Dart API that should enable users to easily interact with Miracle in Flutter and provide Flutter apps as shell elements. This API is still in early stages, however. +</p> + +<p> +At the same time, I have been working on improving the <b>floating window management</b> in Miracle. Miracle should be a competent floating window manager for those who need it. +</p> + +<p> +v0.9.0 of Miracle will probably be a long time in the making. My estimate is that early spring will see it released. However, it should be the penultimate release before I am ready to make v1.0.0 the first, official stable release. And who knows - maybe we'll even have a shell to go along with it! +</p> +</div> +</div> +<div id="outline-container-org5047f79" class="outline-2"> +<h2 id="org5047f79">Conclusion</h2> +<div class="outline-text-2" id="text-org5047f79"> +<p> +2025 has been a whirlwind of a year, and I'm sure that 2026 won't slow down at all for me. A lot of the long term projects that I've been working on are finally coming together, and I feel as though I am on the cusp of making software that I'm truly proud of. On top of that, I am engaged! What a time to be alive :) I hope you all have a lovely New Year with your friends, family, cats, dogs, and everything else. +</p> + +<p> +Keep on making great stuff ✌️ +</p> +</div> +</div> +</div> +</body> +</html> |