At the moment I am making a dynamic and intelligent tiling system that coexists with the mosaic as shown in the mockup and this has been a fairly wide road.
I have already achieved good results, but I think I will only have something that can be proved next year.
I initially used the Shelf algorithm to build the mosaic, but I ran into limitations I didn't like. I'm testing a hybrid approach: MaxRects algorithm augmented with some BSP algorithm features to improve space utilization and partitioning flexibility.
I need to weigh the pros and cons: a hybrid MaxRects with BSP improves space utilization and flexibility (fills gaps and eases reorganization) but increases computational complexity and processing cost.
Any thoughts?
Using the Shelf algorithm, I implemented an approach where windows are arranged with radial growth; exactly what I was looking for. This greatly improved space utilization and looks visually well-balanced.
Before the algorithm tried to complete the horizontal space of their "shelf" with windows before creating another "shelf". The look was very unbalanced and uncentric.
I was researching some articles about algorithms for collages and came across an interesting one: https://callistaenterprise.se/blogg/teknik/2025/06/11/genetic-algorithms-collage-creation/.
The proposal presented seems brilliant, as considering the concept of "collage" makes more sense than thinking about "mosaic" to solve this problem.
I tried everything: spiral packing, radial growth, bin packing... Each one promised to be "the definitive." The radial looked nice but had gaps. The spiral got stuck on edge cases. The bin packing ignored aspect ratios.
In the end, I went back to basics: horizontal rows with smart distribution. Windows arrange themselves in lines, respecting their original sizes. Simple, predictable, and it works.
Sometimes the elegant solution is the one that doesn't try to be brilliant. 🧘
Guys, MosaicWM is becoming more and more stable, so I would like to start having people testing it.
I have an issue reported by several users that, after the discussion in this thread¹, made me rethink how the Mosaic WM should behave:
#GNOME workflow is based on workspaces, and the most practical approach — as most people do — is one task per workspace.
+++
¹ https://github.com/CleoMenezesJr/MosaicWM/issues/7
also: https://github.com/CleoMenezesJr/MosaicWM/issues/13#issue-3713014865
- When an overflow occurs, should a new workspace be created at the end or adjacent to the affected workspace?
These are just the initial questions.
I heard "smart resize"?
The original idea for mosaic windows was that each window would open at its "ideal size," but that will take time to implement. Meanwhile, I propose a different approach to make tiling useful right away.
#GNOME's workflow encourages one workspace per task. I organize mine like this:
1. Terminal / Neovim
2. Browser
3. Messaging apps
4. Casual apps
+++
A simple change that when they reported it I couldn't unsee and had to rush to fix 🤣:
Layout of the mosaic in the overview. 🪟🫣
Some animations for moving windows between workspaces.
Something from the original mockup I always wanted: windows sliding in from outside, "pushing" the existing mosaic, making the bouncy animation feel natural!
Thanks to @jadahl for pointing me to configure + first-frame signals. Now windows moved between workspaces slide in from their origin direction with momentum. Feels so much more physical! 🎯
These past few days, if you've been following Mosaic WM, you might have noticed... nothing visually new. No flashy features. No dramatic UI changes. And that's exactly the point.
Sometimes the most impactful work is invisible. I've been deep in what I like to call "refinement mode" (replacing polling) loops with event-driven signals, implementing coordinated pause mechanisms between competing systems, fixing race conditions that only appeared under specific timing conditions.
[1/6]
None of this shows up in screenshots. But you'll feel it. Lower CPU usage. Smoother animations. Fewer edge cases where things just... don't work right.
Early versions of Mosaic were functional but had rough edges. And that was okay! Seeing something work, even imperfectly, generates motivation. It's proof that the idea has merit. You can show people. You can get feedback. You can iterate.
[2/6]
If I had waited until every edge case was handled before show it, this project might never have seen the light of day. Perfectionism is the enemy of progress.
Still About Fun! With all this technical talk, it's easy to forget: the goal is still to have fun.
[3/6]
Mosaic WM exists because I wanted a tiling experience that felt native to GNOME. Something that doesn't fight the desktop, but enhances it. Every optimization, every bug fix, every architectural improvement serves that goal: making window management disappear so you can focus on what matters.
[4/6]
I'm genuinely happy about the people who have found this project. Keeping things low-profile was intentional (and it paid off). The contributors who showed up weren't just trying and moving on. They were testing, reporting, discussing. Quality feedback from people who actually care.
Every bug report that starts with "I noticed this edge case..." or "What if we tried..." is a gift. It means someone spent time understanding the project deeply enough to contribute meaningfully.
[5/6]
Thank you. Seriously.
What's Next? The foundation is solid now. The performance is respectable. With this groundwork, adding new features becomes safer and faster.
But for now? I'm enjoying the process. Building something useful, learning along the way, and sharing it with people who appreciate thoughtful software.
That's the whole point, isn't it?
[6/6]
That's been a nightmare.
Working with virtual canva along with mutter's limitation of not being able to position windows out of sight has been very difficult to the point of even discouraging the idea.
I first started trying to use the same approach as PaperWM which is to clone the windows, but dealing with multiple hidden Windows / clones was just terrible.
Most of us still use FHD monitors. Mosaic windows are a great idea, but the original approach was designed with larger screens in mind.
[1/5]
It works well on those, but in daily use I and other testers ran into the same issue: windows more often don’t fit into the mosaic layout than the other way around, so we end up creating dozens of workspaces.
I tried a smart-resize approach, which, modest claim, worked well initially by reducing the number of overflows. Still, on smaller-resolution screens the available space becomes cramped and windows feel "squashed."
[2/5]
The goal is to reduce friction between the user and window organization and to encourage the "one task = one workspace" habit: open the windows and start working without anything getting in the way.
[3/5]
So here is Plan C: make the workspace a canvas that effectively doubles the available workspace and lets you scroll through windows. If windows fit in the viewport, nothing changes, but when you open more windows, instead of overflowing we expand the virtual space. Only after you reach that virtual limit does overflow occur.
[4/5]
This idea is based on this mockup (https://github.com/CleoMenezesJr/MosaicWM/issues/35), which I tested and adjusted where real use revealed problems.
[5/5]
I'm stuck and it's already starting to stop being fun.
Working without direction is discouraging, and every time I try new ideas, I always run into another big problem.
You can now enable or disable mosaic tiling on a per-workspace basis!
- Toggle mosaic directly from the Quick Settings
- Disable tiling on specific workspaces while keeping it active on others
- The top bar indicator reflects the current workspace's state (on/off)
@chris I haven't fully warmed up to the design of the Quick Settings yet. While the dot appears to be an improvement, I believe there could be a better way to indicate the active workspace. Additionally, I would like it to be more informative about what happens when clicking on the switch. Specifically, there should be a visual cue to show that the workspace has floating windows or a mosaic layout.
Overall, it’s a great start, but I hope to come up with more ideas for enhancing it.
🍿 I added a workspace switcher popup to visually notify when an automatic workspace change occurs, such as when a window does not fit in the workspace due to overflow or when the last window of a workspace is closed.
The secret is just starting! In Mosaic WM, I began with polling for everything, it wasn’t "perfect," but seeing it work kept me going. 🚀
I just refactored everything to GObject and deterministic signals. The code is now sleek, but I’m glad I didn’t wait for perfection. Build first, optimize later. Growth is the best motivator! 🛠️✨
Maintaining Mosaic WM and my other open source projects has become a real part-time job. If you enjoy my work on Linux/GNOME stuffs and can chip in, please consider becoming a sponsor! 🧱✨
I implemented a sequential evaluation queue for Mosaic WM, effectively resolving race conditions that arise with rapid spawning of windows.
Now, windows wait for the positioning of the previous one before the next evaluation, ensuring balanced layouts. Additionally, dynamic scaling of safety timeouts has been introduced, preventing premature rejections under heavy load.
P.S.: Ignore any glitches from the screencast. 🫣
Rewrote the drag reorder system from scratch.
Previously, every cursor movement during a drag ran a full layout simulation to check if the swap was valid🤢, double the computation, and rejected positions stayed locked for the entire drag session. Now, all valid layouts are pre-computed when the drag starts. While dragging, the cursor just looks up ready-made positions.
I've got a feature for you 🫵: hold Shift when you open a window, and it'll open floating.
Mosaic WM's smart resize just got a full rewrite.
Instead of shrinking windows step by step and waiting for Mutter to catch up each time, it now uses get_min_size()/get_max_size() from Mutter 50 to binary search the optimal scale factor upfront (layout simulations fully synchronous).
All polling machinery are gone (-770 lines) _Everything that I pray praise the Lord_ 🎶🎶.
⚠️ Important notice for Mosaic WM testers:
Starting from commit b96f204, #Mutter 50+ is required. The smart resize system was rewritten as mentioned in the toot above.
If you're on an older version, stick to the previous commit. This isn't just a preference, the extension won't work properly without these APIs.
@Ackernym It has been a significant effort in refactoring. Many workarounds and historical issues have been addressed. Since these improvements are under the hood, it's not particularly interesting to post about them, but certainly for those testing it, the experience feels more stable and optimized.
I’ve been following the philosophy of starting first and then improving and that’s what has been working for me. 🙌
Cleo Menezes Jr. 🌵
Chris Hayes
Ackernym
Felicitas Pojtinger 🌅
Rapha
Angelo Verlain
Chris Wood
Cassio Pereira
destabilize enemy nations