Cleo Menezes Jr. 🌵For fun: partially implementing the Moisac Windows concept by @tbernard.
https://blogs.gnome.org/tbernard/2023/07/26/rethinking-window-management/
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.
Some momentum.
Using mosaic windows is so good that going back to using overlapping windows feels strange.
It's still quite experimental, but I think I can start sharing it to begin getting some public testing.
https://github.com/CleoMenezesJr/MosaicWM
https://github.com/CleoMenezesJr/MosaicWM
The solution I found to alert the user that the window they are resizing will overflow and no longer fit in the workspace was to make it opaque.
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?
In the end, it was worth trying to improve the algorithm I already had rather than attempting to implement something so complex that didn't meet my expectations.
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
But that workflow quickly breaks: depending on the size of a newly opened window, the workspace may overflow and create more workspaces. To mitigate this I implemented: check the next workspace for available space; if it fits, use it; otherwise create a new workspace.
My first idea to improve this: instead of checking only the next workspace, check the subsequent workspaces; and instead of creating a new workspace adjacent to the current one, create it at the end. I did consider a downside: someone might open a casual window and it would end up far away. I solved this by remembering the last visited workspace before moving to the new one — so when that casual window is closed n the workspace becomes empty, we return automatically to the last visited workspace
Now the main problem: people use tiling/window managers that auto-organize windows so they don’t have to spend time arranging them. I feel these goals can conflict:
- If I organize my workspaces by task, how should overflow be handled when it creates additional workspaces?
- If a user knows which workspace they’re in and opens an app, should windows auto-resize to fit the workspace and only create overflow if there’s truly no room?
- If we resize windows when another is opened, how should we arrange them? Should larger windows shrink enough for the smaller one to fit?
+
- If a user knows which workspace they’re in and opens an app, should windows auto-resize to fit the workspace and only create overflow if there’s truly no room?
- If we resize windows when another is opened, how should we arrange them? Should larger windows shrink enough for the smaller one to fit?
+
- 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]
Jacob Scharmberg@CleoMenezesJr scrollable?? Would love that! Using niri atm but would seriously consider using this!
@jacobscharmberg I'm trying to achieve something, but it's been very difficult. This is the first progress I've made in 3 days.
@CleoMenezesJr thanks for the hard work. Your proof of concept looks amazing so far!