diff options
Diffstat (limited to '_posts')
| -rw-r--r-- | _posts/dec_29_2025.org | 61 | ||||
| -rw-r--r-- | _posts/hello.org | 46 | ||||
| -rw-r--r-- | _posts/jul_28_2025.org | 20 | ||||
| -rw-r--r-- | _posts/june_08_2025.org | 25 | ||||
| -rw-r--r-- | _posts/may_06_2025.org | 17 | ||||
| -rw-r--r-- | _posts/sitemap.org | 37 |
6 files changed, 203 insertions, 3 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/hello.org b/_posts/hello.org index 38a4fc7..3a7a9c6 100644 --- a/_posts/hello.org +++ b/_posts/hello.org @@ -8,6 +8,10 @@ * TLDR +:PROPERTIES: +:ID: b15846be-b33b-4233-86b1-b56a76622478 +:PUBDATE: 2025-05-06 Tue 14:32 +:END: - Create a new folder - Put [[https://raw.githubusercontent.com/mattkae/matthewkosarek-xyz/master/index.css][index.css]], [[https://raw.githubusercontent.com/mattkae/matthewkosarek-xyz/master/publish.el][publish.el]], and [[https://github.com/mattkae/matthewkosarek-xyz/blob/master/publish.sh][publish.sh]] in the folder - Create a folder called ~_posts~ (this is where blog posts are written) @@ -19,6 +23,10 @@ - Navigate to ~localhost:8080/posts/sitemap.html~ to see your posts * Introduction +:PROPERTIES: +:ID: 39f1ddfb-72e3-4894-9c4c-b160c6e224fe +:PUBDATE: 2025-05-06 Tue 14:32 +:END: I've recently fallen in love with ~org-mode~, specifically when I use it with [[https://www.orgroam.com/][org-roam]]. I find the whole workflow of creating, tagging, and - later on - searching for information on my computer to be very elegant. On top of that, now that I have the time, I want to begin writing blog posts to better work out my thoughts. With both of these things in mind, I am again turning to the universal tool for human prospering: ~org-mode~. This time, I want to see how it can help me turn a simple org file into a blog post on my website. My requirements are: 1. Org files must get published to HTML files in a particular format with a preset stylesheet @@ -33,6 +41,10 @@ And that's pretty much it for now. Without further ado, let's jump into getting (Note: I will be heavily inspired by [[https://systemcrafters.net/publishing-websites-with-org-mode/building-the-site/#creating-the-build-script][this post from System Crafters]]. I highly recommend that you read his post first before you follow my post, as he provides more details about the ~org-publish-project-alist~ command than I am willing to go into in this post.) * Basic HTML File +:PROPERTIES: +:ID: fbd6c42a-45cf-4c16-81fc-e99df88e2389 +:PUBDATE: 2025-05-06 Tue 14:32 +:END: As a pilot, we are going to use this org file that I am currently writing (~hello.org~) as our guinea pig. The goal is to have this org file be our very first blog post. Emacs ships with org export goodies out of the box via the ~ox-publish.el~ package (which you can find [[https://github.com/emacs-mirror/emacs/blob/master/lisp/org/ox-publish.el][here]]). In our case, we will want to use this package to write a script that exports all the ~./_posts/*.org~ files and outputs them to a corresponding ~./posts/*.html~. Leaning heavily on the System Crafters information, we can create a file called ~publish.el~ and write the following inside of it: @@ -62,6 +74,10 @@ emacs -Q --script publish.el We then do a ~chmod +x publish.sh~ to make it an executable and run it with ~./publish.sh~. If everything went according to plan, we should see a new file at ~posts/hello.html~. * Disabling features that we don't want +:PROPERTIES: +:ID: 393f268d-3200-4857-9c78-097468330437 +:PUBDATE: 2025-05-06 Tue 14:32 +:END: The next thing will be to remove some of the generated items that I didn't ask for, namely the table of contents, author, section numbers, creation time stamp, and the validation link. #+BEGIN_SRC emacs-lisp @@ -87,6 +103,10 @@ The next thing will be to remove some of the generated items that I didn't ask f #+END_SRC * Styling & Code Highlighting +:PROPERTIES: +:ID: 25bb1f38-ad48-4513-9238-229955db4328 +:PUBDATE: 2025-05-06 Tue 14:32 +:END: Next thing on our list is custom styling. This can be achieved by first installing the ~htmlize~ package from ~melpa~ / ~elpa~. The EmacsWiki describes this as "a package for exporting the contents of an Emacs buffer to HTML while respecting display properties such as colors, fonts, underlining, invisibility, etc" ([[https://www.emacswiki.org/emacs/Htmlize][reference]]). If used "out-of-the-box", the buffer will be exported to HTML with all of the styles inlined (e.g. if you underline something in your org file, you will generate a ~<span style="text-decoration: underline">...</span>~). However, we are more interested in styling everything by ourselves: we don't want ~htmlize~ making assumptions about what underlining means to us! Luckily, ~htmlize~ gives us the option to export with class names instead of inline styles so that we can specify each style for ourselves. #+BEGIN_SRC emacs-lisp @@ -241,6 +261,10 @@ Finally, we need to tell org mode to include our two CSS files when the page is If we run the publish again, we can see that we have full styling on our code snippets and everything else on our website. * Images +:PROPERTIES: +:ID: 1ca21e46-c212-41ad-b9a7-34fa9909014a +:PUBDATE: 2025-05-06 Tue 14:32 +:END: Our first two criteria have been met! Next on the list is solving images. As an example, let's use this [[/_posts/assets/squirrel.jpg][squirrel image]] that I found online with an open source license. The ideal situation would be: 1. The squirrel image lives closely to this org document (~hello.org~) @@ -273,6 +297,10 @@ That's all there is to it! There are simpler ways as well, but that should do it * Creation Date +:PROPERTIES: +:ID: f061a150-b8bc-41cf-8c50-77338ac47c80 +:PUBDATE: 2025-05-06 Tue 14:32 +:END: Let's add the creation date below the title next. To start, we will modify the publish command to remove the title (~:with-title nil~) and, in its place, show a preamble bit of HTML that contains a formatted ~div~ with the title and the "last modified" span.z #+BEGIN_SRC emacs-lisp @@ -317,6 +345,10 @@ If you want to see the full list of which values can be included in the ~html-pr Note that the downside of this is that the created date will change whenever you next save the buffer. This isn't a huge deal for my purposes, but you may need to come up with a more sophisticated mechanism for the exact "creation" date for your use case. * Generating the Directory +:PROPERTIES: +:ID: e2226b35-d9ed-4758-8471-71a5c82331f1 +:PUBDATE: 2025-05-06 Tue 14:32 +:END: For every org file in my ~_posts~ folder, I would like to create a link to the generated HTML file at the ~/posts.html~ page of my website. You can think of this as the "directory" of all posts. My criteria is: 1. Posts should appear in order from newest to oldest 2. Posts should be searchable by tags (covered in the next section) @@ -360,6 +392,9 @@ If you open the ~sitemap.html~ file in your browser, you will see a bulleted lis From here, you may customize it however you like. The following are my customizations. ** Sitemap Title +:PROPERTIES: +:ID: 47f964f9-15d7-4370-9483-a76dafd79f4c +:END: I changed the title to "Matthew's Blog Posts". #+BEGIN_SRC emacs-lisp @@ -379,6 +414,9 @@ I changed the title to "Matthew's Blog Posts". ** Format blog entries in the list +:PROPERTIES: +:ID: a1c2f9b9-085a-4540-a9f1-7f7388334191 +:END: I like to include the creation date on the blog posts. To do this, we can use ~org-publish-find-property~ to find the date property of the org file. Afterward, we can format a string that includes our formatted timestamp and the ~org-publish-sitemap-default-entry~, which is just a link with the title of the post. #+BEGIN_SRC emacs-lisp (defun get-org-file-title(entry style project) @@ -395,6 +433,10 @@ I like to include the creation date on the blog posts. To do this, we can use ~o #+END_SRC * Tags & Filtering +:PROPERTIES: +:ID: bb278140-4b5c-4025-a267-693820251199 +:PUBDATE: 2025-05-06 Tue 14:32 +:END: I use [[https://www.orgroam.com/][Org-roam]] for all of my note-taking and, in the next blog post, I plan to demonstrate how I will hook up my Org-roam note-taking workflow to my blogging. In the meantime, just know that we can add tags to the top of our org files like this: #+BEGIN_SRC org @@ -585,4 +627,8 @@ Finally, let's append the following to ~posts/posts.css~ so that our tag list is #+END_SRC * Conclusion +:PROPERTIES: +:ID: 0612cef6-bdb4-4f43-8ba7-86e2c22120fd +:PUBDATE: 2025-05-06 Tue 14:32 +:END: There are many more customizations that I plan to do on this system in the future, but I plan to leave this for now so that I can actually get to some blogging. I will proofread and fix my mistakes as time goes on, but this should be a good jumping off point for anyone interested in using org for their own blogging system. diff --git a/_posts/jul_28_2025.org b/_posts/jul_28_2025.org new file mode 100644 index 0000000..fa1bf08 --- /dev/null +++ b/_posts/jul_28_2025.org @@ -0,0 +1,20 @@ +:PROPERTIES: +:ID: 1c09d4f3-1f72-49f6-930d-e2d92473a979 +:END: + +#+TITLE: Update July 28, 2025 +#+DATE: <2025-07-28 Sun 17:30> +#+filetags: :update: + +* What have I been up to? +Whoops! 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. + +This month was busy busy. I released [[https://github.com/miracle-wm-org/miracle-wm/releases/tag/v0.6.0][v0.6.0 of miracle-wm]] 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. + +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 /ton of work/ to fix screenshooting on rotated displays. We were ignoring [[https://wayland.app/protocols/wayland#wl_surface:request:set_buffer_transform][wl_surface::set_buffer_transform]] in a big way. Now that we're not doing that, your screenshots should like perfect every time! + +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! + +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 πͺ + + diff --git a/_posts/june_08_2025.org b/_posts/june_08_2025.org new file mode 100644 index 0000000..0a9bc8f --- /dev/null +++ b/_posts/june_08_2025.org @@ -0,0 +1,25 @@ +:PROPERTIES: +:ID: c397a1c8-5980-419d-88d4-a3c9782343d5 +:END: +#+TITLE: Update June 08, 2025 +#+DATE: <2025-06-08 Sun 15:30> +#+filetags: :update: + +* What have I been up to? +Another month has gone by, so I guess it's time to see what I've been up to. + +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 ποΈ! + +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 implemnenting 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. + +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 :) + +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 ~overlay_cursor~ flag of [[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]], 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 π€ + +I also fixed [[https://github.com/canonical/mir/pull/3968][this very breaking bug]] that was actively preventing miracle from rendering on my second monitor, so that's good. + +On 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 too. 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 a Google! + +I hope you're having a great and productive summer π + + diff --git a/_posts/may_06_2025.org b/_posts/may_06_2025.org new file mode 100644 index 0000000..2b90752 --- /dev/null +++ b/_posts/may_06_2025.org @@ -0,0 +1,17 @@ +:PROPERTIES: +:ID: fe8e0951-3201-496f-aa0b-21578e269036 +:END: +#+TITLE: Update May 06, 2025 +#+DATE: <2025-05-06 Tue 17:00> +#+filetags: :update: + +* What have I been up to? +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 :) + +In the world of miracle-wm, I've been hard at work writing a new settings application for the compositor called [[https://github.com/miracle-wm-org/miracle-settings][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. + +I also implemented [[https://wayland.app/protocols/wlr-output-management-unstable-v1][wlr-output-management]] 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 [[https://github.com/artizirk/wdisplays][wdisplays]] to change the output configuration at runtime, which is pretty cool! + +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. + +Also - my cat who ate a sewing needle last year has turned two! π± diff --git a/_posts/sitemap.org b/_posts/sitemap.org index b5e96d9..202c055 100644 --- a/_posts/sitemap.org +++ b/_posts/sitemap.org @@ -1,12 +1,43 @@ #+TITLE: Matthew's Blog Posts -#+DATE: 2024-05-01 at 14:07 +#+DATE: 2025-12-29 at 13:03 #+HTML_LINK_HOME: / #+HTML_LINK_UP: / -- [[file:hello.org][Hello, Org]] created on June 20, 2023 +- [[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: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: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: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
\ No newline at end of file + #+end_sitemap_tag |