Add border images

[fluix-dev]

Everything has been moved to my fork where I'll be adding adding more flashier features to Sway. I'll be updating the README there shortly to reflect the latest changes.

To view the previous versions of this comment, click the arrow beside Edited in this comment's header.

[mortie]

There seems to be some artifacting with fractional scaling. There's a thin border around shadows on my 4k display scaled to 1.5x:

[markstos]

I like the idea of a custom border solution, but I wonder if this is the way to go about it.

I envision a config file command that allows me to set a filter command for windows. The filter command would take the window as input return and return an updated image as output, possibly with a border, drop shadows, or transparency. One implementation of a filter command might allow me to define some CSS which describes how a I might like a border or drop shadow to look. Perhaps in-memory the filter command would take those CSS commands and essentially pre-render a border effect so an effect can be be very quickly applied to windows without recalculations.

I admittedly know little about how compositors work and if my idea is even workable with Wayland, but I'll say that managing custom borders through a folder of 8 static images is not appealing.

[fluix-dev]

I envision a config file command that allows me to set a filter command for windows.

This solution is meant to avoid exactly this -- 16 config options for everything you want, although that may be more intuitive.

One implementation of a filter command might allow me to define some CSS which describes how a I might like a border or drop shadow to look.

There's nothing that can parse and render CSS in Sway at the moment and adding this would be a huge task.

I'll say that managing custom borders through a folder of 8 static images is not appealing.

While this may not be a huge improvement for you, this may become only a single image.

[markstos]

This solution is meant to avoid exactly this -- 16 config options for everything you want, although that may be more intuitive.

I envisioned just one config option added to sway-- to specify a filter. Adding a drop shadow in CSS certainly doesn't take 16 configuration details either:

#example2 {
  box-shadow: 5px 10px #888888;
}

There's nothing that can parse and render CSS in Sway at the moment and adding this would be a huge task.

I'm not suggesting that Sway learn how to parse CSS. I'm suggesting an external filter command, where one possible implementation would to be to use one that understands CSS. Another filter command might load a directory containing 8 static images. Rust, Python and other languages have CSS parsing libraries.

[mortie]

I'm not suggesting that Sway learn how to parse CSS. I'm suggesting an external filter command, where one possible implementation would to be to use one that understands CSS. Another filter command might load a directory containing 8 static images. Rust, Python and other languages have CSS parsing libraries.

I'm not sure I understand. What would the "filter" command do? Would it run once on startup/config change and deliver shadow images? Would it run once time a window changes and return a pixel buffer with filtered results? Would it somehow be loaded into the Sway process and provide shaders or something?

How can a "filter" thing be an external process in a system which needs high performance GPU-accelerated rendering?

[biqqthiqq]

perhaps related to the damage tracking issues, but I'm getting this when changing a floating window to tiled, and then manually positioning them under each other.

[markstos]

I'm not sure I understand.

@mortie To be clear, I'm not sure I understand enough about compositors enough to know if my idea is good or viable. Primarily, as a Sway user I'm expressing that it seems like there ought to be a better way to declare the border style I'd like besides providing a directory of images. Perhaps I would feel differently if there was a companion tool to make it easy to generate such a directory of images.

[fluix-dev]

perhaps related to the damage tracking issues, but I'm getting this when changing a floating window to tiled, and then manually positioning them under each other.

No, this is actually an issue with which container is getting borders drawn. Can you run swaymsg -t get_tree and provide the representation of that workspace. Feel free to remove the container on the right (in the image) so it's just the one with extra borders.

Edit: Disregard, I've found the issue.

[ddevault]

Giving this the executive NACK. Feel free to keep working on it and incorporate it into a fork, but it's not desirable upstream.

[mortie]

@ddevault What do you feel about the concept of shadows and such in general? Is the NACK just for this particular approach? If so, what rough requirements do you have for an implementation of border shadows?

[ddevault]

This is a general NACK to any flashy features of this sort. I want sway to be simple and reliable going forward, not to perpetually grow new shiny things. We ought to focus on reliability, performance, and improvements to what we already have. Sway upstream needs to grow up from the cool new kid on the block into the reliable mainstay of the open-source desktop. This isn't the first feature to get NACKed for this reason, and it won't be the last.

And again, I would be supportive of a sway fork which adds these sorts of flashier features. I'm certain there'd be demand for it.

[fluix-dev]

We ought to focus on reliability, performance, and improvements to what we already have.

Understandable.

Feel free to keep working on it and incorporate it into a fork, but it's not desirable upstream.

Yep, I'll do exactly this, as planned before.