Hi, I'm in the process of upgrading xfce4-panel in Debian and I get some crashes with GTK3 plugins (whisker, pulseaudio and xfpm). Those gtk3 plugins were built against libxfce4panel-2.0.so.4.0.0 4.12 and I've upgraded the running library to libxfce4panel-2.0.so.4.0.0 4.13. The xfce4-panel binary is still a 4.12, I'm not sure if it's relevant or not, when I'll have tested I'll report back. If a plugin built against libxfce4panel-2.0.so.4.0.0 4.12 doesn't work with libxfce4panel-2.0.so.4.0.0 4.13 then the breakage should be explicit, like with a soname bump.
*** Bug 13636 has been marked as a duplicate of this bug. ***
PROVIDER_PROP_TYPE_SET_BACKGROUND_ALPHA was removed. These plugins must be using it. https://git.xfce.org/xfce/xfce4-panel/diff/wrapper/main.c?id=28133ea35fd542beea4e519df6e6534c44739481
(In reply to Peter de Ridder from comment #2) > PROVIDER_PROP_TYPE_SET_BACKGROUND_ALPHA was removed. These plugins must be > using it. > > https://git.xfce.org/xfce/xfce4-panel/diff/wrapper/main. > c?id=28133ea35fd542beea4e519df6e6534c44739481 I quickly checked whiskermenu and it doesn't seem to use it, at least directly.
I got the property set reversed: The panel sends these signals to the plugin-wrapper. They are send by panel-plugin-external towards the wrapper/main. The version of the panel-plugin-external and wrapper/main should match, if it comes to XfcePanelPluginProviderPropType. If the panel-plugin-external sends a property to wrapper/main which is removed in the version of wrapper/main, or if it was added in the version of panel-plugin-external and wrapper/main is still an older version, you'll get the error as reported in Bug 13636. Can you verify the version of the panel you run and the version of the wrapper used? From the trace of Bug 13636, you seem to be running the latest version of the wrapper.
From your initial report, you say you run 4.12. That would mean the versions of the panel and wrapper don't match. The actual problem might be: Why does the panel version 4.12 run the wrapper of 4.13. What are the paths where the binaries are installed? Was one overwritten?
Yes, the running xfce4-panel is 4.12 (along with libxfc4panel libxfce4panel-1.0.so.4). So wrapper-1.0 is 4.12 and wrapper-2.0 is 4.13.
Between 4.12 and 4.13, PROVIDER_PROP_TYPE_SET_BACKGROUND_ALPHA was removed and PROVIDER_PROP_TYPE_SET_OPACITY was added. Also PROVIDER_PROP_TYPE_SET_OPACITY wasn't added to the end. Makes it impossible to use the 4.13 wrapper with 4.12 panel, as well as using 4.12 wrapper with 4.13 panel. If this is something we want to support, we need to fix this. Currently if the wrapper doesn't know about the property is stops, maybe it should ignore it.
In my opinion as a packager, it would be best to avoid incompatibilities between versions. And if these happen (sometimes it's just not possible to avoid them), then something should be done to properly handle that at the library level, like soname bumps. We tried to handle plugins/panels dependencies at the packaging level in Debian, and honestly it's been really hard. We ship libxfce4panel-1.0 in the same binary package as xfce4-panel, but that doesn't prevent incompatibilities with the plugins, so we have some not-so-nice tricks to enforce strict version dependencies against the panel library version the plugin package was built with. And in turn it makes it really hards to upgrade panel and plugins because one needs to rebuild *all the plugins* every time the panel change major version (even if there was no incompatible change) because we couldn't know in advance if there was to be incompatibilities at the next major version. We wanted to avoid this with libxfce4panel-2.0 so it's shipped outside of xfce4-panel binary package (an it prevents having xfce4-panel depends on both gtk2 and gtk3), but that means we need to handle that properly as well. And right now there is no way for a current plugin package, built against libxfce4panel-2.0 4.12, to “know” that it won't work with the 4.13 wrapper. In the end, I have the feeling that since wrapper-2.0 has incompatible changes, it should somehow be shipped as wrapper-2.1 or something, and be co-installable with wrapper2.0. Not sure if that makes sense though.
Created attachment 7183 Moved new property OPACITY to end, make wrapper accept unknown properties It isn't a libxfce4panel ABI incompatibility. It is in the internal communication between the panel wrapper. With this patch panel 4.12 with wrapper-2.0 4.13 will work. But the background alpha won't. panel 4.12 with wrapper-1.0 4.13 won't work. panel 4.13 with wrapper-1.0 4.12 won't work.
Peter de Ridder referenced this bugreport in commit eaca5041ae4a37b772f48b258819ab06bc9da3d3 Don't let the wrapper crash on unknown properties (Bug #13614) https://git.xfce.org/xfce/xfce4-panel/commit?id=eaca5041ae4a37b772f48b258819ab06bc9da3d3
Thanks for the patch Peter, I think that solution makes the most sense and prevents that unnecessary crash.