Closed thejdev closed 3 years ago
Hi. Has this been submitted to the EOS App Store?
@dcowan-london, I don't think this has been submitted to the EOS App Store. I do not think that this manifest file works either (I realised this after the pull request was merged). I believe this may be due to a Flatpak permissions issue - I assume that the app needs to be able to write to /usr/share/applications/ location or ~/.local/share/applications, but I do not know how to do this.
I ended up just building it manually and installing as a .
So the issue seems to be that WebPin tries to put the desktop in GLib.Environment.get_user_data_dir () + "/applications/"
(https://github.com/artemanufrij/webpin/blob/master/src/Objects/DesktopFile.vala#L163). GLib.Environment.get_user_data_dir ()
is XDG_DATA_HOME
, which in the Flatpak environment is /home/{user}/.var/app/com.github.artemanufrij.webpin/data
, which doesn't exist.
https://docs.flatpak.org/es/latest/conventions.html#desktop-files says that .desktop
files should be put in /app/share/applications/
, but this directory is readonly by the application.
Another issue: when selecting an icon for an app, WebPin uses the legacy file picker, which is confined to the FlatPak enviroment. This needs to be switched to the FlatPak FileChooser portal (https://docs.flatpak.org/en/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.FileChooser).
In the .desktop
files, Exec
needs to be Exec=flatpak run com.github....
) for FlatPak
This should probably be an Issue, now. Possibly continuing this issue - https://github.com/artemanufrij/webpin/issues/143?
So the issue seems to be that WebPin tries to put the desktop in
GLib.Environment.get_user_data_dir () + "/applications/"
(https://github.com/artemanufrij/webpin/blob/master/src/Objects/DesktopFile.vala#L163).GLib.Environment.get_user_data_dir ()
isXDG_DATA_HOME
, which in the Flatpak environment is/home/{user}/.var/app/com.github.artemanufrij.webpin/data
, which doesn't exist.https://docs.flatpak.org/es/latest/conventions.html#desktop-files says that
.desktop
files should be put in/app/share/applications/
, but this directory is readonly by the application.
Well, this was fixed by simply adding - '--filesystem=~/.var/app/com.github.artemanufrij.webpin'
to the manifest under finish-args
.
Created apps now get added to my Applications menu. But these apps don't appear in the WebPin interface (or work when launched). This is because WebPin gets the list by looking for installed apps (using GLib.AppInfo.get_all ()
- https://github.com/artemanufrij/webpin/blob/master/src/Services/DesktopFilesManager.vala#L55), and this is not available to FlatPak.
I guess there are two options here - have WebPin keep track of apps itself, or get it's list of apps from the .desktop
files in /home/{user}/.var/app/com.github.artemanufrij.webpin/data/applications
.
So I've hit another issue. Turns out that GLib.AppInfo
ignores .desktop
files who's Exec
lines contain a path which doesn't exist.
FlatPak apps are launched with flatpak run ...
, for example flatpak run com.github.artemanufrij.webpin https://google.com
. However, a .desktop
file with that as the exec line will be ignored by GLib.AppInfo
, as flatpak run
doesn't exist in the flatpak container.
There are a few options I can see here. One would be to create some kind of symlink in the flatpak container so that flatpak run
does exist.
The other option is to do what AppEditor does: patch GLib (https://github.com/donadigo/appeditor/blob/master/external/glib-appinfo.patch#L1). I don't think that's the best route, but it is an option.
Moved to #143
Hi,
Elementary OS 6 requires Flatpaks for the App Center, as noted in #143 .
To assist with this, I have created a Flatpak manifest file as per the directions listed here: https://docs.elementary.io/develop/writing-apps/our-first-app/packaging#flatpak-manifest
I am able to build the Flatpak and install using:
flatpak-builder build com.github.artemanufrij.webpin.yml --user --install --force-clean
Once this pull request is merged, webpin may be resubmitted to the App Center.
Thanks,
Jaidev V.