Re: WM_CLASS/StartupWMClass, desktop files & mozilla ports (was: Re: help creating new port: x11/xfce4/xfce4-docklike)
Le Wed, Apr 19, 2023 at 11:16:32PM +0200, Joel Carnat a écrit : > Le 19/04/2023 à 09:47, Joel Carnat a écrit : > > > > > > More testing needed, but feedback on the rationale more than welcome ! > > > > > > > > > > Landry > > > > > > > > > > > > > I have tested various combination and long-story-short, nothing worked > > > > except the dirty modification of Exec. StartupWMClass doesn't seem to be > > > > taken in account, or at least WM_CLASS isn't changed (tested with > > > > xprop). > > > > > > > > Using `firefox --class firefox` from xterm does show the proper icon. > > > > You > > > > can then pin it on docklike. But it is pinned without the flags. You > > > > have to > > > > edit the launcher to add "--class firefox". Then, clicking docklike icon > > > > will start Firefox with the overwritten class and show the icon. > > > > > > > > I have noticed that when you modify the launcher from docklike, it > > > > automatically modifies ~/.local/share/applications/firefox.desktop with > > > > "Exec=firefox --class firefox %u". > > > > > > Was all this testing with standard packages, or my wip packages setting > > > MOZ_APP_REMOTINGNAME ? > > > > It was the standard packages. > > I forgot to test with your packages. > > > > I’ll have a look this evening and let you know. > > > > So I tested your firefox-esr package. > Long-story-short, it works as expected. > > - starting firefox-esr from xterm sets a FF icon in docklike. > checking wmclass shows WM_CLASS(STRING) = "Navigator", "firefox-esr" > - same thing happens when I remove any *firefox*desktop from my > ~/.local/share/applications directory. > - starting firefox-esx and pinning it to docklike keeps the FF icon. > clicking on the icon start Firefox ESR as expected and swallow the > instance using the icon. Thanks for the testing, i've commited MOZ_APP_REMOTINGNAME and fixed icons while here, all should be fine now. Landry
Re: WM_CLASS/StartupWMClass, desktop files & mozilla ports (was: Re: help creating new port: x11/xfce4/xfce4-docklike)
Le 19/04/2023 à 09:47, Joel Carnat a écrit : More testing needed, but feedback on the rationale more than welcome ! Landry I have tested various combination and long-story-short, nothing worked except the dirty modification of Exec. StartupWMClass doesn't seem to be taken in account, or at least WM_CLASS isn't changed (tested with xprop). Using `firefox --class firefox` from xterm does show the proper icon. You can then pin it on docklike. But it is pinned without the flags. You have to edit the launcher to add "--class firefox". Then, clicking docklike icon will start Firefox with the overwritten class and show the icon. I have noticed that when you modify the launcher from docklike, it automatically modifies ~/.local/share/applications/firefox.desktop with "Exec=firefox --class firefox %u". Was all this testing with standard packages, or my wip packages setting MOZ_APP_REMOTINGNAME ? It was the standard packages. I forgot to test with your packages. I’ll have a look this evening and let you know. So I tested your firefox-esr package. Long-story-short, it works as expected. - starting firefox-esr from xterm sets a FF icon in docklike. checking wmclass shows WM_CLASS(STRING) = "Navigator", "firefox-esr" - same thing happens when I remove any *firefox*desktop from my ~/.local/share/applications directory. - starting firefox-esx and pinning it to docklike keeps the FF icon. clicking on the icon start Firefox ESR as expected and swallow the instance using the icon. Regards, Joel C.
Re: WM_CLASS/StartupWMClass, desktop files & mozilla ports (was: Re: help creating new port: x11/xfce4/xfce4-docklike)
> Le 19 avr. 2023 à 07:48, Landry Breuil a écrit : > > Le Tue, Apr 18, 2023 at 10:20:54PM +0200, Joel Carnat a écrit : >>> Le 18/04/2023 à 16:08, Landry Breuil a écrit : > > Can you try removing the '-default' suffixing horror, and just add > StartupWMClass=firefox (or thunderbird, or firefox-esr..) to your custom > desktop file and check this also fixes the problem ? > > The firefox-flatpak desktop file has a bit more actions, more > translations, and seems better maintained upstream, so instead of > setting MOZ_APP_REMOTINGNAME in the build i'd rather switch to this > desktop file as a source for the one we install in the package. > > My understanding of the root issue is that docklike relies on the > WM_CLASS value to match running processes, which doesnt work for mozilla > windows because of the -default suffix. You can see for yourself what > is the WM_CLASS for all existing windows using 'xlsclients', that might > also show other applications behaving weird. >>> >>> Thinking more about it, i'm not sure fixing the desktop file is enough, >>> since that only might account for the browsers launched from clicking on >>> a proper launcher, and might not have the same behaviour with starting >>> "firefox" in a terminal. >>> >>> More testing needed, but feedback on the rationale more than welcome ! >>> >>> Landry >>> >> >> I have tested various combination and long-story-short, nothing worked >> except the dirty modification of Exec. StartupWMClass doesn't seem to be >> taken in account, or at least WM_CLASS isn't changed (tested with xprop). >> >> Using `firefox --class firefox` from xterm does show the proper icon. You >> can then pin it on docklike. But it is pinned without the flags. You have to >> edit the launcher to add "--class firefox". Then, clicking docklike icon >> will start Firefox with the overwritten class and show the icon. >> >> I have noticed that when you modify the launcher from docklike, it >> automatically modifies ~/.local/share/applications/firefox.desktop with >> "Exec=firefox --class firefox %u". > > Was all this testing with standard packages, or my wip packages setting > MOZ_APP_REMOTINGNAME ? It was the standard packages. I forgot to test with your packages. I’ll have a look this evening and let you know. > >> Note that Thunderbird also has the StartupWMClass in the default desktop >> file ; and the icon is ignored. I have also seen >> /usr/local/share/applications/writer.desktop having "Exec=libreoffice7.5 >> --writer %U" in the stock file. > > And.. what is the behaviour for writer ? works ? wrong icon ? wrong > class ? With Libreoffice, everything worked out of the box. I never thought about checking its desktop files before yesterday. > For thunderbird the issue is the same as firefox, it has > 'thunderbird-default' as > WM_CLASS: > WM_CLASS(STRING) = "Mail", "thunderbird-default" > and the desktop file is wrong too, since it has > 'StartupWMClass=Thunderbird-bin' > which doesnt match the binary name nor the WM_CLASS. > > To my understanding, for the icon to work (in all situations, eg > launched from a terminal or from a command in a shell), the value in > xlsclients (set via --class arg on the commandline or gdk_set_wm_class() > in the code) has to match the binary name. > > Landry
Re: WM_CLASS/StartupWMClass, desktop files & mozilla ports (was: Re: help creating new port: x11/xfce4/xfce4-docklike)
Le Tue, Apr 18, 2023 at 10:20:54PM +0200, Joel Carnat a écrit : > Le 18/04/2023 à 16:08, Landry Breuil a écrit : > > > > > > Can you try removing the '-default' suffixing horror, and just add > > > StartupWMClass=firefox (or thunderbird, or firefox-esr..) to your custom > > > desktop file and check this also fixes the problem ? > > > > > > The firefox-flatpak desktop file has a bit more actions, more > > > translations, and seems better maintained upstream, so instead of > > > setting MOZ_APP_REMOTINGNAME in the build i'd rather switch to this > > > desktop file as a source for the one we install in the package. > > > > > > My understanding of the root issue is that docklike relies on the > > > WM_CLASS value to match running processes, which doesnt work for mozilla > > > windows because of the -default suffix. You can see for yourself what > > > is the WM_CLASS for all existing windows using 'xlsclients', that might > > > also show other applications behaving weird. > > > > Thinking more about it, i'm not sure fixing the desktop file is enough, > > since that only might account for the browsers launched from clicking on > > a proper launcher, and might not have the same behaviour with starting > > "firefox" in a terminal. > > > > More testing needed, but feedback on the rationale more than welcome ! > > > > Landry > > > > I have tested various combination and long-story-short, nothing worked > except the dirty modification of Exec. StartupWMClass doesn't seem to be > taken in account, or at least WM_CLASS isn't changed (tested with xprop). > > Using `firefox --class firefox` from xterm does show the proper icon. You > can then pin it on docklike. But it is pinned without the flags. You have to > edit the launcher to add "--class firefox". Then, clicking docklike icon > will start Firefox with the overwritten class and show the icon. > > I have noticed that when you modify the launcher from docklike, it > automatically modifies ~/.local/share/applications/firefox.desktop with > "Exec=firefox --class firefox %u". Was all this testing with standard packages, or my wip packages setting MOZ_APP_REMOTINGNAME ? > Note that Thunderbird also has the StartupWMClass in the default desktop > file ; and the icon is ignored. I have also seen > /usr/local/share/applications/writer.desktop having "Exec=libreoffice7.5 > --writer %U" in the stock file. And.. what is the behaviour for writer ? works ? wrong icon ? wrong class ? For thunderbird the issue is the same as firefox, it has 'thunderbird-default' as WM_CLASS: WM_CLASS(STRING) = "Mail", "thunderbird-default" and the desktop file is wrong too, since it has 'StartupWMClass=Thunderbird-bin' which doesnt match the binary name nor the WM_CLASS. To my understanding, for the icon to work (in all situations, eg launched from a terminal or from a command in a shell), the value in xlsclients (set via --class arg on the commandline or gdk_set_wm_class() in the code) has to match the binary name. Landry
Re: WM_CLASS/StartupWMClass, desktop files & mozilla ports (was: Re: help creating new port: x11/xfce4/xfce4-docklike)
Le 18/04/2023 à 16:08, Landry Breuil a écrit :
Le Tue, Apr 18, 2023 at 08:25:54AM +0200, Landry Breuil a écrit :
Le Sun, Apr 16, 2023 at 06:53:35PM +0200, Joel Carnat a écrit :
Le 16/04/2023 à 18:21, Landry Breuil a écrit :
Le Fri, Apr 14, 2023 at 09:49:38AM +0200, Joel Carnat a écrit :
Only the Exec part:
# diff /usr/local/share/applications/firefox.desktop
~/.local/share/applications/firefox.desktop
153c153
< Exec=firefox %u
---
Exec=firefox-default %u
200c200
< Exec=firefox -new-window
---
Exec=firefox-default -new-window
219c219
< Exec=firefox -private-window
---
Exec=firefox-default -private-window
Sorry, but i dont think that makes sense. Unless there's a
'firefox-default' script/wrapper in your $PATH, i doubt that can work.
or the /usr/local/share/applications/firefox.desktop file takes
precedence because ~/.local/share/applications/firefox.desktop has an
invalid entry for Exec
Well, I have no clue why it works. It just does (here) :D
I can even open ~/.local/share/applications/firefox.desktop, replace
"Exec=firefox-default %u" with "Exec=firefox %u", save the file, and the
icon changes on docklike. Reversing the change makes the icon appear on
docklike.
So i've had a proper look, and it is all caused by WM_CLASS being
firefox{,-esr}-default instead of just the program name.
I've build 113.0b4 & esr 102.10.0 with
MOZ_APP_REMOTINGNAME=${MOZILLA_PROJECT} in MAKE_ENV (directly in
mozilla.port.mk) and those binaries have their proper icon in
xfce4-docklike. You can try by installing them from
https://packages.rhaalovely.net/snapshots/amd64/
but there might be a 'better' fix. I see that for all mozilla ports
we're using
https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-snap/firefox.desktop
as a source for our desktop file, but there's also
https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/org.mozilla.firefox.desktop
and this one has StartupWMClass=firefox since
https://hg.mozilla.org/mozilla-central/rev/8bc2a43e9ac0f8521348db40df7b0f441c6392a2.
Can you try removing the '-default' suffixing horror, and just add
StartupWMClass=firefox (or thunderbird, or firefox-esr..) to your custom
desktop file and check this also fixes the problem ?
The firefox-flatpak desktop file has a bit more actions, more
translations, and seems better maintained upstream, so instead of
setting MOZ_APP_REMOTINGNAME in the build i'd rather switch to this
desktop file as a source for the one we install in the package.
My understanding of the root issue is that docklike relies on the
WM_CLASS value to match running processes, which doesnt work for mozilla
windows because of the -default suffix. You can see for yourself what
is the WM_CLASS for all existing windows using 'xlsclients', that might
also show other applications behaving weird.
Thinking more about it, i'm not sure fixing the desktop file is enough,
since that only might account for the browsers launched from clicking on
a proper launcher, and might not have the same behaviour with starting
"firefox" in a terminal.
More testing needed, but feedback on the rationale more than welcome !
Landry
I have tested various combination and long-story-short, nothing worked
except the dirty modification of Exec. StartupWMClass doesn't seem to be
taken in account, or at least WM_CLASS isn't changed (tested with xprop).
Using `firefox --class firefox` from xterm does show the proper icon.
You can then pin it on docklike. But it is pinned without the flags. You
have to edit the launcher to add "--class firefox". Then, clicking
docklike icon will start Firefox with the overwritten class and show the
icon.
I have noticed that when you modify the launcher from docklike, it
automatically modifies ~/.local/share/applications/firefox.desktop with
"Exec=firefox --class firefox %u".
Note that Thunderbird also has the StartupWMClass in the default desktop
file ; and the icon is ignored. I have also seen
/usr/local/share/applications/writer.desktop having "Exec=libreoffice7.5
--writer %U" in the stock file.
Joel C.
Re: WM_CLASS/StartupWMClass, desktop files & mozilla ports (was: Re: help creating new port: x11/xfce4/xfce4-docklike)
Le Tue, Apr 18, 2023 at 08:25:54AM +0200, Landry Breuil a écrit :
> Le Sun, Apr 16, 2023 at 06:53:35PM +0200, Joel Carnat a écrit :
> > Le 16/04/2023 à 18:21, Landry Breuil a écrit :
> > > Le Fri, Apr 14, 2023 at 09:49:38AM +0200, Joel Carnat a écrit :
> > > >
> > > > Only the Exec part:
> > > > # diff /usr/local/share/applications/firefox.desktop
> > > > ~/.local/share/applications/firefox.desktop
> > > > 153c153
> > > > < Exec=firefox %u
> > > > ---
> > > > > Exec=firefox-default %u
> > > > 200c200
> > > > < Exec=firefox -new-window
> > > > ---
> > > > > Exec=firefox-default -new-window
> > > > 219c219
> > > > < Exec=firefox -private-window
> > > > ---
> > > > > Exec=firefox-default -private-window
> > >
> > > Sorry, but i dont think that makes sense. Unless there's a
> > > 'firefox-default' script/wrapper in your $PATH, i doubt that can work.
> > > or the /usr/local/share/applications/firefox.desktop file takes
> > > precedence because ~/.local/share/applications/firefox.desktop has an
> > > invalid entry for Exec
> > >
> >
> > Well, I have no clue why it works. It just does (here) :D
> > I can even open ~/.local/share/applications/firefox.desktop, replace
> > "Exec=firefox-default %u" with "Exec=firefox %u", save the file, and the
> > icon changes on docklike. Reversing the change makes the icon appear on
> > docklike.
>
> So i've had a proper look, and it is all caused by WM_CLASS being
> firefox{,-esr}-default instead of just the program name.
>
> I've build 113.0b4 & esr 102.10.0 with
> MOZ_APP_REMOTINGNAME=${MOZILLA_PROJECT} in MAKE_ENV (directly in
> mozilla.port.mk) and those binaries have their proper icon in
> xfce4-docklike. You can try by installing them from
> https://packages.rhaalovely.net/snapshots/amd64/
>
> but there might be a 'better' fix. I see that for all mozilla ports
> we're using
> https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-snap/firefox.desktop
> as a source for our desktop file, but there's also
> https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/org.mozilla.firefox.desktop
> and this one has StartupWMClass=firefox since
> https://hg.mozilla.org/mozilla-central/rev/8bc2a43e9ac0f8521348db40df7b0f441c6392a2.
>
> Can you try removing the '-default' suffixing horror, and just add
> StartupWMClass=firefox (or thunderbird, or firefox-esr..) to your custom
> desktop file and check this also fixes the problem ?
>
> The firefox-flatpak desktop file has a bit more actions, more
> translations, and seems better maintained upstream, so instead of
> setting MOZ_APP_REMOTINGNAME in the build i'd rather switch to this
> desktop file as a source for the one we install in the package.
>
> My understanding of the root issue is that docklike relies on the
> WM_CLASS value to match running processes, which doesnt work for mozilla
> windows because of the -default suffix. You can see for yourself what
> is the WM_CLASS for all existing windows using 'xlsclients', that might
> also show other applications behaving weird.
Thinking more about it, i'm not sure fixing the desktop file is enough,
since that only might account for the browsers launched from clicking on
a proper launcher, and might not have the same behaviour with starting
"firefox" in a terminal.
More testing needed, but feedback on the rationale more than welcome !
Landry
WM_CLASS/StartupWMClass, desktop files & mozilla ports (was: Re: help creating new port: x11/xfce4/xfce4-docklike)
Le Sun, Apr 16, 2023 at 06:53:35PM +0200, Joel Carnat a écrit :
> Le 16/04/2023 à 18:21, Landry Breuil a écrit :
> > Le Fri, Apr 14, 2023 at 09:49:38AM +0200, Joel Carnat a écrit :
> > >
> > > Only the Exec part:
> > > # diff /usr/local/share/applications/firefox.desktop
> > > ~/.local/share/applications/firefox.desktop
> > > 153c153
> > > < Exec=firefox %u
> > > ---
> > > > Exec=firefox-default %u
> > > 200c200
> > > < Exec=firefox -new-window
> > > ---
> > > > Exec=firefox-default -new-window
> > > 219c219
> > > < Exec=firefox -private-window
> > > ---
> > > > Exec=firefox-default -private-window
> >
> > Sorry, but i dont think that makes sense. Unless there's a
> > 'firefox-default' script/wrapper in your $PATH, i doubt that can work.
> > or the /usr/local/share/applications/firefox.desktop file takes
> > precedence because ~/.local/share/applications/firefox.desktop has an
> > invalid entry for Exec
> >
>
> Well, I have no clue why it works. It just does (here) :D
> I can even open ~/.local/share/applications/firefox.desktop, replace
> "Exec=firefox-default %u" with "Exec=firefox %u", save the file, and the
> icon changes on docklike. Reversing the change makes the icon appear on
> docklike.
So i've had a proper look, and it is all caused by WM_CLASS being
firefox{,-esr}-default instead of just the program name.
I've build 113.0b4 & esr 102.10.0 with
MOZ_APP_REMOTINGNAME=${MOZILLA_PROJECT} in MAKE_ENV (directly in
mozilla.port.mk) and those binaries have their proper icon in
xfce4-docklike. You can try by installing them from
https://packages.rhaalovely.net/snapshots/amd64/
but there might be a 'better' fix. I see that for all mozilla ports
we're using
https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-snap/firefox.desktop
as a source for our desktop file, but there's also
https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/org.mozilla.firefox.desktop
and this one has StartupWMClass=firefox since
https://hg.mozilla.org/mozilla-central/rev/8bc2a43e9ac0f8521348db40df7b0f441c6392a2.
Can you try removing the '-default' suffixing horror, and just add
StartupWMClass=firefox (or thunderbird, or firefox-esr..) to your custom
desktop file and check this also fixes the problem ?
The firefox-flatpak desktop file has a bit more actions, more
translations, and seems better maintained upstream, so instead of
setting MOZ_APP_REMOTINGNAME in the build i'd rather switch to this
desktop file as a source for the one we install in the package.
My understanding of the root issue is that docklike relies on the
WM_CLASS value to match running processes, which doesnt work for mozilla
windows because of the -default suffix. You can see for yourself what
is the WM_CLASS for all existing windows using 'xlsclients', that might
also show other applications behaving weird.
Landry
Re: help creating new port: x11/xfce4/xfce4-docklike
Le 16/04/2023 à 18:21, Landry Breuil a écrit : Le Fri, Apr 14, 2023 at 09:49:38AM +0200, Joel Carnat a écrit : Only the Exec part: # diff /usr/local/share/applications/firefox.desktop ~/.local/share/applications/firefox.desktop 153c153 < Exec=firefox %u --- Exec=firefox-default %u 200c200 < Exec=firefox -new-window --- Exec=firefox-default -new-window 219c219 < Exec=firefox -private-window --- Exec=firefox-default -private-window Sorry, but i dont think that makes sense. Unless there's a 'firefox-default' script/wrapper in your $PATH, i doubt that can work. or the /usr/local/share/applications/firefox.desktop file takes precedence because ~/.local/share/applications/firefox.desktop has an invalid entry for Exec Well, I have no clue why it works. It just does (here) :D I can even open ~/.local/share/applications/firefox.desktop, replace "Exec=firefox-default %u" with "Exec=firefox %u", save the file, and the icon changes on docklike. Reversing the change makes the icon appear on docklike. (oh, and diff -u is always more readable ;) sorry for that. you'd have told me firefox --class=firefox to override the default 'wm class' set to 'firefox-default', i'd have understood.. Anyway, for firefox, to my understanding this comes from https://bugzilla.mozilla.org/show_bug.cgi?id=1530052. To be investigated. I copied /usr/local/share/applications/xfce4-terminal.desktop into ~/.local/share/applications/xterm.desktop, remove a bunch of translations I don't use and modify the Exec part: # cat ~/.local/share/applications/xterm.desktop ok but that's a different issue, there's no 'default' desktop file for xterm. not xfce4-docklike problems :) Yes, you're right. I was surprised because xfce/tasklist did apply an icon to xterm even without a desktop file. But I found tasklist would use the info from the XTerm*iconHint xresource, whereas docklike didn't. That's why I thought it was docklike's fault.
Re: help creating new port: x11/xfce4/xfce4-docklike
Le 16/04/2023 à 18:16, Landry Breuil a écrit : Le Fri, Apr 14, 2023 at 10:01:43AM +0200, Joel Carnat a écrit : Le 14/04/2023 à 09:06, Landry Breuil a écrit : Le Thu, Apr 13, 2023 at 06:30:15PM +0200, Joel Carnat a écrit : Le 20/02/2023 à 10:19, Joel Carnat a écrit : Hi, nice, two comments: - no need for CONFIGURE_STYLE, its set by x11/xfce4/Makefile.inc I added it to solve an issue where "make build" would not work without it: ===> Building for xfce4-docklike-0.4.1 gmake: Makefile: No such file or directory gmake: *** No rule to make target 'Makefile'. Stop. *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2960 '/usr/ports/pobj/xfce4-docklike-0.4.1/.build_done': @cd /usr/ports/pobj/xfce...) *** Error 2 in /usr/ports/mystuff/x11/xfce4/xfce4-docklike (/usr/ports/infrastructure/mk/bsd.port.mk:2600 'build': @lock=xfce4-docklike-0.4) I saw that x11/xfce4/xfce4-whiskermenu had it set (to some other parameter) and other ports used "gnu" as an value. So I tried and it compiled this way. But maybe it's not the right way to solve this particular issue. I think your issue (and the fact that distinfo didnt have the xfce4/ prefix for the distfile path) stems from your creation of a port in mystuff/x11/xfce4 without having copied x11/xfce4/Makefile.inc to mystuff/x11/xfce4 - thus CONFIGURE_STYLE & DIST_SUBDIR werent set by the missing Makefile.inc Yes, this has solved the error. Thanks. Here's the updated tarball in case you want it. Joel C. xfce4-docklike.tar.gz Description: application/gzip
Re: help creating new port: x11/xfce4/xfce4-docklike
Le Fri, Apr 14, 2023 at 09:49:38AM +0200, Joel Carnat a écrit : > > Only the Exec part: > # diff /usr/local/share/applications/firefox.desktop > ~/.local/share/applications/firefox.desktop > 153c153 > < Exec=firefox %u > --- > > Exec=firefox-default %u > 200c200 > < Exec=firefox -new-window > --- > > Exec=firefox-default -new-window > 219c219 > < Exec=firefox -private-window > --- > > Exec=firefox-default -private-window Sorry, but i dont think that makes sense. Unless there's a 'firefox-default' script/wrapper in your $PATH, i doubt that can work. or the /usr/local/share/applications/firefox.desktop file takes precedence because ~/.local/share/applications/firefox.desktop has an invalid entry for Exec (oh, and diff -u is always more readable ;) you'd have told me firefox --class=firefox to override the default 'wm class' set to 'firefox-default', i'd have understood.. Anyway, for firefox, to my understanding this comes from https://bugzilla.mozilla.org/show_bug.cgi?id=1530052. To be investigated. > I copied /usr/local/share/applications/xfce4-terminal.desktop into > ~/.local/share/applications/xterm.desktop, remove a bunch of translations I > don't use and modify the Exec part: > # cat ~/.local/share/applications/xterm.desktop ok but that's a different issue, there's no 'default' desktop file for xterm. not xfce4-docklike problems :)
Re: help creating new port: x11/xfce4/xfce4-docklike
Le Fri, Apr 14, 2023 at 10:01:43AM +0200, Joel Carnat a écrit : > Le 14/04/2023 à 09:06, Landry Breuil a écrit : > > Le Thu, Apr 13, 2023 at 06:30:15PM +0200, Joel Carnat a écrit : > > > Le 20/02/2023 à 10:19, Joel Carnat a écrit : > > > > Hi, > > > > > > nice, two comments: > > - no need for CONFIGURE_STYLE, its set by x11/xfce4/Makefile.inc > > I added it to solve an issue where "make build" would not work without it: > ===> Building for xfce4-docklike-0.4.1 > gmake: Makefile: No such file or directory > gmake: *** No rule to make target 'Makefile'. Stop. > *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2960 > '/usr/ports/pobj/xfce4-docklike-0.4.1/.build_done': @cd > /usr/ports/pobj/xfce...) > *** Error 2 in /usr/ports/mystuff/x11/xfce4/xfce4-docklike > (/usr/ports/infrastructure/mk/bsd.port.mk:2600 'build': > @lock=xfce4-docklike-0.4) > > I saw that x11/xfce4/xfce4-whiskermenu had it set (to some other parameter) > and other ports used "gnu" as an value. So I tried and it compiled this way. > > But maybe it's not the right way to solve this particular issue. I think your issue (and the fact that distinfo didnt have the xfce4/ prefix for the distfile path) stems from your creation of a port in mystuff/x11/xfce4 without having copied x11/xfce4/Makefile.inc to mystuff/x11/xfce4 - thus CONFIGURE_STYLE & DIST_SUBDIR werent set by the missing Makefile.inc Landry
Re: help creating new port: x11/xfce4/xfce4-docklike
On 2023/04/14 09:06:26 +0200, Landry Breuil wrote:
> nice, two comments:
> - no need for CONFIGURE_STYLE, its set by x11/xfce4/Makefile.inc
> - please dont start COMMENT by an article, the previous one was fine imo
> ('modern & minimalist taskbar for Xfce') - no need for the final dot
> either
>
> other than that the port looks okay to me, i'll need another okay to
> import it.
I'm testing it, works mostly fine for me and the port looks good.
I've replaced the bottom panel with the dock :)
ok op@ to import with the two points above fixed.
I had to re-run `make makesum' because the distfile now it's under
xfce4/
> > I have also solved the "icons" issue I had with Firefox and Thunderbird.
> > Basically, it is because the binaries are known as firefox-default and
> > thunderbird-default in OpenBSD - I noticed this while running Windowmaker
> > and docking those apps. I had to write my own
> > ~/.local/share/applications/{firefox,thunderbird}.desktop files. And it also
> > works to apply an icon to xterm(1). Do you think this package should come
> > with a note about desktop files in MESSAGE or I should rather add those
> > desktop files in the port?
>
> I wont accept such desktop files in the docklike port, feels like a
> kludge to workaround something broken somewhere else. What's the
> difference between your desktop file and the original one ? There are no
> 'default' suffixes in the thunderbird/firefox binaries.. that has to be
> some weird ICCCM property, because xprop on a firefox window indeed
> gives WM_CLASS(STRING) = "Navigator", "firefox-default"
> but i dunno where that comes from. Will have to dig.
> How about xterm ?
net/lagrange is another application that can't be docked and doesn't
show the icon; no idea why (but xprop on it returns only a few atoms.)
apostrophe, xournalpp (gtk) and yacreader (qt) are handled fine.
Re: help creating new port: x11/xfce4/xfce4-docklike
Le 14/04/2023 à 09:06, Landry Breuil a écrit :
Le Thu, Apr 13, 2023 at 06:30:15PM +0200, Joel Carnat a écrit :
Le 20/02/2023 à 10:19, Joel Carnat a écrit :
Hi,
I’ve spend part of the weekend trying to solve the Firefox / Thunderbird issue.
In details, those applications can’t be docked and don’t get their icon
displayed. Long story short: I couldn’t solve it.
I tried docklike on a couple of Linux distro and could reproduce the bug. Only
MX Linux doesn’t get the bug. But when getting its source and compile on
OpenBSD, the bug is still there.
I’ll continue digging and let you know if I can find a solution.
Regards,
Joel C.
Le 18 févr. 2023 à 15:02, Landry Breuil a écrit :
Le Sat, Feb 18, 2023 at 01:44:20PM +, Klemens Nanni a écrit :
2/18/23 13:16, Landry Breuil пишет:
i havent tested it yet, but here's a port of the latest git commit, with
a simplified Makefile.
Do you intend to upstream the local patches? I was surprised to see
them given your use of XFCE4_COMMIT.
i think joel wanted to upstream them :)
COMMENT must not start with articles or end in a full stop, I think.
Right
Should this be hooked up to one of the xfce meta packages?
Maybe, if it works and is useful..
Hi,
xfce4-docklike has been updated upstream and we don't need any patches any
more. Attached is the updated port. I've been using it on OpenBSD 7.3 amd64
for a couple of days now without issue.
nice, two comments:
- no need for CONFIGURE_STYLE, its set by x11/xfce4/Makefile.inc
I added it to solve an issue where "make build" would not work without it:
===> Building for xfce4-docklike-0.4.1
gmake: Makefile: No such file or directory
gmake: *** No rule to make target 'Makefile'. Stop.
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2960
'/usr/ports/pobj/xfce4-docklike-0.4.1/.build_done': @cd
/usr/ports/pobj/xfce...)
*** Error 2 in /usr/ports/mystuff/x11/xfce4/xfce4-docklike
(/usr/ports/infrastructure/mk/bsd.port.mk:2600 'build':
@lock=xfce4-docklike-0.4)
I saw that x11/xfce4/xfce4-whiskermenu had it set (to some other
parameter) and other ports used "gnu" as an value. So I tried and it
compiled this way.
But maybe it's not the right way to solve this particular issue.
- please dont start COMMENT by an article, the previous one was fine imo
('modern & minimalist taskbar for Xfce') - no need for the final dot
either
ok, corrected.
Re: help creating new port: x11/xfce4/xfce4-docklike
Le 14/04/2023 à 09:12, Landry Breuil a écrit :
Le Fri, Apr 14, 2023 at 09:06:26AM +0200, Landry Breuil a écrit :
Le Thu, Apr 13, 2023 at 06:30:15PM +0200, Joel Carnat a écrit :
I have also solved the "icons" issue I had with Firefox and Thunderbird.
Basically, it is because the binaries are known as firefox-default and
thunderbird-default in OpenBSD - I noticed this while running Windowmaker
and docking those apps. I had to write my own
~/.local/share/applications/{firefox,thunderbird}.desktop files. And it also
works to apply an icon to xterm(1). Do you think this package should come
with a note about desktop files in MESSAGE or I should rather add those
desktop files in the port?
I wont accept such desktop files in the docklike port, feels like a
kludge to workaround something broken somewhere else. What's the
difference between your desktop file and the original one ? There are no
'default' suffixes in the thunderbird/firefox binaries.. that has to be
some weird ICCCM property, because xprop on a firefox window indeed
gives WM_CLASS(STRING) = "Navigator", "firefox-default"
but i dunno where that comes from. Will have to dig.
ah, seems gdk_set_program_class() in
https://searchfox.org/mozilla-central/source/widget/gtk/nsAppShell.cpp#328
is the one setting that weird name. strange. the -default suffix seems
to come from the update channel set in
https://searchfox.org/mozilla-central/source/toolkit/moz.configure#2780
- for some reason unknown to me we're not on 'release' but 'default',
probably because we dont get binary updates from mozilla.
so, what have you set in the desktop file to 'fix' that ?
Only the Exec part:
# diff /usr/local/share/applications/firefox.desktop
~/.local/share/applications/firefox.desktop
153c153
< Exec=firefox %u
---
> Exec=firefox-default %u
200c200
< Exec=firefox -new-window
---
> Exec=firefox-default -new-window
219c219
< Exec=firefox -private-window
---
> Exec=firefox-default -private-window
How about xterm ?
what needs to be done for xterm ?
I copied /usr/local/share/applications/xfce4-terminal.desktop into
~/.local/share/applications/xterm.desktop, remove a bunch of
translations I don't use and modify the Exec part:
# cat ~/.local/share/applications/xterm.desktop
[Desktop Entry]
Version=1.0
Name=Xterm
Name[fr]=Xterm
GenericName=Terminal emulator for X
GenericName[fr]=Émulateur de terminal X
Comment=Use the command line
Comment[fr]=Utiliser la ligne de commande
Exec=/usr/X11R6/bin/xterm
Icon=funterm
Terminal=false
Type=Application
Categories=Utility;
StartupNotify=true
Re: help creating new port: x11/xfce4/xfce4-docklike
Le Fri, Apr 14, 2023 at 09:06:26AM +0200, Landry Breuil a écrit :
> Le Thu, Apr 13, 2023 at 06:30:15PM +0200, Joel Carnat a écrit :
>
> > I have also solved the "icons" issue I had with Firefox and Thunderbird.
> > Basically, it is because the binaries are known as firefox-default and
> > thunderbird-default in OpenBSD - I noticed this while running Windowmaker
> > and docking those apps. I had to write my own
> > ~/.local/share/applications/{firefox,thunderbird}.desktop files. And it also
> > works to apply an icon to xterm(1). Do you think this package should come
> > with a note about desktop files in MESSAGE or I should rather add those
> > desktop files in the port?
>
> I wont accept such desktop files in the docklike port, feels like a
> kludge to workaround something broken somewhere else. What's the
> difference between your desktop file and the original one ? There are no
> 'default' suffixes in the thunderbird/firefox binaries.. that has to be
> some weird ICCCM property, because xprop on a firefox window indeed
> gives WM_CLASS(STRING) = "Navigator", "firefox-default"
> but i dunno where that comes from. Will have to dig.
ah, seems gdk_set_program_class() in
https://searchfox.org/mozilla-central/source/widget/gtk/nsAppShell.cpp#328
is the one setting that weird name. strange. the -default suffix seems
to come from the update channel set in
https://searchfox.org/mozilla-central/source/toolkit/moz.configure#2780
- for some reason unknown to me we're not on 'release' but 'default',
probably because we dont get binary updates from mozilla.
so, what have you set in the desktop file to 'fix' that ?
> How about xterm ?
what needs to be done for xterm ?
Re: help creating new port: x11/xfce4/xfce4-docklike
Le Thu, Apr 13, 2023 at 06:30:15PM +0200, Joel Carnat a écrit :
> Le 20/02/2023 à 10:19, Joel Carnat a écrit :
> > Hi,
> >
> > I’ve spend part of the weekend trying to solve the Firefox / Thunderbird
> > issue. In details, those applications can’t be docked and don’t get their
> > icon displayed. Long story short: I couldn’t solve it.
> >
> > I tried docklike on a couple of Linux distro and could reproduce the bug.
> > Only MX Linux doesn’t get the bug. But when getting its source and compile
> > on OpenBSD, the bug is still there.
> >
> > I’ll continue digging and let you know if I can find a solution.
> >
> > Regards,
> > Joel C.
> >
> > > Le 18 févr. 2023 à 15:02, Landry Breuil a écrit :
> > >
> > > Le Sat, Feb 18, 2023 at 01:44:20PM +, Klemens Nanni a écrit :
> > > > 2/18/23 13:16, Landry Breuil пишет:
> > > > > i havent tested it yet, but here's a port of the latest git commit,
> > > > > with
> > > > > a simplified Makefile.
> > > >
> > > > Do you intend to upstream the local patches? I was surprised to see
> > > > them given your use of XFCE4_COMMIT.
> > >
> > > i think joel wanted to upstream them :)
> > >
> > > > COMMENT must not start with articles or end in a full stop, I think.
> > >
> > > Right
> > >
> > > > Should this be hooked up to one of the xfce meta packages?
> > >
> > > Maybe, if it works and is useful..
> > >
> >
>
> Hi,
>
> xfce4-docklike has been updated upstream and we don't need any patches any
> more. Attached is the updated port. I've been using it on OpenBSD 7.3 amd64
> for a couple of days now without issue.
nice, two comments:
- no need for CONFIGURE_STYLE, its set by x11/xfce4/Makefile.inc
- please dont start COMMENT by an article, the previous one was fine imo
('modern & minimalist taskbar for Xfce') - no need for the final dot
either
other than that the port looks okay to me, i'll need another okay to
import it.
> I have also solved the "icons" issue I had with Firefox and Thunderbird.
> Basically, it is because the binaries are known as firefox-default and
> thunderbird-default in OpenBSD - I noticed this while running Windowmaker
> and docking those apps. I had to write my own
> ~/.local/share/applications/{firefox,thunderbird}.desktop files. And it also
> works to apply an icon to xterm(1). Do you think this package should come
> with a note about desktop files in MESSAGE or I should rather add those
> desktop files in the port?
I wont accept such desktop files in the docklike port, feels like a
kludge to workaround something broken somewhere else. What's the
difference between your desktop file and the original one ? There are no
'default' suffixes in the thunderbird/firefox binaries.. that has to be
some weird ICCCM property, because xprop on a firefox window indeed
gives WM_CLASS(STRING) = "Navigator", "firefox-default"
but i dunno where that comes from. Will have to dig.
How about xterm ?
Landry
Re: help creating new port: x11/xfce4/xfce4-docklike
Le 20/02/2023 à 10:19, Joel Carnat a écrit :
Hi,
I’ve spend part of the weekend trying to solve the Firefox / Thunderbird issue.
In details, those applications can’t be docked and don’t get their icon
displayed. Long story short: I couldn’t solve it.
I tried docklike on a couple of Linux distro and could reproduce the bug. Only
MX Linux doesn’t get the bug. But when getting its source and compile on
OpenBSD, the bug is still there.
I’ll continue digging and let you know if I can find a solution.
Regards,
Joel C.
Le 18 févr. 2023 à 15:02, Landry Breuil a écrit :
Le Sat, Feb 18, 2023 at 01:44:20PM +, Klemens Nanni a écrit :
2/18/23 13:16, Landry Breuil пишет:
i havent tested it yet, but here's a port of the latest git commit, with
a simplified Makefile.
Do you intend to upstream the local patches? I was surprised to see
them given your use of XFCE4_COMMIT.
i think joel wanted to upstream them :)
COMMENT must not start with articles or end in a full stop, I think.
Right
Should this be hooked up to one of the xfce meta packages?
Maybe, if it works and is useful..
Hi,
xfce4-docklike has been updated upstream and we don't need any patches
any more. Attached is the updated port. I've been using it on OpenBSD
7.3 amd64 for a couple of days now without issue.
I have also solved the "icons" issue I had with Firefox and Thunderbird.
Basically, it is because the binaries are known as firefox-default and
thunderbird-default in OpenBSD - I noticed this while running
Windowmaker and docking those apps. I had to write my own
~/.local/share/applications/{firefox,thunderbird}.desktop files. And it
also works to apply an icon to xterm(1). Do you think this package
should come with a note about desktop files in MESSAGE or I should
rather add those desktop files in the port?
xfce4-docklike.tar.gz
Description: application/gzip
Re: help creating new port: x11/xfce4/xfce4-docklike
Hi, I’ve spend part of the weekend trying to solve the Firefox / Thunderbird issue. In details, those applications can’t be docked and don’t get their icon displayed. Long story short: I couldn’t solve it. I tried docklike on a couple of Linux distro and could reproduce the bug. Only MX Linux doesn’t get the bug. But when getting its source and compile on OpenBSD, the bug is still there. I’ll continue digging and let you know if I can find a solution. Regards, Joel C. > Le 18 févr. 2023 à 15:02, Landry Breuil a écrit : > > Le Sat, Feb 18, 2023 at 01:44:20PM +, Klemens Nanni a écrit : >> 2/18/23 13:16, Landry Breuil пишет: >>> i havent tested it yet, but here's a port of the latest git commit, with >>> a simplified Makefile. >> >> Do you intend to upstream the local patches? I was surprised to see >> them given your use of XFCE4_COMMIT. > > i think joel wanted to upstream them :) > >> COMMENT must not start with articles or end in a full stop, I think. > > Right > >> Should this be hooked up to one of the xfce meta packages? > > Maybe, if it works and is useful.. >
Re: help creating new port: x11/xfce4/xfce4-docklike
Le Sat, Feb 18, 2023 at 01:44:20PM +, Klemens Nanni a écrit : > 2/18/23 13:16, Landry Breuil пишет: > > i havent tested it yet, but here's a port of the latest git commit, with > > a simplified Makefile. > > Do you intend to upstream the local patches? I was surprised to see > them given your use of XFCE4_COMMIT. i think joel wanted to upstream them :) > COMMENT must not start with articles or end in a full stop, I think. Right > Should this be hooked up to one of the xfce meta packages? Maybe, if it works and is useful..
Re: help creating new port: x11/xfce4/xfce4-docklike
Le 18/02/2023 à 10:16, Landry Breuil a écrit : Le Fri, Feb 10, 2023 at 06:42:46AM +0100, Landry Breuil a écrit : Le Thu, Feb 09, 2023 at 12:31:24PM +0100, Joel Carnat a écrit : Le 09/02/2023 à 08:05, Landry Breuil a écrit : Le Thu, Feb 09, 2023 at 01:01:48AM +0100, Joel Carnat a écrit : Hi, rather than applying upstream commits, its simpler to use XFCE_COMMIT in the port, see for example x11/xfce4/xfce4-taskmanager. i'll have a look and test your port in the coming days. i havent tested it yet, but here's a port of the latest git commit, with a simplified Makefile. Landry Great, thanks! It builds and runs ok on 7.2-STABLE and 7.2-CURRENT (#1054: Fri Feb 17 19:43:18 MST 2023). There are still weird behaviour with Firefox and Thunderbird. But things like xterm, thunar and keepassxc appear as expected. Not sure if it matters but to build the package on 7.2-STABLE, I had to replace the pcre reference in WANTLIB (from pcre2-8 to pcre). Regards, Joel C.
Re: help creating new port: x11/xfce4/xfce4-docklike
2/18/23 13:16, Landry Breuil пишет: i havent tested it yet, but here's a port of the latest git commit, with a simplified Makefile. Do you intend to upstream the local patches? I was surprised to see them given your use of XFCE4_COMMIT. COMMENT must not start with articles or end in a full stop, I think. Should this be hooked up to one of the xfce meta packages?
Re: help creating new port: x11/xfce4/xfce4-docklike
Le Fri, Feb 10, 2023 at 06:42:46AM +0100, Landry Breuil a écrit : > Le Thu, Feb 09, 2023 at 12:31:24PM +0100, Joel Carnat a écrit : > > Le 09/02/2023 à 08:05, Landry Breuil a écrit : > > > Le Thu, Feb 09, 2023 at 01:01:48AM +0100, Joel Carnat a écrit : > > > > Hi, > rather than applying upstream commits, its simpler to use XFCE_COMMIT in > the port, see for example x11/xfce4/xfce4-taskmanager. > i'll have a look and test your port in the coming days. i havent tested it yet, but here's a port of the latest git commit, with a simplified Makefile. Landry xfce4-docklike.tgz Description: application/tar-gz
Re: help creating new port: x11/xfce4/xfce4-docklike
Le Thu, Feb 09, 2023 at 12:31:24PM +0100, Joel Carnat a écrit : > Le 09/02/2023 à 08:05, Landry Breuil a écrit : > > Le Thu, Feb 09, 2023 at 01:01:48AM +0100, Joel Carnat a écrit : > > > Hi, > > > > > > I am trying to port the docklike XFCE plugin. > > > https://docs.xfce.org/panel-plugins/xfce4-docklike-plugin/start > > > > > > I followed faq/ports/guide.html and used x11/xfce4/xfce4-clipman as a > > > starting point. Everything compiles and build a package properly. The > > > checking tools do not identify errors. But still when launching the > > > docklike > > > applet, it dies and the following log is available in .xsession-errors: > > > > > > wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined > > > symbol 'inotify_init' > > > wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined > > > symbol 'inotify_add_watch' > > > > that probably means it failed to properly link against inotify, all the > > other errors come from that only - . All the patches should be > > upstreamed too :) > > > > Ok. I'll send them upstream if I can manage to use that software at all :) > > > im not sure at all wether it depends on inotify really, autoconf doesnt > > seem to search for it, and seeing that commit maybe the dep was dropped ? > > https://gitlab.xfce.org/panel-plugins/xfce4-docklike-plugin/-/commit/50941fc2cb741ed6dea26da6a50ce514114b40e8 > > i dunno if those glib bits work on openbsd. > > Ok, thanks. > > I have applied the diffs and now, the plugin starts and runs. > There are still bugs with icons (Firefox & Thunderbird) though ; > but I think I've seen this when compiling on Slackware Linux too. > > I'll try to understand what happens. But it may be related to > patches about .desktop files. > > While I was there, I had a look at FreeBSD ports tree. > They don't seem to apply inotify modifications on their side. > https://cgit.freebsd.org/ports/tree/x11/xfce4-docklike-plugin/Makefile > > Not sure why it would work as-is on FreeBSD and not OpenBSD. I mean, > don't both OS use the same glib sets? > > BTW, attached in the updated port tarball. rather than applying upstream commits, its simpler to use XFCE_COMMIT in the port, see for example x11/xfce4/xfce4-taskmanager. i'll have a look and test your port in the coming days.
Re: help creating new port: x11/xfce4/xfce4-docklike
On 2023/02/09 12:31, Joel Carnat wrote: > > While I was there, I had a look at FreeBSD ports tree. > They don't seem to apply inotify modifications on their side. > https://cgit.freebsd.org/ports/tree/x11/xfce4-docklike-plugin/Makefile > > Not sure why it would work as-is on FreeBSD and not OpenBSD. I mean, > don't both OS use the same glib sets? libinotify emulates the inotify api using kqueue, but it's quite resource intensive, it needs one FD per file within a monitored directory. FreeBSD installs it in in a location on the default library search path, we have it tucked away a bit more so that generally a port will need patching to explicitly use it rather than just picking it up. I suppose they have larger default FD limits and as a result are probably less concerned about software exhausting them.
Re: help creating new port: x11/xfce4/xfce4-docklike
Le 09/02/2023 à 08:05, Landry Breuil a écrit : Le Thu, Feb 09, 2023 at 01:01:48AM +0100, Joel Carnat a écrit : Hi, I am trying to port the docklike XFCE plugin. https://docs.xfce.org/panel-plugins/xfce4-docklike-plugin/start I followed faq/ports/guide.html and used x11/xfce4/xfce4-clipman as a starting point. Everything compiles and build a package properly. The checking tools do not identify errors. But still when launching the docklike applet, it dies and the following log is available in .xsession-errors: wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined symbol 'inotify_init' wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined symbol 'inotify_add_watch' that probably means it failed to properly link against inotify, all the other errors come from that only - . All the patches should be upstreamed too :) Ok. I'll send them upstream if I can manage to use that software at all :) im not sure at all wether it depends on inotify really, autoconf doesnt seem to search for it, and seeing that commit maybe the dep was dropped ? https://gitlab.xfce.org/panel-plugins/xfce4-docklike-plugin/-/commit/50941fc2cb741ed6dea26da6a50ce514114b40e8 i dunno if those glib bits work on openbsd. Ok, thanks. I have applied the diffs and now, the plugin starts and runs. There are still bugs with icons (Firefox & Thunderbird) though ; but I think I've seen this when compiling on Slackware Linux too. I'll try to understand what happens. But it may be related to patches about .desktop files. While I was there, I had a look at FreeBSD ports tree. They don't seem to apply inotify modifications on their side. https://cgit.freebsd.org/ports/tree/x11/xfce4-docklike-plugin/Makefile Not sure why it would work as-is on FreeBSD and not OpenBSD. I mean, don't both OS use the same glib sets? BTW, attached in the updated port tarball. x11_xfce4_xfce4-docklike.tar.gz Description: application/gzip
Re: help creating new port: x11/xfce4/xfce4-docklike
Le Thu, Feb 09, 2023 at 01:01:48AM +0100, Joel Carnat a écrit : > Hi, > > I am trying to port the docklike XFCE plugin. > https://docs.xfce.org/panel-plugins/xfce4-docklike-plugin/start > > I followed faq/ports/guide.html and used x11/xfce4/xfce4-clipman as a > starting point. Everything compiles and build a package properly. The > checking tools do not identify errors. But still when launching the docklike > applet, it dies and the following log is available in .xsession-errors: > > wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined > symbol 'inotify_init' > wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined > symbol 'inotify_add_watch' that probably means it failed to properly link against inotify, all the other errors come from that only - . All the patches should be upstreamed too :) im not sure at all wether it depends on inotify really, autoconf doesnt seem to search for it, and seeing that commit maybe the dep was dropped ? https://gitlab.xfce.org/panel-plugins/xfce4-docklike-plugin/-/commit/50941fc2cb741ed6dea26da6a50ce514114b40e8 i dunno if those glib bits work on openbsd.
help creating new port: x11/xfce4/xfce4-docklike
Hi, I am trying to port the docklike XFCE plugin. https://docs.xfce.org/panel-plugins/xfce4-docklike-plugin/start I followed faq/ports/guide.html and used x11/xfce4/xfce4-clipman as a starting point. Everything compiles and build a package properly. The checking tools do not identify errors. But still when launching the docklike applet, it dies and the following log is available in .xsession-errors: wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined symbol 'inotify_init' wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined symbol 'inotify_add_watch' (process:56575): GLib-WARNING **: 00:33:22.766: (../glib-2.72.4/glib/gerror.c:761):g_error_new_valist: runtime check failed: (domain != 0) (process:56575): xfce4-panel-wrapper-CRITICAL **: 00:33:22.767: Wrapper docklike-23: Failed to open plugin module "/usr/local/lib/xfce4/panel/plugins/libdocklike.so": Cannot load specified object. xfce4-panel-Message: 00:33:22.769: Plugin docklike-23 has been automatically restarted after crash. wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined symbol 'inotify_init' wrapper-2.0:/usr/local/lib/xfce4/panel/plugins/libdocklike.so: undefined symbol 'inotify_add_watch' (process:94743): GLib-WARNING **: 00:33:23.215: (../glib-2.72.4/glib/gerror.c:761):g_error_new_valist: runtime check failed: (domain != 0) (process:94743): xfce4-panel-wrapper-CRITICAL **: 00:33:23.215: Wrapper docklike-23: Failed to open plugin module "/usr/local/lib/xfce4/panel/plugins/libdocklike.so": Cannot load specified object. (xfce4-panel:46981): GLib-CRITICAL **: 00:33:24.884: g_child_watch_add_full: assertion 'pid > 0' failed I've tried various modifications as found in several ports but none solved the crash. Any ideas to solve those errors? Thanks, Joel C. PS: I've attached the port attempt. PPS: I'm using OpenBSD 7.2-STABLE/amd64. x11_xfce4_xfce4-docklike.tar.gz Description: application/gzip
