Open grahamperrin opened 3 years ago
Let's revisit this once we have Firefox as a (wrapper) .app
bundle...
Thanks.
In the meantime, if it helps … in this frame from the screen recording, there was very faint hint of a circular 'running' indicator beneath the icon, some time after using QTerminal to run firefox
:
very faint hint of a circular 'running' indicator beneath the icon
Do you mean the blue dot? It is for the frontmost application. I guess we should make it white?
I never noticed blueness, I see black.
White might be better against the default desktop background but I wonder about other contexts.
Will set to white for now. At least the defaults need to work well together ;-)
Firefox (when installed by pkg
and not having an .app
bundle nor an .AppDir
) cannot be launched when pinned to the Dock because the Dock cannot figure out the corresponding .desktop
file.
/usr/share/applications
is hardcoded in systemappmonitor.c
as the location that is searched for .desktop files
(this does not exist on FreeBSD; QStandardPaths::ApplicationsLocation should be used instead)xWindowWMClassName
is used in utils.cpp
to find "matching" desktop files; xWindowWMClassName
of Firefox is Navigator
utils.cpp
tries to match Navigator
to
Navigator.desktop
- no such file exists)StartupWMClass
in the desktop files (e.g., StartupWMClass=Navigator
- no such key exists)Icon
in the desktop files (e.g., Icon=Navigator.png
- this does not match)Exec
in the desktop files (e.g., Exec=Navigator
- this does not match)As a quick and dirty workaround I will change the hardcoded /usr/share/applications
to /usr/local/share/applications
for FreeBSD; if you add StartupWMClass=Navigator
to /usr/local/share/applications/firefox.desktop
then you should be able to pin Firefox.
Even with these quick and dirty workarounds utils.cpp
does not really find the "matching" desktop files for many applications. This issue should be resolved "properly" in upstream cyber-dock (#19, #20).
This is one example for why we don't like XDG .desktop
files and are using .app
bundles and .AppDir
as our native application formats in helloSystem.
Work has been done in Filer since this had been reported, however this might also be an issue with firefox.desktop
missing a StartupWMClass
entry which might have to be fixed in FreeBSD Ports. But then, because the desktop file is called firefox.desktop
it should also match heuristically. Something is still wrong. Need to check with upstream again.
xprop
shows WM_CLASS(STRING) = "Navigator", "Firefox"
.
I made a Firefox wrapper app bundle (and Thunderbird) and neither works from the dock.
I might be able to make a "real" bundle, with CMake and Meson it's piece of cake.
Neither works from the dock.
Please describe what the issue is. If the Dock doesn't show the icon of an app bundle correctly, then possibly there is a bug in the Dock.
The issue is associating Firefox's wm class with its app bundle. If you pin it, close it, then try and launch it from the dock nothing happens.
FreeBSD% launch "Firefox Web Browser"
# Found "/Applications/Firefox Web Browser.app/Firefox Web Browser"
Launches Firefox and shows the correct icon for me. Can you confirm?
But the issue starts thereafter: if you right-click on the icon, it says "Keep Mozilla Firefox in Dock" instead of "Keep Firefox Web Browser in Dock", and if you choose it, then
FreeBSD% cat ~/.config/cyberos/dock_pinned.conf
(...)
[Firefox]
DesktopPath=
Exec=
IconName=firefox
Index=5
visibleName=Mozilla Firefox
(...)
This is clearly wrong. We should get something like
[Firefox%20Web%20Browser]
DesktopPath=
Exec=/Applications/Firefox Web Browser.app/Firefox Web Browser
IconName=file:///Applications/Firefox Web Browser.app/Resources/Firefox Web Browser.png
Index=1
visibleName=Firefox Web Browser
So here, the bug is likely that ithe Dock gets confused between the Firefox installed in the system (.desktop file) and the /Applications/Firefox Web Browser.app/
.
Hence, this is probably a bug in Dock.
Right. So for now, I can edit that file.
I'll see if removing the desktop file works.
In the example below, the issue is that the window that gets rendered on the screen is from process ID 2164 rather than 2162. Dock tries to look up process ID 2164 to see whether it is in an AppDir or .app bundle, but it isn't (2162 is). Hence we need to find a way to
.AppDir
or .app
bundle was launched by and belongs to an .AppDir
or .app
bundle, or.AppDir
or .app
bundle. For example, process 2161 could export an environment variable like APP_BUNDLE=/Applications/Firefox Web Browser.app
which then would get propagated to all of its child processes2161 - I 0:00,05 /usr/local/bin/launch /Applications/Firefox Web Browser.app
2162 - I 0:00,12 python3 /Applications/Firefox Web Browser.app/Firefox Web Browser (python3.7)
2163 - I 0:00,05 launch /usr/local/lib/firefox/firefox
2164 - S 0:03,31 /usr/local/lib/firefox/firefox
2166 - S 0:01,52 /usr/local/lib/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 232414 -parentBuildID 20210401095825 -appdir /usr/local/lib/firefox/browser 2164 tab
2169 - S 0:00,62 /usr/local/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 6190 -prefMapSize 232414 -parentBuildID 20210401095825 -appdir /usr/local/lib/firefox/browser 2164 tab
2170 - S 0:00,32 /usr/local/lib/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 7049 -prefMapSize 232414 -parentBuildID 20210401095825 -appdir /usr/local/lib/firefox/browser 2164 tab
Good idea, but if say Firefox was to launch /usr/local/bin/filer-qt as a subprocess...
I wonder if anyone has seen the same issue in AppImage with the ld library path variable...
https://user-images.githubusercontent.com/192271/105627664-0e857300-5e30-11eb-935a-086936ec9a3c.mp4