diff options
| author | Matt Kosarek <matt.kosarek@canonical.com> | 2026-03-11 17:49:05 -0400 |
|---|---|---|
| committer | Matt Kosarek <matt.kosarek@canonical.com> | 2026-03-11 17:49:05 -0400 |
| commit | 77b0f69d0c6e555349dd491d7ca209924d119e61 (patch) | |
| tree | 095cf20002f5df752c04c20af4366588bd7ba32b /.astro/data-store.json | |
| parent | c929a29c728c6799a3f83f5ad5c1c6f99ed516d4 (diff) | |
Diffstat (limited to '.astro/data-store.json')
| -rw-r--r-- | .astro/data-store.json | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/.astro/data-store.json b/.astro/data-store.json new file mode 100644 index 0000000..7b64288 --- /dev/null +++ b/.astro/data-store.json @@ -0,0 +1 @@ +[["Map",1,2,9,10],"meta::meta",["Map",3,4,5,6,7,8],"astro-version","5.18.1","content-config-digest","43a771c3b74a5605","astro-config-digest","{\"root\":{},\"srcDir\":{},\"publicDir\":{},\"outDir\":{},\"cacheDir\":{},\"site\":\"https://matthewkosarek.xyz\",\"compressHTML\":true,\"base\":\"/\",\"trailingSlash\":\"ignore\",\"output\":\"static\",\"scopedStyleStrategy\":\"attribute\",\"build\":{\"format\":\"directory\",\"client\":{},\"server\":{},\"assets\":\"_astro\",\"serverEntry\":\"entry.mjs\",\"redirects\":true,\"inlineStylesheets\":\"auto\",\"concurrency\":1},\"server\":{\"open\":false,\"host\":false,\"port\":4321,\"streaming\":true,\"allowedHosts\":[]},\"redirects\":{},\"image\":{\"endpoint\":{\"route\":\"/_image\"},\"service\":{\"entrypoint\":\"astro/assets/services/sharp\",\"config\":{}},\"domains\":[],\"remotePatterns\":[],\"responsiveStyles\":false},\"devToolbar\":{\"enabled\":true},\"markdown\":{\"syntaxHighlight\":{\"type\":\"shiki\",\"excludeLangs\":[\"math\"]},\"shikiConfig\":{\"langs\":[],\"langAlias\":{},\"theme\":\"github-dark\",\"themes\":{},\"wrap\":false,\"transformers\":[]},\"remarkPlugins\":[],\"rehypePlugins\":[],\"remarkRehype\":{},\"gfm\":true,\"smartypants\":true},\"security\":{\"checkOrigin\":true,\"allowedDomains\":[],\"actionBodySizeLimit\":1048576},\"env\":{\"schema\":{},\"validateSecrets\":false},\"experimental\":{\"clientPrerender\":false,\"contentIntellisense\":false,\"headingIdCompat\":false,\"preserveScriptOrder\":false,\"liveContentCollections\":false,\"csp\":false,\"staticImportMetaEnv\":false,\"chromeDevtoolsWorkspace\":false,\"failOnPrerenderConflict\":false,\"svgo\":false},\"legacy\":{\"collections\":false}}","posts",["Map",11,12,35,36,55,56,75,76],"jul_28_2025",{"id":11,"data":13,"body":18,"filePath":19,"digest":20,"rendered":21,"legacyId":34},{"title":14,"date":15,"tags":16},"Update July 28, 2025","2025-07-28",[17],"update","## What have I been up to?\n\nWhoops! I missed this month's update by a *long* shot, but I still want to get it out there before the end of the month.\n\nThis month was busy busy. I released [v0.6.0 of miracle-wm](https://github.com/miracle-wm-org/miracle-wm/releases/tag/v0.6.0) which adds a bunch of new features, go and check it out if you haven't already! I am nearly finished with the sway/i3 IPC support and have big plans to wrap that up before the middle of August. There really isn't much more to go on that front so I might as well close that chapter. On top of that, the more interesting features of miracle that I have planned (e.g. some built-in shell integrations) are motivating me to wrap up the boring parts first.\n\nAside from miracle, I've continued to land a bunch of things in Mir recently around accessibility. The magnifier work is finally done, so go check that out if you use that feature in your day-to-day! I also did a *ton of work* to fix screenshooting on rotated displays. We were ignoring [wl_surface::set_buffer_transform](https://wayland.app/protocols/wayland#wl_surface:request:set_buffer_transform) in a big way. Now that we're not doing that, your screenshots should look perfect every time!\n\nLast but not least, the team has been making waves implementing multi-window in the Flutter toolkit. That's some really interesting and exciting work, so stay tuned for that if you're a Flutter developer!\n\nThat's all I got! I will make another post shortly, maybe once miracle v0.7.0 is out. Have a great rest of your summer/winter šŖ","src/content/posts/jul_28_2025.md","eb7072bb3c1eff0c",{"html":22,"metadata":23},"\u003Ch2 id=\"what-have-i-been-up-to\">What have I been up to?\u003C/h2>\n\u003Cp>Whoops! I missed this monthās update by a \u003Cem>long\u003C/em> shot, but I still want to get it out there before the end of the month.\u003C/p>\n\u003Cp>This month was busy busy. I released \u003Ca href=\"https://github.com/miracle-wm-org/miracle-wm/releases/tag/v0.6.0\">v0.6.0 of miracle-wm\u003C/a> which adds a bunch of new features, go and check it out if you havenāt already! I am nearly finished with the sway/i3 IPC support and have big plans to wrap that up before the middle of August. There really isnāt much more to go on that front so I might as well close that chapter. On top of that, the more interesting features of miracle that I have planned (e.g. some built-in shell integrations) are motivating me to wrap up the boring parts first.\u003C/p>\n\u003Cp>Aside from miracle, Iāve continued to land a bunch of things in Mir recently around accessibility. The magnifier work is finally done, so go check that out if you use that feature in your day-to-day! I also did a \u003Cem>ton of work\u003C/em> to fix screenshooting on rotated displays. We were ignoring \u003Ca href=\"https://wayland.app/protocols/wayland#wl_surface:request:set_buffer_transform\">wl_surface::set_buffer_transform\u003C/a> in a big way. Now that weāre not doing that, your screenshots should look perfect every time!\u003C/p>\n\u003Cp>Last but not least, the team has been making waves implementing multi-window in the Flutter toolkit. Thatās some really interesting and exciting work, so stay tuned for that if youāre a Flutter developer!\u003C/p>\n\u003Cp>Thatās all I got! I will make another post shortly, maybe once miracle v0.7.0 is out. Have a great rest of your summer/winter šŖ\u003C/p>",{"headings":24,"localImagePaths":29,"remoteImagePaths":30,"frontmatter":31,"imagePaths":33},[25],{"depth":26,"slug":27,"text":28},2,"what-have-i-been-up-to","What have I been up to?",[],[],{"title":14,"date":15,"tags":32},[17],[],"jul_28_2025.md","june_08_2025",{"id":35,"data":37,"body":41,"filePath":42,"digest":43,"rendered":44,"legacyId":54},{"title":38,"date":39,"tags":40},"Update June 08, 2025","2025-06-08",[17],"## What have I been up to?\n\nAnother month has gone by, so I guess it's time to see what I've been up to.\n\nCanonical hosted our company's sprint in Frankfurt, Germany during the month of May. It was a very productive time for the whole team. I always enjoy seeing everyone in person, talking through big issues face-to-face, and exploring a new city. I also got to spend some time in Zurich, Switzerland before the sprint began. Zurich is pretty awesome šļø!\n\nIn miracle-wm, I have been going down quite the rabbit-hole š! What began as a plan to fix the remaining warnings in the source code has snowballed into me implementing the rest of the IPC mechanism and testing the entire thing. This has been no small feat, as both sway and i3 implement a *lot* of different commands, and a failure to implement any one of them often leads to half-broken clients. I've had to make some \"executive\" decisions to ignore parts of the protocol that I deem irrelevant now (especially many of the X-specific bits), but it is a mostly compatible implementation. The good news is that I've nearly completed this journey and should be ready to release version `0.6.0` some time in the middle of June.\n\nMiracle is getting closer-and-closer to my vision of it every day. The only problem right now is finding the bandwidth to implement everything that I have in my head :)\n\nOn the Mir side of things, I am still implementing the magnifier glass accessibility feature from before, but with a much-improved technical direction that we arrived at during our time in Frankfurt. Unfortunately, this required a quick detour to properly implement the `overlay_cursor` flag of [zwlr_screencopy_manager_v1::capture_output_region](https://wayland.app/protocols/wlr-screencopy-unstable-v1#zwlr_screencopy_manager_v1:request:capture_output:arg:overlay_cursor), as both screencopy and magnification rely on this same code path. The good news is that I'm quite close on this and it should be landing in full any day now š¤\n\nI also fixed [this very breaking bug](https://github.com/canonical/mir/pull/3968) that was actively preventing miracle from rendering on my second monitor, so that's good.\n\nIn addition to these two projects, I am also reinvolving myself in the Flutter multi-window work. For those who don't know, we're trying to make it so that the Flutter toolkit can render to multiple surfaces. This is no small feat, as Flutter was originally written with the assumption that only a single \"view\" would ever be drawn to. However we've managed to make some great progress on it thus far, and we're very excited to land the first pull request imminently with the help of the folks over at Google!\n\nI hope you're having a great and productive summer š","src/content/posts/june_08_2025.md","50d5a26d5c525d33",{"html":45,"metadata":46},"\u003Ch2 id=\"what-have-i-been-up-to\">What have I been up to?\u003C/h2>\n\u003Cp>Another month has gone by, so I guess itās time to see what Iāve been up to.\u003C/p>\n\u003Cp>Canonical hosted our companyās sprint in Frankfurt, Germany during the month of May. It was a very productive time for the whole team. I always enjoy seeing everyone in person, talking through big issues face-to-face, and exploring a new city. I also got to spend some time in Zurich, Switzerland before the sprint began. Zurich is pretty awesome šļø!\u003C/p>\n\u003Cp>In miracle-wm, I have been going down quite the rabbit-hole š! What began as a plan to fix the remaining warnings in the source code has snowballed into me implementing the rest of the IPC mechanism and testing the entire thing. This has been no small feat, as both sway and i3 implement a \u003Cem>lot\u003C/em> of different commands, and a failure to implement any one of them often leads to half-broken clients. Iāve had to make some āexecutiveā decisions to ignore parts of the protocol that I deem irrelevant now (especially many of the X-specific bits), but it is a mostly compatible implementation. The good news is that Iāve nearly completed this journey and should be ready to release version \u003Ccode>0.6.0\u003C/code> some time in the middle of June.\u003C/p>\n\u003Cp>Miracle is getting closer-and-closer to my vision of it every day. The only problem right now is finding the bandwidth to implement everything that I have in my head :)\u003C/p>\n\u003Cp>On the Mir side of things, I am still implementing the magnifier glass accessibility feature from before, but with a much-improved technical direction that we arrived at during our time in Frankfurt. Unfortunately, this required a quick detour to properly implement the \u003Ccode>overlay_cursor\u003C/code> flag of \u003Ca href=\"https://wayland.app/protocols/wlr-screencopy-unstable-v1#zwlr_screencopy_manager_v1:request:capture_output:arg:overlay_cursor\">zwlr_screencopy_manager_v1::capture_output_region\u003C/a>, as both screencopy and magnification rely on this same code path. The good news is that Iām quite close on this and it should be landing in full any day now š¤\u003C/p>\n\u003Cp>I also fixed \u003Ca href=\"https://github.com/canonical/mir/pull/3968\">this very breaking bug\u003C/a> that was actively preventing miracle from rendering on my second monitor, so thatās good.\u003C/p>\n\u003Cp>In addition to these two projects, I am also reinvolving myself in the Flutter multi-window work. For those who donāt know, weāre trying to make it so that the Flutter toolkit can render to multiple surfaces. This is no small feat, as Flutter was originally written with the assumption that only a single āviewā would ever be drawn to. However weāve managed to make some great progress on it thus far, and weāre very excited to land the first pull request imminently with the help of the folks over at Google!\u003C/p>\n\u003Cp>I hope youāre having a great and productive summer š\u003C/p>",{"headings":47,"localImagePaths":49,"remoteImagePaths":50,"frontmatter":51,"imagePaths":53},[48],{"depth":26,"slug":27,"text":28},[],[],{"title":38,"date":39,"tags":52},[17],[],"june_08_2025.md","may_06_2025",{"id":55,"data":57,"body":61,"filePath":62,"digest":63,"rendered":64,"legacyId":74},{"title":58,"date":59,"tags":60},"Update May 06, 2025","2025-05-06",[17],"## What have I been up to?\n\nI've been meaning to do these little blog-post type updates for a while, and I figured now is as good a time as any. So let's start :)\n\nIn the world of miracle-wm, I've been hard at work writing a new settings application for the compositor called [miracle-settings](https://github.com/miracle-wm-org/miracle-settings). While the application is written in Flutter, the logic behind the application is entirely implemented in `libmiracle-wm-config.so`, a new library that will ship with miracle as part of `v0.6.0`. If Flutter isn't your cup of tea, you should be able to implement your own settings app for miracle in the language/toolkit of your choice by simply binding to the C (or C++!) API.\n\nI also implemented [wlr-output-management](https://wayland.app/protocols/wlr-output-management-unstable-v1) in miracle and changed how we do display configuration in a big way. The display configuration will now always be loaded from `$HOME/.config/miracle-wm/display.yaml`. Users should now be able to use apps like [wdisplays](https://github.com/artizirk/wdisplays) to change the output configuration at runtime, which is pretty cool!\n\nOn the Mir project, I've been working on accessibility features (e.g. magnification) in addition to exposing some facilities for compositor authors to write end-to-end tests for Mir-based compositors. These new testing facilities should help us write tests in miracle in a big way.\n\nAlso - my cat who ate a sewing needle last year has turned two! š±","src/content/posts/may_06_2025.md","83f373d568b44b68",{"html":65,"metadata":66},"\u003Ch2 id=\"what-have-i-been-up-to\">What have I been up to?\u003C/h2>\n\u003Cp>Iāve been meaning to do these little blog-post type updates for a while, and I figured now is as good a time as any. So letās start :)\u003C/p>\n\u003Cp>In the world of miracle-wm, Iāve been hard at work writing a new settings application for the compositor called \u003Ca href=\"https://github.com/miracle-wm-org/miracle-settings\">miracle-settings\u003C/a>. While the application is written in Flutter, the logic behind the application is entirely implemented in \u003Ccode>libmiracle-wm-config.so\u003C/code>, a new library that will ship with miracle as part of \u003Ccode>v0.6.0\u003C/code>. If Flutter isnāt your cup of tea, you should be able to implement your own settings app for miracle in the language/toolkit of your choice by simply binding to the C (or C++!) API.\u003C/p>\n\u003Cp>I also implemented \u003Ca href=\"https://wayland.app/protocols/wlr-output-management-unstable-v1\">wlr-output-management\u003C/a> in miracle and changed how we do display configuration in a big way. The display configuration will now always be loaded from \u003Ccode>$HOME/.config/miracle-wm/display.yaml\u003C/code>. Users should now be able to use apps like \u003Ca href=\"https://github.com/artizirk/wdisplays\">wdisplays\u003C/a> to change the output configuration at runtime, which is pretty cool!\u003C/p>\n\u003Cp>On the Mir project, Iāve been working on accessibility features (e.g. magnification) in addition to exposing some facilities for compositor authors to write end-to-end tests for Mir-based compositors. These new testing facilities should help us write tests in miracle in a big way.\u003C/p>\n\u003Cp>Also - my cat who ate a sewing needle last year has turned two! š±\u003C/p>",{"headings":67,"localImagePaths":69,"remoteImagePaths":70,"frontmatter":71,"imagePaths":73},[68],{"depth":26,"slug":27,"text":28},[],[],{"title":58,"date":59,"tags":72},[17],[],"may_06_2025.md","dec_29_2025",{"id":75,"data":77,"body":81,"filePath":82,"digest":83,"rendered":84,"legacyId":100},{"title":78,"date":79,"tags":80},"Update December 29, 2025","2025-12-29",[17],"## What have I been up to?\n\n2025 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.\n\n## Miracle Update\n\nMiracle 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.\n\nOne 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.\n\nThe \"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.\n\nThe 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 privileged compositor. This increases the attack surface to an extent that I would feel uncomfortable shipping to users.\n\nFor these reasons, I decided that Miracle plugins will be written in **WebAssembly** with the help of [WasmEdge](https://wasmedge.org). The benefits of this approach are:\n\n1. WebAssembly runs in a lightweight bytecode engine\n2. Many languages can compile down to WebAssembly (Rust will have first-class support to start)\n3. WebAssembly plugins will only be able to access APIs that we provide (reducing the requirement of \"trusting\" the plugin author)\n\nThe 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 linearly fade in a window:\n\n```rust\n#[unsafe(no_mangle)]\npub extern \"C\" fn animate(\n data: MiracleAnimationFrameData,\n) -> MiracleAnimationFrameResult {\n\n let progress = data.runtime_seconds / data.duration_seconds;\n let opacity = data.opacity_start + (data.opacity_end - data.opacity_start) * progress;\n MiracleAnimationFrameResult {\n completed: 0,\n has_area: 1,\n area: [data.destination[0], data.destination[1], data.destination[2], data.destination[3]],\n has_transform: 0,\n transform: [0.0; 16],\n has_opacity: 1,\n opacity,\n }\n}\n```\n\nWhile 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.\n\nIn parallel with this work, I have been working on improving the **shell authoring** experience in Miracle. The beginning of this has been the initial [implementation of a background on floating containers](https://github.com/miracle-wm-org/miracle-wm/pull/745), 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 [miracle.dart](https://github.com/miracle-wm-org/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.\n\nAt 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.\n\nv0.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!\n\n## Conclusion\n\n2025 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.\n\nKeep on making great stuff āļø","src/content/posts/dec_29_2025.md","038649b01aa2629d",{"html":85,"metadata":86},"\u003Ch2 id=\"what-have-i-been-up-to\">What have I been up to?\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Ch2 id=\"miracle-update\">Miracle Update\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>One of the major upcoming features in Miracle is a \u003Cstrong>plugin system\u003C/strong>. 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.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>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 privileged compositor. This increases the attack surface to an extent that I would feel uncomfortable shipping to users.\u003C/p>\n\u003Cp>For these reasons, I decided that Miracle plugins will be written in \u003Cstrong>WebAssembly\u003C/strong> with the help of \u003Ca href=\"https://wasmedge.org\">WasmEdge\u003C/a>. The benefits of this approach are:\u003C/p>\n\u003Col>\n\u003Cli>WebAssembly runs in a lightweight bytecode engine\u003C/li>\n\u003Cli>Many languages can compile down to WebAssembly (Rust will have first-class support to start)\u003C/li>\n\u003Cli>WebAssembly plugins will only be able to access APIs that we provide (reducing the requirement of ātrustingā the plugin author)\u003C/li>\n\u003C/ol>\n\u003Cp>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 linearly fade in a window:\u003C/p>\n\u003Cpre class=\"astro-code github-dark\" style=\"background-color:#24292e;color:#e1e4e8; overflow-x: auto;\" tabindex=\"0\" data-language=\"rust\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\">#[\u003C/span>\u003Cspan style=\"color:#F97583\">unsafe\u003C/span>\u003Cspan style=\"color:#E1E4E8\">(no_mangle)]\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\">pub\u003C/span>\u003Cspan style=\"color:#F97583\"> extern\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> \"C\"\u003C/span>\u003Cspan style=\"color:#F97583\"> fn\u003C/span>\u003Cspan style=\"color:#B392F0\"> animate\u003C/span>\u003Cspan style=\"color:#E1E4E8\">(\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\"> data\u003C/span>\u003Cspan style=\"color:#F97583\">:\u003C/span>\u003Cspan style=\"color:#B392F0\"> MiracleAnimationFrameData\u003C/span>\u003Cspan style=\"color:#E1E4E8\">,\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\">) \u003C/span>\u003Cspan style=\"color:#F97583\">->\u003C/span>\u003Cspan style=\"color:#B392F0\"> MiracleAnimationFrameResult\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> {\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\"> let\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> progress \u003C/span>\u003Cspan style=\"color:#F97583\">=\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> data\u003C/span>\u003Cspan style=\"color:#F97583\">.\u003C/span>\u003Cspan style=\"color:#E1E4E8\">runtime_seconds \u003C/span>\u003Cspan style=\"color:#F97583\">/\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> data\u003C/span>\u003Cspan style=\"color:#F97583\">.\u003C/span>\u003Cspan style=\"color:#E1E4E8\">duration_seconds;\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\"> let\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> opacity \u003C/span>\u003Cspan style=\"color:#F97583\">=\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> data\u003C/span>\u003Cspan style=\"color:#F97583\">.\u003C/span>\u003Cspan style=\"color:#E1E4E8\">opacity_start \u003C/span>\u003Cspan style=\"color:#F97583\">+\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> (data\u003C/span>\u003Cspan style=\"color:#F97583\">.\u003C/span>\u003Cspan style=\"color:#E1E4E8\">opacity_end \u003C/span>\u003Cspan style=\"color:#F97583\">-\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> data\u003C/span>\u003Cspan style=\"color:#F97583\">.\u003C/span>\u003Cspan style=\"color:#E1E4E8\">opacity_start) \u003C/span>\u003Cspan style=\"color:#F97583\">*\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> progress;\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#B392F0\"> MiracleAnimationFrameResult\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> {\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\"> completed\u003C/span>\u003Cspan style=\"color:#F97583\">:\u003C/span>\u003Cspan style=\"color:#79B8FF\"> 0\u003C/span>\u003Cspan style=\"color:#E1E4E8\">,\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\"> has_area\u003C/span>\u003Cspan style=\"color:#F97583\">:\u003C/span>\u003Cspan style=\"color:#79B8FF\"> 1\u003C/span>\u003Cspan style=\"color:#E1E4E8\">,\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\"> area\u003C/span>\u003Cspan style=\"color:#F97583\">:\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> [data\u003C/span>\u003Cspan style=\"color:#F97583\">.\u003C/span>\u003Cspan style=\"color:#E1E4E8\">destination[\u003C/span>\u003Cspan style=\"color:#79B8FF\">0\u003C/span>\u003Cspan style=\"color:#E1E4E8\">], data\u003C/span>\u003Cspan style=\"color:#F97583\">.\u003C/span>\u003Cspan style=\"color:#E1E4E8\">destination[\u003C/span>\u003Cspan style=\"color:#79B8FF\">1\u003C/span>\u003Cspan style=\"color:#E1E4E8\">], data\u003C/span>\u003Cspan style=\"color:#F97583\">.\u003C/span>\u003Cspan style=\"color:#E1E4E8\">destination[\u003C/span>\u003Cspan style=\"color:#79B8FF\">2\u003C/span>\u003Cspan style=\"color:#E1E4E8\">], data\u003C/span>\u003Cspan style=\"color:#F97583\">.\u003C/span>\u003Cspan style=\"color:#E1E4E8\">destination[\u003C/span>\u003Cspan style=\"color:#79B8FF\">3\u003C/span>\u003Cspan style=\"color:#E1E4E8\">]],\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\"> has_transform\u003C/span>\u003Cspan style=\"color:#F97583\">:\u003C/span>\u003Cspan style=\"color:#79B8FF\"> 0\u003C/span>\u003Cspan style=\"color:#E1E4E8\">,\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\"> transform\u003C/span>\u003Cspan style=\"color:#F97583\">:\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> [\u003C/span>\u003Cspan style=\"color:#79B8FF\">0.0\u003C/span>\u003Cspan style=\"color:#E1E4E8\">; \u003C/span>\u003Cspan style=\"color:#79B8FF\">16\u003C/span>\u003Cspan style=\"color:#E1E4E8\">],\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\"> has_opacity\u003C/span>\u003Cspan style=\"color:#F97583\">:\u003C/span>\u003Cspan style=\"color:#79B8FF\"> 1\u003C/span>\u003Cspan style=\"color:#E1E4E8\">,\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\"> opacity,\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\"> }\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\">}\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\n\u003Cp>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.\u003C/p>\n\u003Cp>In parallel with this work, I have been working on improving the \u003Cstrong>shell authoring\u003C/strong> experience in Miracle. The beginning of this has been the initial \u003Ca href=\"https://github.com/miracle-wm-org/miracle-wm/pull/745\">implementation of a background on floating containers\u003C/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 \u003Ca href=\"https://github.com/miracle-wm-org/miracle.dart\">miracle.dart\u003C/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.\u003C/p>\n\u003Cp>At the same time, I have been working on improving the \u003Cstrong>floating window management\u003C/strong> in Miracle. Miracle should be a competent floating window manager for those who need it.\u003C/p>\n\u003Cp>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!\u003C/p>\n\u003Ch2 id=\"conclusion\">Conclusion\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>Keep on making great stuff āļø\u003C/p>",{"headings":87,"localImagePaths":95,"remoteImagePaths":96,"frontmatter":97,"imagePaths":99},[88,89,92],{"depth":26,"slug":27,"text":28},{"depth":26,"slug":90,"text":91},"miracle-update","Miracle Update",{"depth":26,"slug":93,"text":94},"conclusion","Conclusion",[],[],{"title":78,"date":79,"tags":98},[17],[],"dec_29_2025.md"]
\ No newline at end of file |
