Is this a WM by any chance?

[Joe23232]

Forgive me for my lack of understanding but is this a window manager by any chance? Am I able to write my own WM in a high level manner with smithay?

[kchibisov]

Forgive me for my lack of understanding but is this a window manager by any chance? Am I able to write my own WM in a high level manner with smithay?

It's a toolkit to write Wayland compositors. So you'll be able to build your own Wayland compositor with those tools. There's an example Wayland compositor called anvil in a source tree.

[Joe23232]

I see, do you know any WM that uses anvil or utlise smithay compositor and the WM is also configurable in Rust other than waycooler as that project is dead?

[kchibisov]

Not really.

[Joe23232]

I see. I have a question, if I go to dwl (which is supposed to be a dwm wayland replacement), what does it claim dwl is a compact, hackable compositor for Wayland based on wlroots. yet it is being used as a WM? I am a bit confused with this?

[Joe23232]

@kchibisov One other question, is smithay an alternative to dwl?

Can smithay manage windows like dwl for wlroots?

[elinorbgr]

Under the wayland model, the display server and the WM are actually the same program, which is called a wayland compositor. This is different from the X11 model, where the display server (Xorg) and the WM are two different programs.

So sway, is both a display server and a WM, same goes for dwl.

The task of a display server is quite large though, and it requires a lot of heavy-lifting and deep integration with the OS. All this work is fairly generic, but still complex. So some people develop libraries to abstract that for compositor writers. wlroots is an example of such a library, smithay is another.

Hope that clarifies. :)

[Joe23232]

Under the wayland model, the display server and the WM are actually the same program, which is called a wayland compositor. This is different from the X11 model, where the display server (Xorg) and the WM are two different programs.

Ah I see, that makes sense. So then what is XWayland then? Does it port X apps and get it to work on Wayland? Would it benefit Wayland?

So sway, is both a display server and a WM, same goes for dwl.

I heard that both sway and dwl uses dwlroots, so they are just wrappers on top of dwlroots?

The task of a display server is quite large though, and it requires a lot of heavy-lifting and deep integration with the OS. All this work is fairly generic, but still complex. So some people develop libraries to abstract that for compositor writers. wlroots is an example of such a library, smithay is another.

I see

Hope that clarifies. :)

Thank you mate, that really does clarify a lot mate :)

---

Do you know any projects that utilises smithay which is an alternative to dwl? Is anvil one?

[elinorbgr]

So then what is XWayland then? Does it port X apps and get it to work on Wayland? Would it benefit Wayland?

XWayland is a compatibility layer to run X apps in a Wayland context. It presents to itself to them as a normal X server, and connects to the wayland compositor as a special wayland client, and does the protocol translation in real-time.

I heard that both sway and dwl uses dwlroots, so they are just wrappers on top of dwlroots?

Both internally use wlroots yes. They add their own logic on top of it to reach their own design decision. As a rough analogy, you could say that wlroots plays to them the same role GTK or Qt could play for a GUI app.

Do you know any projects that utilises smithay which is an alternative to dwl? Is anvil one?

anvil is the example compositor provided in Smithay (the anvil directory in smithay source tree). While it works reasonnably fine, its window management capabilities are quite barebones.

I'm not aware of a project that currently uses Smithay and can be used as a daily driver alternative to sway or dwl, though. We are not as mature as wlroots.

[Joe23232]

XWayland is a compatibility layer to run X apps in a Wayland context. It presents to itself to them as a normal X server, and connects to the wayland compositor as a special wayland client, and does the protocol translation in real-time.

I suppose that would cause some overhead.

Both internally use wlroots yes. They add their own logic on top of it to reach their own design decision. As a rough analogy, you could say that wlroots plays to them the same role GTK or Qt could play for a GUI app.

Ah I see.

anvil is the example compositor provided in Smithay (the anvil directory in smithay source tree). While it works reasonnably fine, its window management capabilities are quite barebones.

I hope it can be developed further one day.

I'm not aware of a project that currently uses Smithay and can be used as a daily driver alternative to sway or dwl, though. We are not as mature as wlroots.

I see, thanks for letting me know.

---

I am in the process of learning Rust, maybe one day I could build on top of anvil. One of the things I was thinking of doing is adding decoration around the windows. Is it possible to use something like processing-rs or some shape drawing tool Rust crate to draw the shapes and display it through Wayland?

[elinorbgr]

XWayland does cause some overhead, but as far as I know it's relatively small. And anyway, that's mostly the only way to run X11 apps in a Wayland environment.

Anvil can definitely be further developed, but at its core it remains an example compositor. It's only meant to show how Smithay can be used and to test and debug Smithay, as such it won't integrate fancy WM features for example. A real compositor built on Smithay would be an other project. For example, this is what @Drakulix plans to do with his compositor Fireplace (currently on hiatus waiting for Smithay to be mature enough for him to migrate to it).

Adding decorations to windows could definitely be done in anvil, and it would mostly be done directly in the OpenGL code anvil uses to draw its content, as well as integrate the logic for user interaction with the borders. To do this properly, we need to add helpers into Smithay to manage the xdg_decoration protocols, so that clients can negotiate between client-side and server-side decorations, and anvil can draw decorations only for client that request it.

I don't know about processing-rs, and we'd need to discuss what it would give in practice as apposed to the bare glium we are currently using. Though if you're interested in adding server-side decorations supports in smithay and anvil, we would be happy to mentor you on that. :)

[Joe23232]

For example, this is what @Drakulix plans to do with his compositor Fireplace (currently on hiatus waiting for Smithay to be mature enough for him to migrate to it).

Oh that is interesting 👍 I might end up using it then :) would you happen to know if Fireplace will be capable of adding decorations around the window?

Adding decorations to windows could definitely be done in anvil, and it would mostly be done directly in the OpenGL code anvil uses to draw its content, as well as integrate the logic for user interaction with the borders. To do this properly, we need to add helpers into Smithay to manage the xdg_decoration protocols, so that clients can negotiate between client-side and server-side decorations, and anvil can draw decorations only for client that request it.

I see

I don't know about processing-rs, and we'd need to discuss what it would give in practice as apposed to the bare glium we are currently using. Though if you're interested in adding server-side decorations supports in smithay and anvil, we would be happy to mentor you on that. :)

Thank you mate, but I may want to go with Fireplace since Anvil is used as an example whereas with Fireplace it is used for actual use rather than an example. But yeah I hope I can contribute to the project one day after I can learn some more Rust and have more free time :)