Sway: feature request: per window color

Created on 23 Nov 2018  路  18Comments  路  Source: swaywm/sway

Hello sway developers,

I have firefox-wayland running in docker-like containers and have multiple instances (different profiles/privileges/network access). I would like to decorate the window of specific instance with diffferent colors (unsecure -> red, work -> green, etc).

It does not look like sway supports per-window colors, and I'd be happy to provide a pull request for that.
I would be also interested in advice how to group and color all window from a firefox instance. I've seen for_window [id="nautilus"] border none but all my firefox instances come with the same id. Is there something available in wayland protocol (I haven't looked up at the protocol specifics yet)? Would it be possible to proxy wayland socket from a firefox-instance and provide more insight about who that is?

Any help would be more than appreciated :)

Thank you!

enhancement

Most helpful comment

Thanks for the consideration and feedback! An argument might be made that some features can't ever make their way into i3 because those use-cases (here: visual feedback on keyboard grabs/idle inhibiting) simply don't exist or are prohibitively hard to implement there. I've polished the PoC implementation a bit anyway and will carry it on above branch until it's proven its worth enough to maybe research feasibility and push for in i3 and then re-raise here.

All 18 comments

Just for information, https://github.com/i3/i3/issues/1879 concerns the same feature on i3.

It seems that i3 refused to add support for this feature, and suggests using title_format <span background="#ff0000">%title</span> instead.

I would be also interested in advice how to group and color all window from a firefox instance.
Is there something available in wayland protocol (I haven't looked up at the protocol specifics yet)? Would it be possible to proxy wayland socket from a firefox-instance and provide more insight about who that is?

I'm not sure how this could work. Maybe the PID could be used?

I tried the span trick but does looks supported in sway (I tried swaymsg title_format "<span background="#ff0000">%title</span>")

I tried the span trick but does looks supported in sway

You mean it's _not_ working?

yes, does not work. It displays the <span> in the title.

Oh, you just need to add pango: in front of your font name, to enable pango markup.

I tried with "font pango:DejaVu Sans Mono 10" in config (deja vu is installed) but does not work for me. According to sway -d it is loaded correctly, and doesn't show any error there.

I fixed support for pango_markup in #3179

For anyone needing the configuration syntax for this:

font pango:"DejaVu Sans Mono 10"
for_window [class=".*"] title_format "<span background='#ff0000'>%title</span>"

the pango_markup works, but only the text has background, no the whole window decoration, a window not giving any title would appear empty.

Thanks for sharing the pango markup trick. While having full titlebar background color would be cleaner and nicer-looking, feature-wise this is good enough.

I'd like to use title bar/border colours as visual feedback for active keyboard shortcuts (#5124) and idle inhibitors. The pango markup approach works but looks godawful. Would patches implementing per window colours be accepted?

Is there an i3 issue about this?

If i3 implements this, this is in scope for Sway.

There's a pretty differentiated discussion hitting all the pros and cons in i3/i3#1879 linked above. It does not specifically go into shortcuts and idle inhibitors though. From what I can tell it got as far as a PoC implementation and then got shot down wholesale in a benefit vs. maintenance overhead consideration. I'd be willing to do a PoC implementation for sway to allow the same benefit vs. maintenance impact assessment to be done.

PoC code now at https://github.com/michaelweiser/sway/tree/window-colours. Seems to drop right in and behaves exactly how I expected and wanted it to.

We don't add features like this unless i3 has them first.

Thanks for the consideration and feedback! An argument might be made that some features can't ever make their way into i3 because those use-cases (here: visual feedback on keyboard grabs/idle inhibiting) simply don't exist or are prohibitively hard to implement there. I've polished the PoC implementation a bit anyway and will carry it on above branch until it's proven its worth enough to maybe research feasibility and push for in i3 and then re-raise here.

I was searching for a way to set a different titlebar color depending on which seat has focus, and found this bug. So far when you use two keyboards and mice and set them up on different seats, only moving the default seat's mouse changes the titlebar color. Moving the second mouse into a different window may result in some client feedback (e.g. scrollbars becoming brighter, text selection color changing) but it would be much more useable if each seat had its own designated titlebar color so that each user can see what (s)he's interacting with. But maybe I can get the pango markup working that way somehow.

I think your stance that only i3 can add new features is rather limiting, isn't it? But this feature could be useful there too, since X11 also has multi-seat support.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ddevault picture ddevault  路  4Comments

jakubn551 picture jakubn551  路  4Comments

WhyNotHugo picture WhyNotHugo  路  3Comments

dnkl picture dnkl  路  4Comments

johanhelsing picture johanhelsing  路  3Comments