diff options
Diffstat (limited to '_posts')
| -rw-r--r-- | _posts/dec_29_2025.org | 61 | ||||
| -rw-r--r-- | _posts/sitemap.org | 29 |
2 files changed, 85 insertions, 5 deletions
diff --git a/_posts/dec_29_2025.org b/_posts/dec_29_2025.org new file mode 100644 index 0000000..4318ef6 --- /dev/null +++ b/_posts/dec_29_2025.org @@ -0,0 +1,61 @@ +:PROPERTIES: +:ID: defb26e2-2966-477d-b232-f1fff4066247 +:END: + +#+TITLE: Update December 29, 2025 +#+DATE: <2025-12-29 Mon 10:27> +#+filetags: :update: + +* What have I been up to? + +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. + +* Miracle Update +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, + +One of the major upcoming features in Miracle is a *plugin system*. 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. + +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. + +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. + +For these reasons, I decided that Miracle plugins will be written in *WebAssembly* with the help of [[https://wasmedge.org][WasmEdge]]. The benefits of this approach are: + +1. WebAssembly runs in a lightweight bytecode engine +2. Many languages can compile down to WebAssembly (Rust will have first-class support to start) +3. WebAssembly plugins will only be able to access APIs that we provide (reducing the requirement of "trusting" the plugin author) + +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: + +#+BEGIN_SRC rust +#[unsafe(no_mangle)] +pub extern "C" fn animate( + data: MiracleAnimationFrameData, +) -> MiracleAnimationFrameResult { + + let progress = data.runtime_seconds / data.duration_seconds; + let opacity = data.opacity_start + (data.opacity_end - data.opacity_start) * progress; + MiracleAnimationFrameResult { + completed: 0, + has_area: 1, + area: [data.destination[0], data.destination[1], data.destination[2], data.destination[3]], + has_transform: 0, + transform: [0.0; 16], + has_opacity: 1, + opacity, + } +} +#+END_SRC + +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. + +In parallel with this work, I have been working on improving the *shell authoring* experience in Miracle. The beginning of this has been the initial [[https://github.com/miracle-wm-org/miracle-wm/pull/745][implementation of a background on floating containers]], 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 [[https://github.com/miracle-wm-org/miracle.dart][miracle.dart]], 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. + +At the same time, I have been working on improving the *floating window management* in Miracle. Miracle should be a competent floating window manager for those who need it. + +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! + +* Conclusion +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. + +Keep on making great stuff ✌️ diff --git a/_posts/sitemap.org b/_posts/sitemap.org index c457aa1..202c055 100644 --- a/_posts/sitemap.org +++ b/_posts/sitemap.org @@ -1,24 +1,43 @@ #+TITLE: Matthew's Blog Posts -#+DATE: 2025-07-28 at 15:19 +#+DATE: 2025-12-29 at 13:03 #+HTML_LINK_HOME: / #+HTML_LINK_UP: / -- [[file:jul_28_2025.org][Update July 28, 2025]] created on July 28, 2025 +- [[file:dec_29_2025.org][Update December 29, 2025]] + #+begin_sitemap_date + December 29, 2025 + #+end_sitemap_date #+begin_sitemap_tag update #+end_sitemap_tag -- [[file:june_08_2025.org][Update June 08, 2025]] created on June 08, 2025 +- [[file:jul_28_2025.org][Update July 28, 2025]] + #+begin_sitemap_date + July 28, 2025 + #+end_sitemap_date #+begin_sitemap_tag update #+end_sitemap_tag -- [[file:may_06_2025.org][Update May 06, 2025]] created on May 06, 2025 +- [[file:june_08_2025.org][Update June 08, 2025]] + #+begin_sitemap_date + June 08, 2025 + #+end_sitemap_date #+begin_sitemap_tag update #+end_sitemap_tag -- [[file:hello.org][Hello, Org]] created on June 20, 2023 +- [[file:may_06_2025.org][Update May 06, 2025]] + #+begin_sitemap_date + May 06, 2025 + #+end_sitemap_date + #+begin_sitemap_tag + update + #+end_sitemap_tag +- [[file:hello.org][Hello, Org]] + #+begin_sitemap_date + June 20, 2023 + #+end_sitemap_date #+begin_sitemap_tag technology,home #+end_sitemap_tag |