Show window icons in titlebar #4882
Comments
|
Sorry, this isn't something we're interested in. |
Why? |
|
We try to keep Sway simple. You're free to add this feature to a fork of Sway if you want it. |
What is simple and what isn't? How is showing a text simpler than showing an icon? |
|
Icon lookup is far from simple. Sway would need to implement it, then load the image (supporting multiple file formats), and render it. |
|
Wondering what #307 was about then |
|
@hasufell you could try something like this: |
|
Worth mentioning that upstream i3 has implemented the feature. |
|
As a workaround, you can name windows incorporating emojis, eg in sway's config: for_window [title="cmus"] title_format "🔊 cmus " And your font has to have emoji support, eg: font pango:Liberation Sans 21 |
Though this is a link to Airblader's fork, true upstream did indeed implement this in i3/i3#4439. |
|
FWIW, I don't really like the idea of this feature from a technical point of view. It comes at a significant cost: using the XDG icon spec to find the icon from the app-id, then load it (we need to support a variety of file formats), then upload it to the GPU for rendering. |
emersion
changed the title
|
Note, i3 doesn't need all of this, because X11 clients upload their icon pixel data themselves to the X11 server as a window property. Wayland doesn't do such things (for good reasons!), but that means more work for Sway. |
|
Yet another note, a way out of this would be to have a helper client responsible for rendering the titlebars. This would also allow users to arbitrarily customize the titlebars. As a bonus, this would remove the need for cairo/pango in Sway completely. This needs a lot more investigation before it can become a viable option, though. |
Very true, but this sounds like it could be really clever! |
|
Excited about the removal of cairo/pango as dependencies :) |
I believe that, for an implementation to be efficient, it should need to draw the titlebars into a surface itself (rather than pipe bytes to sway and have sway draw that), right? What do you think of drawing all decorations on this external helper (titlebars and borders). The default helper that sway ships can keep the current, very simple, implementation, but a potential third party one can add shadows and other eye candy without adding maintenance burden on sway. |
|
Yeah, that's what I had in mind. |
|
How do you imagine this working? A new WLR-specific Wayland protocol for signalling what needs to be rendered by the helper program + shuttling the surfaces around, or perhaps something more lightweight (just using wayland surfaces as a convenient render surface, the rest signaled out-of-band)? I'll be between roles soon, and might be interested in giving this a go. |
|
Basically the helper needs to render two things: borders, and titlebar. The titlebar in sway doesn't follow the same rules as more traditional (e.g.: xfce-like) desktops. For a window in a tabbed container, the titlebar should actually enumerate all the windows in the tabbed container, so the protocol needs to actually describe the three itself. I've seen other x11 window managers that something similar when it comes to tabbing arbitrary windows (e.g.: pekwm), so the wayland protocol may be reusable by other compositors (even if the helpers themselves are not necessarily all portable). Re regarding the size of the borders "surface". Assume a window has a 200x200px space. If the helper renders a 2px border, should sway resize the inner window to 196x196px? Does the helper render 200x200px with a transparent/ignored area in the middle? Or does it render four different surfaces (top, right, bottom, left)? I suspect the latter is more efficient. The helper could indicate a global "oh, my borders are all top:2px, bottom: 2px, left: 2px, right:2px", so sway knows how much it'll need to pad windows.. I think per-window border sizes would be far more problematic. Side question: Can borders for floating windows have alpha? I'm sure someone will eventually want to use this for shadows and such. |
|
For a first pass, would we really want to delegate all logic for configuring border sizes etc to the helper? could we keep that in Sway's configuration, and simply pass that global info (as well as the window information and the surfaces) to the helper for rendering? |
|
More generally, what should be the behavior in the case that the helper is 'slow' in rendering the surface and yeeting it back? My guess is that somehow, sway should avoid blocking frames and instead just paint the border/titlebar with the correct color as defined by the config? |
Maybe a bit off-topic, but what good reasons? Applications being able to dynamically update their window icon alongside their title has been a thing since the dawn of time, I'm not sure what exactly is the issue with communicating that along with the protocol. +1 for splitting off the titlebar/border rendering. I've been thinking about patching sway locally to modify the borders since I find them a tad boring. |
|
I'm surprised that people are able to use Sway quickly and efficiently without window titlebar icons. Having to visually scan and read text for dozens of window titles you have open wastes a lot of time and reduces productivity. |
|
Discussion about this on IRC: |
|
To summarize from chatting with the core-devs over IRC, we don't seem to have a great path forward:
So what do? The default (and implicitly accepted path) is to stay the course: maintain the status-quo where core textures needed to composite windows (ie: titlebars) require no synchronization with an outside client and are done in the hot-path. It doesn't appear that we have agreement amongst devs/contributors on changing that, and its a reasonable architectural choice to make, but it does imply that features like this arent possible. |
Sounds like this delivers perfect frames, at a price of never allowing out-of-compositor decorations.
Removing pango and fontconfig dependencies can also reduce complexity for sway.
I agree. How do other DEs delegate decorations without compromising on perfect frames? |
|
Also, could some wayland-protocol proxy do decorations and synchronisation on its own? That is, by exposing a different wayland socket to clients. |
They mostly don't.
Would be very complicated. |
Sorry, but can you elaborate on this a little? I haven't read the Wayland book, nor do I have any knowledge about Wayland's protocol design, but this seems like a rather odd/regressive design decision.
I understand that synchronization is required but why would this need to block the compositor? I don't see any issue with having the icon being rendered once/if/whenever the data becomes available. It can render the titlebars as they are now with no icon and if the surrogate process takes even say 10, 20, or 30 seconds to get the icon then so be it, just render it once it's available no matter how ridiculously long it takes. Having icons, even if they don't render immediately, is better than no icons at all. Also, I agree that delivering imperfect frames is unacceptable, I now understand the technical limitations surrounding this feature. |
No, this isn't the place to discuss this.
Synchronization doesn't mean blocking the compositor. It means that the updates of the client surface and the decorations are synchronized, and happen atomically, to ensure there are no glitchy frames displayed to the user. The main concern is that this adds substantial complexity. |
|
What are people's thoughts on designing the protocol in such a way that for simple window decorations clients like what sway would presumably ship by default, the consequences of a failure of synchronization are minor (either perfect or minimally imperfect frames), and users who choose to use fancier window decorations may end up with more noticeably imperfect frames if their decorations client can't keep up? As I understand, the state which would need to be synchronized between the compositor and the decorations client is:
The most likely culprit for noticeably imperfect frames is loss of synchronization in surface dimensions, which could cause resized containers to have unrendered regions of their borders, or in the case of e.g. center-aligned text and tabbed container titles, cropped or missing window titles. The maximally flexible protocol design would allow the decorations client to negotiate, for any container, how much space it gets to draw on any side. This approach is great for my personal agenda, because I'd like to co-opt the stacked layout to implement vertical tabs in the style of firefox's tree-style-tabs extension. However — An alternative would be to give the compositor more control over which decorations surfaces get to exist. Currently, as I understand (and I might misunderstand), you can categorize containers into two classes based on what decorations they have:
Here is an outline of a minimum viable protocol that would minimize the imperfections caused by failures of synchronization: The compositor gets to decide which decorations surfaces exist. Each container that gets decorations gets three surfaces: left, right and bottom borders. Additionally, each application window gets one decorations surface, namely its title. In order to accommodate resizing of containers without rendering obviously bad frames in the case of lost synchronization, each of these surfaces is larger than it needs to be. Window-title and bottom-border surfaces are all as wide as they might ever possibly be — maybe as wide as the widest output, maybe as wide as the widest row of pixels in the output arrangement. Left and right borders are similarly maximally tall. The compositor notifies the decorations client of the actual rendered regions of these surfaces at any given time, but the client is expected to draw something useful in the rest of the surface just in case synchronization is lost. The compositor never blocks on decorations redraws, instead always rendering the decorations surface clipped to the needed dimensions. Advantages
Disadvantages
That's my analysis anyhow. I lack experience with wayland and might well have missed something. |
|
So it seems that synchronisation issues are a blocker for delegating all decorations to a dedicated/privileged client. The original issue here is just about showing icons in titlebars. I'd like to re-focus discussion on that. I'm thinking on an approach as follows:
On the sway side:
This protocol is perfectly usable by other compositors too. FWIW, a well-written icon-manager-helper could also be cross-compositor. Some points worth discussing:
|
|
Just for the record, color fonts now can embed SVG documents which in itself can contain bipmap image data... It seems that drawing fonts is edit: This makes me think that perhaps implementing icons on the titlebars could be done by an external process that would transform the icon from the window into a font and return to sway the font to use as well as the glyph to use within the font, and this could be done. However, it seems sway has to be restarted completely (not just reloaded) to get it to accept a new font. There is probably a call somewhere to make to refresh the font list. |
Seems like a good idea, however I don't think we need to go to the length of drawing all the borders and corners. I'm perfectly fine having this fixed in sway or configurable by simple options. What we might need instead is to draw the content of the titlebar itself. The simpler version of the protocol could be:
This keep things simple. The only drawback compared to the current state is that when the titlebar is extended, there might be a loss of synchronization that would delay showing up the rest of the text, but it should not be that noticeable and if we want to separate the text rendering to a separate process, this is something can will necessarily happen (unless we take the decision to render all of the text even if not shown). Shrinking the titlebar would not cause any visual imperfection as the title would be clipped as of today. If we want to extend the protocol to draw the borders, the process that draws the decoration can draw a larger surface that could be cut in four (vertically and horizontally) and in place of the cuts, the compositor would extend the pixels. I do not really imagine a use case where the border could not be drawn like this. But then with drawing borders, we will want to also tell which parts are clickable and which parts should trigger a window resize, ... edit: for the simple version:
|
I like the idea of this; but manually setting each icon is very tedious. So I decided to make this repo: https://github.com/iguanajuice/sway-font-awesome Right now, it only adds icons to apps that I personally use. Please open issues for apps that I haven't added an icon for yet (which is a lot of them), if you're interested. |
I wrote a little rust app for this a while back also. It has a bunch of icons defined in the default config and I'd gladly accept PRs with more set. Setting icons in the sway config is probably preferable for a lot of use cases, but if you want to change the icon based on window title changes for instance (like to change a terminal icon to a vim icon), as far as i know an app is necessary: https://github.com/allie-wake-up/swaycons |
Why not? My first thought on how to implement icons in the titlebar would be to have a protocol to allow the client to give the compositor a surface to use for the icon, similar to setting the cursor shape. And allow the application to update the icon, so it can use it to indicate status. The problem with that is it isn't very useful unless most applications implement it. And since gnome only supports client side decorations it is unlikely gtk would support such a protocol. With the proposal for a separate decorations app, I'm not sure how it would know what icon to use. Does determine it based on the app id? If so, that means an app can't dynamically change the icon, or use different icons for different windows . Both of which I think are possible in X. How does KDE determine the icon to use? |
I generally find it hard to distinguish the type of window just based on the title. I'm wasting time reading titles and being confused about whether I'm switching to a console, browser window or something else. Workspaces alone don't fix it, they are only useful to group windows, not distinguish them visually. Icons fix this easily with little visual overhead.
There were several i3 window titlebar icon patches. Also see the screenshot.
I wasn't able to find an existing issue report about this.
The text was updated successfully, but these errors were encountered: