Wlroots taskbar #2046
Wlroots taskbar #2046
Conversation
This is an abstract interface to operate windows and workspaces
- Move WindowProperty enum to lxqttaskbartypes.h
This model will manage the tasks shown
Also use it to get window icon
- Don't rely on global screen coordinates - This will be needed for future Wayland port, Where we don't have global screen coordinates - Keep compatible behavior on X11
This new window propery flag is needed to notify geometry changes
- It is now a global instance
This will be used to avoid crashing panel in case no backend could be created. A warning message will be printed in this case.
That's correct. Wlroots does not support urgency hints, except for probably what is being transmitted from xwayland. |
|
Found the cause of incorrect icons. For example, although the icon of Falkon is just I think this approach is used in Plasma-Wayland. However, Waybar does it differently and finds the original icon. All in all, this isn't an important problem. EDIT: On second thought, even if it's what Plasma-Wayland does too, it is a problem because it affects too many apps, especially when apps have weird app_id'a that aren't reflected by their desktop entries (like qpdfview and screengrab). |
|
@tsujan I doubt you if you need an icon named
Edit: Edit2: |
It is with Waybar, but not with this PR. |
According to a previous comment of yours, |
I see.. I was under the assumption that |
|
(1) isn't compatible with Qt. So, I guess the icon name should be extracted from the desktop entry, as is done in other places of lxqt-panel (like Quick Launch). |
Yes, and no. With Quick Launch, things are easy: you know the desktop file name before hand. So all that you need to do is extract the icon name, and then the icon. In our case, we have a more complicated situation. As you've noticed, we have a lot of apps that do not report a "proper" app-id. So we need falbacks, and fallbacks for our fallbacks. That is the reason why that code is that long. With that, I have managed to get icons for most of the apps - QPdfView and VritualBox are exceptions. Their app-ids are so bad our fallbacks are just not good-enough. |
|
To complicate things when reporting missing icons to sfwbar we found that some app-id's on debian are different than on arch, for example thunderbird... |
|
@tsujan I have updated the code to get the icon. It's essentially the code I linked above. You should see some improvements in the icons. |
|
The latest commit fixed most generic icons of the list above, remaining only
This code should go also to the plasma plugin no? |
|
Found that the setting
does nothing now on wayland. |
I confirm @stefonarch's observation. Yes, it's definitely an improvement. Some icons that weren't shown are correct now. But, for example, those of qpdfview, speedcrunch and screengrab aren't yet (they are LXQt's fallback icon |
|
@marcusbritanicus, a word about your last commit: You don't need to search in directories for icons. All you need is find their correct names; the rest should be done by EDIT: I mean |
Qpdfview has no issue here, but I'm not sure if I didn't make some hack for it. |
I do not remember why exactly I had to add that code: if I remember correctly, it was some legacy x11 app which had its icon installed to If you can confirm that |
@tsujan @stefonarch Following are the app-ids (and desktop names) reported:
You can see that in each case, the issue is with the app. The app-ids do not match the desktop file names as they are required to. screengrab's app id is so convoluted, I am wondering if it's a typo. If screengrab is an LXQt app (as it appears to be), I suggest we call Edit: |
|
As for screengrab it's a non-issue as it works actually only under x11. We should or update it to include the relevant wayland protocols or show a message "Not supported actually under wayland". As for qpdfview I see I've added some custom icons |
@stefonarch The wayland protocol is sadly insufficient at the moment. We can capture the whole screen or an area. But capturing windows is not yet possible. The speed at which work on wayland-protocols is progressing, I would not be surprised if it takes a decade for a wayland screengrab protocol to become available. 😆 But yes, I am willing to make a preliminary attempt at including wlr-screengrab protocol in the code. It is not very difficult to do that. It should work on all compositors that implement this protocol. |
Nice! Opened lxqt/screengrab#366 before.
My wshot (in bash) supports window capture on sway, wayfire and hyprland by using their cli tools. |
@marcusbritanicus, yes, it does. It follows Freedesktop standards.
I know what you mean. But we can't tell users that they should create this or that desktop entry for this or that app to have a correct icon on the task-bar, because
That's not the point. We need to find out how Waybar does it and improve our task-bar. |
|
Anyway, IMHO, fixing of the problems mentioned at #2046 (comment) may have priority over this, namely,
|
Can we use XDG Portal which should have a "Capture" protocol? Can't remember the exact name, maybe ScreenGrag or something. |
|
Please don't add comments that are about another app. |
That is great. In that case I can happily replace
I know we cannot tell the users that it's the app bug and forget about it. But attempting to "fix" an app's problem by making special provisions in the code is rather too much. Instead, we can make a simple package (open a repo) which ships desktops or icons that fixes issues with these apps. @stefonarch has added a few icons with suitable names for qpdfview, including
I would like to disagree. Our taskbar is near-perfect as it is. I would again like to re-iterate what I said previously: (1) Open a bug report for the particular app. (2) Until the app fixes it, ship an icon or desktop file that fixes the issue (lxqt-wayland-fixes). Let's be open about this - if an app misbehaves, we tell people that it's the problem with the app, and not try to cover it up using code in our task-bar. |
|
I just remember to have those generic-icon chasing lived already non only whit sfwbar but also together with @selairi for yatbfw time ago. It's probably a lot easier ship fallback icons than make the code catchup every bug in apps for we are not responsible. If waybar has a good system to catch everything up we could look at it, but as said every other panel suffer those issues too. |
|
At the end it's more or less the same: shipping an icon for an app or adding a lookup loop for it. It looks like for both
|
|
Just noticed that the "active" window state is also reset when changing tab in browser, due to changing button text as seen in filemanager and fpad. |
This PR adds a generic wlroots backend support for the the taskbar and desktop-switcher plugins.
@gfgit: I took lxqt-panel:git, then merged #2041 and #2043. I hope this is what I was supposed to do. If something's amiss, please do let me know.
One of the issues we face is the wlroots backend does not support virtual desktops. However, various compositors (wayfire, sway, hyprland, etc) have their own mechanisms to provide this feature.
So it would be beneficial if we provide per-compositor support. As discussed in #2531, the best way forward is to develop a plugin interface for the wayland backend. Currently, I have the following structure in mind:
Few points:
lxqtwaylandbackend.cppshould attempt to detect the DE and load the suitable plugin. The DE detection can be based on a user settings orXDG_CURRENT_DESKTOP.lxqtwaylandbackend.cppwill be used).Changes made:
panel/backends/wayland/topanel/backends/wayland/plasmapanel/backends/wayland/wlrootsimplements the wlroots backend.panel/lxqtpanelapplication.cppto use only wlroots backend. (This needs to be fixed)Current state:
Note: For the purpose of our discussion here, by "non-wlroots compositor", what I mean is a compositor that does not implement wlr-foreign-toplevel protocol.
cc: @stefonarch @tsujan