Enhancement/Taskbar

[Anakael]

It's isn't complete now, just to assign to me. I'll force this feature over two weeks.

[Anakael]

Does anyone have an idea how to pass .svg to output? (For app icon)

[Alexays]

It's ready for a review?

[Anakael]

Almost. There is TODO list:

• possibility to configure output format(text/icon/both)
• limit the geometry for not collizing with others widget on bar.

[Anakael]

I think it's ready to review. Logic for management geometry is too complicated for one PR.

[psokovykh]

Doesn't work for me, unfortunately. Some apps (like xterm, termite [possibly every terminal], telegram-desktop, yed [application for drawing charts] and more) miss their icons.

Fails to show icons of floating windows in taskbar (which is indeed needed).

Sometimes misses buttons for random non-floating windows too (and it randomly changes when I switch them from floating to non-floating mode).

[Anakael]

As for now the way we get icons is pretty awkward. It's caused by a lack of meta-information of windows in Wayland. The code uses "window_properties" from I3IPC which is supported only for Xwayland views. After some researching, we ended up with writing separated daemon because the functionality of getting icon by PID(the only we consistently get from I3IPC for Wayland view) is highly demanded by the community and other developers. It should be daemon for recognizing run-time config updates.

If we successfully write such daemon, will you mind adding it as a (possibly optional) dependency for waybar?

[psokovykh]

Of course, we can write such functionality within just taskbar, and that's it. But ability to get icon by PID rapidly (without repeatedly parsing .desktop files, and themes folders and so on) is of course needed by other modules (not current, but, maybe, future ones). So, we can write separated library within waybar. But there are also other applications, for which the functionality is needed (for example, something like alt-tab handler, or dmenu-like-tweaks). Yeah, we can write public api within waybar, but

1. It's kinda not the goal of the project, I guess, to maintain such APIs
2. It's weird for small utility to be dependent on something like waybar.

So writing separated package, on which waybar can be depened (mb optionally, only if user need something like the taskbar), and also other applictions can be depended is the best way I can see.

We with @Anakael developed consistent vision of how such daemon should work, so, there will be news soon.

[Arnaudv6]

Hello @Anakael and @Dokel, thanks for this work, and you general approach!
Have you been in touch with wayland-protocol guys (@emersion) maybe to discuss the icon matter?

As far as I'm concerned, taskbar functionality is already relevant without icons: icons are a plus.
I'm all for merging this work without waiting for good icons support.
Ability to drag something (i.e. a file from file-manager) to an app' button in taskbar to un-minimize and raise said app is central to me though. (I did not test if this works yet).

[emersion]

Icons for wayland apps should be retrieved via their app_id. You'd need to do the whole .desktop/theme dance, but you can cache the results.

[Arnaudv6]

Thanks @emersion.While I'm at meddling, https://gitlab.freedesktop.org/ddevault/fdicons This might be of interest ?

[AGCaesar]

Glad to see you are still working on this! I would love to switch to sway/waybar soon :)

[Alexays]

Superseded by #692
You can improve the module if you want 😃