Repository navigation
[WIP] [X11] Port from libwnck to libxfce4windowing - #1585
Sunderland93 wants to merge 14 commits into
Conversation
This also removes a disconnect call that was placed outside X11 guard and broke builds with X11 support disabled
Window selector backend already only talked to libxfce4windowing and therefore works on X11 as well
workspace-switcher.h was only included inside HAVE_X11 block, leaving workspace_switcherapplet_fill undeclared when building without X11
|
Got this segfault after a few minutes runtime under wayland (current session): |
|
Got this backtrace from the segfault under wayland: |
|
Fixed |
|
This now works fine in both x11 and wayland. Forgot to test previews while in the x11 session however. Note that the handling of very large numbers of open windows is somewhat different that what people may have come to expect on x11 and is the same as on wayland here. It is possible to get a rendering issue where the window list overflows onto other applets in some edge cases like changing window scaling with a crowded window list at certain numbers of open windows, or with certain applications that somehow seem to set a miniumum button width in the window list such as avidemux. This would be guaranteed to generate bug reports on x11 wheras new issues on wayland are more expected. libwnck never, ever does this but in the past few years has had nasty issues in some versions with narrow switcher rectangle rendering. |
Latest commit should address this issue, but I didn't testing it yet |
|
This does prevent the tasklist from overflowing onto other applets when opening avidemux (the worst offender)
but so long as icons are showing in tasklist buttons the buttons do not shrink so the tasklist gets cut off. This
is better than before as the rest of the panel remains usable, but we need to find out what's going on with
icons set by avidemux and similar apps.
If icons are NOT showing due to an already crowded tasklist, all buttons render as they should, avidemux
included.
Mentioning avidemux because panel issues with it in the wayland code and thus the new x11 code as well
are absolutely repeatable and happen every time at least on this end.
|
|
I can't reproduce issue with avidemux (probably I did it wrong), but latest commit should allow tasklist to correctly resize buttons to the width actually allocated |
|
Note that avidemux only ships a 128x128 icon, this is a QT app written possibly without testing the icon in GTK based panels |
|
Turns out there is a much simpler way to do this, using gtk_image_set_pixel_size() to force the icon to render at the intended size. This can be done simply to force GTK_ICON_SIZE_MENU as in the diff below from the last commit, but we then need to detect the panel height and set the icon size both when we load and when we render the icon to the largest standard icon size that will fit in the panel. Any time we are forcing GTK_ICON_SIZE_MENU the tasklist icons will stay at 16x16 no matter how wide the user sets the panel height(on a horizonal panel) Anyway, this diff reverts the last commit and adds just 3 lines of code, only supporting GTK_ICON_SIZE_MENU for now. It does render all icons sharp and all the same size. |
|
From the PREVIOUS commit 7e1015a this diff is much easier to understand: |
|
I just did some comparison testing of my diff applied to the next to last commit to git master. Turns out in master we already have all of the original rendering issues (too large icons when only oversize icons shipped and these icons making the window list overflow onto other applets) with avidemux and its 128x128 icon. I also tested again in x11, behavior same as in wayland and icon size was correct (for GTK_ICON_SIZE MENU anyway) both with 1x and 2x window scaling. Thus this was never worse in wayland than the current git master but of course ported those issues over to the x11 panel. From what we have now with my diff we just need to get the space available in terms of panel height on a horizontal panel/width on a vertical panel, select the icon from the largest folder that fits right, both load and force that size, and this will be ready. The only remaining difference from the x11 panel will be subtle differences in when exactly icons or labels get hidden, and duplicating the exact behavior of libwnck to avoid bug reports over that sort of thing is probably impractical. |
f9a329f scaled the icon to a fixed pixel size itself and handed GtkImage the resulting pixbuf. That bounded the button, but GtkImage reports a pixbuf's own pixel width as its logical width, so at a 2x scale the icon came out twice the size it should have been, and every icon was a little soft from the resample we did rather than the theme's. Pin the size on the GtkImage instead and leave the lookup to GTK. A pixel size is authoritative over the icon size, and having one set also makes the lookup pass GTK_ICON_LOOKUP_FORCE_SIZE, so the theme scales the icon to exactly that size. The widget's size then comes from the pixel size rather than from the surface the theme returned, which is what stops an application that only ships a 128x128 icon dragging the button's minimum width up with it and pushing the tasklist off the panel. Apply the same to the group button and the group context menu, which were still sizing themselves from whatever the icon theme handed back. The two image constructors passed the pixel constant icon_size (16) as a GtkIconSize, whose range is 0 to 6, so the value was out of range. Ask for GTK_ICON_SIZE_MENU instead.
|
We also have several issues with window grouping that this will presumably bring to the x11 session given identical x11 and wayland behavior: 1: If window grouping is turned on on an uncrowded panel and the panel becomes crowded, sometimes part of the last button gets cut off 2: Not all buttons that should be in a group(being from the same app) get included in that group, some remain separate 3: If window grouping is turned on while the panel is crowded, the icon is only shown in the buttons for grouped windows and not for solo windows of other apps |
|
In tasklist-core.c in I added Catching this zero case with at the top of the file and using it with the code below in solved the problem, a theme that sets a padding of 1px or more overrides it if the padding value is readable. A minimum padding value of 1px leads to oversize icons again at some panel sizes, while a 2px minimum seems to give behavior very similar to master in x11 so far as icon size is concerned. |





We already use
libxfce4windowingfor Wayland backend, but this library also supports X11, as it useslibwnckunder the hood. So, instead of maintaining two codebases for two backends, we can maintain a single, unified one. This way, both backends will work identically, have a common structure, and a single source of bugs. All backend-agnostic code is moved into separate structures, making the codebase overall cleaner and easier to maintain, and significantly simplifying the addition of features like this #1535Needs a lot of testing, so WIP for now