For fun: partially implementing the Moisac Windows concept by @tbernard.

https://blogs.gnome.org/tbernard/2023/07/26/rethinking-window-management/

#GNOME

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

Photo Collage Generation Using Genetic Algorithms | Callista

Callista Enterprise - seniora IT-arkitekter och systemutvecklare inom Java, öppen källkod, agil utveckling och systemintegration

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

Unexpected overflows to new workspaces · Issue #7 · CleoMenezesJr/MosaicWM

Current behavior I already have one window open. When I open another window, it sometimes opens on a new workspace and sometimes not. This is quite confusing. Expected behavior It opens on the same...

GitHub
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?
+

- 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

+++

I already know where everything is and my windows usually open at the right size, so overflow is rare. But new users can find it frustrating to adjust windows until the layout is “perfect.”

Proposal: before checking whether a window fits the workspace, automatically try to resize it to fit. If a user opened an app in that workspace, they likely want it to fit there. Windows do have minimum sizes, so some overflow will still occur, but it would be less common for new users.

This is still experimental, no commits yet, just advanced tests.

What do you think?

@CleoMenezesJr I do find it annoying when I’m on a workspace and the window almost always moves to a new one. On the other hand, I’ve experimented with many windows in a workspace and it is effectively just mobile phone apps at that point, which I also don’t like. (1/2)
@CleoMenezesJr But, I do want to play around with automatically resizing. I imagine that I’d rather it open in my current workspace and adjust each app’s size in one space, rather than the current workflow of swapping between workspaces, trying to adjust both apps until they hopefully fit into one workspace. (2/2)
@CleoMenezesJr (3/2) I’m not sure what would be best though. I’ve also been trying to just lay back and let it do what it wants and see how that feels. I really like the idea though, i’ve been waiting for this since it was first announced.

@gnuntoo thank you for your feedback:

If you wanna try this new feature and talk about it, check it out:

https://github.com/CleoMenezesJr/MosaicWM/pull/21

feat: Implement Smart Resize and Reverse Smart Resize capabilities by CleoMenezesJr · Pull Request #21 · CleoMenezesJr/MosaicWM

Description This PR introduces the Smart Resize feature set, designed to dynamically adjust window sizes to optimize workspace utilization and significantly reduce unnecessary window overflows. It ...

GitHub

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

Speedrun any%: get more commits than stars. 🤣🤣

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

Playing around with an idea. 👀

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.

Now I'm using an approach where I use a virtual layout and position the windows at the coordinates of that canva and literally crop the windows to appear or not appear on the screen. That's the idea I've been pushing the furthest.

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]

@CleoMenezesJr Here's an alt-text description of the image:

The image depicts a computer screen showing a software development environment, likely for a project named "Muttermode". The interface is dark-themed and features multiple windows and panels, overlaid on a background image of a nebula or starry sky. On the left is a window labeled "New Document" with options for "Problem" and a lightning bolt icon suggesting a new project. A central panel displays a calculator interface with numerical and operational buttons, and a dropdown menu set to "Portuguese". The right side of the screen shows a sidebar with a list of "Apps" including options such as "Ptyxis," "Errands," "Calculator," "Pika Backup," and "Steam", with a numerical indicator reading "16 Runnin…" at the top.

Here is a more detailed breakdown of the visible text:
“Muttermode Development Kit”
“27°C Wed Dec 17 17:35:42”
“New Document”
“Problem”
“Auto”
“Portuguese”
“0/1000”
“Translate”
“Apps”
“Ptyxis”
“Errands”
“Calculator”
“Pika Backup”
“Steam”
“16 Runnin…”

Provided by @altbot, generated privately and locally using Gemma3:27b

🌱 Energy used: 0.182 Wh

@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!
@CleoMenezesJr You scrollin'?
@Fingel playing around with the idea.
@CleoMenezesJr I am a big fan of PaperWM but I think an extension can only go so far. Still impressive what it can do. This looks great nice work!
@CleoMenezesJr I think what applies here is a saying that'll stick with me as a dev:
Make it work. Make it correct. Make it fast.
You got to stage 2 and 3 now ! :-D
@CleoMenezesJr @jadahl your extension is starting to look really, really similar to what appeared on Tobias' blog post. What would you say is still missing, until it's 1:1?
@frandavid100 Currently, there is a need to address behaviors that the blog does not cover. Improvements are required in the smart resize algorithm, which serves as an alternative solution for the "ideal window size." This is currently limited by the complexity of implementing it in the near future. Additionally, there is a need for intelligent tiling that recognizes patterns and applies them, such as in the exemple of vertical tiling with three windows.

@CleoMenezesJr @jadahl I thought I'd never care to get into tiling on any deeper level due to the amount of new learning involved while my current workflow doesn't really feel too bad.

However, you might just be the first person to convert me, this work looks fantastic!

@Isofruit I'm really glad to hear it. Hope to see your feedback soon.

@CleoMenezesJr @jadahl

Sei trabalho está ficando incrível, Cleo!

@_mmiller valeu, meu nobre! ta sendo legal fazer.
@CleoMenezesJr I used it today for a few hours. I had the exact same issue, and unfortunately, I ended up with too many workspaces. I'd be really happy if existing windows could be resized or rearranged to make room for the new window within my workspace. I think it would get annoying when windows are partially invisible because they're spilling out of the workspace. That's kind of the point of this extension – to fit everything into my view.
@CleoMenezesJr There is a problem when windows really don't fit. At one point, you need to have another workspace. In that case, I'd like to have the new workspace next to the current one.
@romix Thanks for your feedback, it's something I've been thinking about. take a look:
https://floss.social/@CleoMenezesJr/115698907040271882
Cleo Menezes Jr. :verified: (@[email protected])

Attached: 1 image I heard "smart resize"? The original idea for tiled 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 +++

FLOSS.social
@CleoMenezesJr IIRC we had discussed this in Brno and the idea was to add a workspace next to the one opening the window, so that they are kept tied
@CleoMenezesJr Wait, doesn't app already move to new workspace on maximize like MacOS?