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.

https://github.com/CleoMenezesJr/MosaicWM

#GNOME

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. 🪟🫣

#GNOME #TheMosaicSaga

Some animations for moving windows between workspaces.

#GNOME #TheMosicSaga

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! 🎯

#GNOME #TheMosaicSaga

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]

#GNOME

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]

#GNOME

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]

#GNOME

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]

#GNOME

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]

#GNOME

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]

#GNOME

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]

#GNOME

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]

#GNOME

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)

#GNOME