GNOME Bugzilla – Bug 767101
Support system-installed web apps when GIO_LAUNCHED_DESKTOP_FILE is unset
Last modified: 2016-09-01 21:51:14 UTC
It should be possible to start system-installed web apps even when GIO_LAUNCHED_DESTKOP_FILE is unset, to make sure the web apps work in any desktop environment and to make it possible to test that the Exec command works when running it from the command line. One solution would be to add a new command-line argument to allow specifying the path to the desktop file manually, and pass this in the desktop file instead of profile. But I think we could instead add an optional argument to --application-mode to take the path to the desktop file; then it would only fail if the optional argument is not passed. Of course, generating such desktop files would be slightly annoying, as in Autotools it would require a configure replacement, but this isn't the end of the world. Carlos, what do you think?
Created attachment 328883 [details] [review] Allow running system web apps outside GNOME Expect system web apps to pass the desktop file path via the command line using the existing --application-mode flag, rather than requiring that Epiphany be started via Gio. This allows Epiphany to compete with Electron as a choice for running web apps that work outside GNOME. It also breaks any existing system web apps, but that's probably fine as this feature is new in 3.20 and I'm not aware of anybody using it yet.
OK František, unless someone objects, I'm going to include this in tomorrow's Epiphany release to unblock the developer portal project; it should hit rawhide in two or three days. We might change this "API" prior to the 3.22 release, since it's not very good, but I'll give you a heads-up if we do so.
Cool, thanks! I'll keep watching this for following changes.
Attachment 328883 [details] pushed as 857805a - Allow running system web apps outside GNOME
Oh, here's an improvement: instead of passing the path of the desktop file to application mode, instead let's just require passing the desktop file basename ("fedora-developer-portal.desktop") and let Gio look it up in the standard desktop file locations.
The following fix has been pushed: 561d2df Expect only the desktop file basename to be passed on command line
Created attachment 330095 [details] [review] Expect only the desktop file basename to be passed on command line Instead of passing the path of the desktop file to application mode, let's just require passing the desktop file basename ("fedora-developer-portal.desktop") and let Gio look it up in the standard desktop file locations.
Here's an example Exec line you can use, for a desktop file is named "fedora-developer-portal.desktop": Exec=epiphany --application-mode=fedora-developer-portal.desktop /usr/share/fedora-developer-portal/index.html The argument to --application-mode just has to match the name of the desktop file.
So, today, I tried running updated Fedora Developer Portal with new epiphany-runtime (3.21.3-2.fc25) on KDE Rawhide. $ epiphany --aplication-mode=fedora-developer-portal.desktop /usr/share/fedora-developer-portal/index.html Invalid desktop file passed to --application-mode It doesn't matter if I put just name for .desktop or absolute path. .desktop file ĺooks like: [Desktop Entry] Name=Fedora Developer Portal Comment=The developer workstation you've been waiting for. GenericName=Documentation Exec=epiphany --application-mode=fedora-developer-portal.desktop /usr/share/fedora-developer-portal/index.html Icon=fedora-developer-portal StartupWMClass=fedora-developer-portal Type=Application StartupNotify=true Categories=Development; MimeType=text/plain;
Where is the desktop file saved, is it under ~/.local/share/applications or /usr/share/applications? The desktop file needs to be saved to one of those standard paths (technically, under $XDG_DATA_DIRS and $XDG_DATA_HOME) for it to work.
It's inside the /usr/share/applications/ . You can try latest rpm: https://drive.google.com/file/d/0B-kL1imq8JJzZ1otRHBpWjlLR0k/view?usp=sharing
I can reproduce the problem; I'll try to investigate soon.
(In reply to Michael Catanzaro from comment #12) > I can reproduce the problem; I'll try to investigate soon. Ah, the desktop file you install in the RPM does not match the desktop file in comment #9: it's missing the argument to --application-mode! When I manually edit the desktop file to change --application-mode to --application-mode=fedora-developer-portal.desktop, then it works.
Yes, I've forgotten to rebuilt rpm with correct .desktop file. But somehow I am still experiencing same issue with fixed .desktop file (rebuilt rpm with correct .desktop is here: https://drive.google.com/open?id=0B-kL1imq8JJzSTl5cmFWSUNDZ2c ). I am testing on latest Rawhide (KDE and GNOME).
OK, I can reproduce in my rawhide VM... reopening yet again.
I'm still planning to get back to this; sorry it's been delayed a bit.
OK Frantisek, sorry for the delay in getting back to this.... I tested your latest RPM today on Fedora 25 Alpha, KDE spin... and it works for me just fine the *second* time I run fedora-developer-portal (less a bunch of critical warnings coming from Epiphany, which shouldn't be there, but which I haven't gotten around to fixing), both from the command line and from the desktop file. The first time I run fedora-developer-portal, Epiphany crashes. I can reproduce the crash again by deleting ~/.config/epiphany/app-epiphany-fedora-developer-portal-fd60f6b8ebe9576f9c05475ac06ae40817f52f09 I'm trying to get a backtrace, but having trouble installing debuginfo due to some error with dnf: $ sudo dnf debuginfo-install epiphany-runtime-3.21.90-1.fc25.x86_64 enabling updates-debuginfo repository enabling fedora-debuginfo repository enabling updates-testing-debuginfo repository Error: Failed to synchronize cache for repo 'updates-debuginfo' I guess I'll try again later.
I installed debuginfo manually from koji. Very short backtrace:
+ Trace 236609
František, this makes it work on the first run for me. Fix will be in the 3.21.92 release (due September 12). Please do confirm that it works for you on the second run, as otherwise there must be some other issue. The following fix has been pushed: b9be331 web-app-utils: don't crash if address is not a URI
Created attachment 334610 [details] [review] web-app-utils: don't crash if address is not a URI Let's tolerate desktop files passing an absolute path or something instead of a URI.
(In reply to Michael Catanzaro from comment #19) > František, this makes it work on the first run for me. Fix will be in the > 3.21.92 release (due September 12). (If you need it sooner, I can release it sooner.)