Something I mentioned on GitHub, to clarify someone who was confused as to why their feature request was shot down (even with a patch attached).

The window management code of sway is basically closed to further enhancements. This has been an unspoken policy for a while now. We only merge bugfixes and otherwise we track i3 releases upstream.

Expanding sway into a giant kitchen sink is not my goal. We need to at some point become conservative with our changes, or else the runaway complexity will ruin the software. Eventually sway should be "done", in my opinion.

There is still room for improvement, but that is mainly limited to the domains in which i3 is not: the parts of sway (and wlroots) which replace the role of the Xorg server. To this end, we're building improvements around screen capture, VR support, and so on. We also continue to see lots of investment in wlroots, and I expect it will continue to mature for a long time.

@sir Does this apply to the other elements of the swaywm repo: swaybar, specifically.

As you know pango stopped supporting pcf fonts and some people were upset by that, so I was thinking (on a longer term :D) to contribute a PR to remove pango in favour of some other rendering backend.

@sir also, would swayidle accept a PR to use some of the dbus mechanisms of suspending the idle timer if media players are running ?

@mariusor no pango, no dbus. There is a Wayland protocol for suspending idle

@sir pango is already there, that's what I wanted to replace. :P

Roger about the wayland idle protocol.

So features should be patched against upstream aka i3 ?

Also this means I will be able to go to sway from i3 whenever I want ? :)

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!