After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749254 - [Desktop Entry issue] Can't launch Type=Link icon
[Desktop Entry issue] Can't launch Type=Link icon
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-05-12 08:30 UTC by tyang
Modified: 2018-05-24 17:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description tyang 2015-05-12 08:30:47 UTC
I got some kind of test.desktop file like this

[Desktop Entry]
Version=1.0
Type=Link
Encoding=UTF-8
Name=Launch Server Administrator
Comment=Launch Server Administrator
URL=https://localhost:1311

And I did "ln -s /usr/share/test.desktop ~/Desktop/b.desktop" in case that we can click the icon from gnome desktop.

But while I double clicked the icon, it responds "There was an error launching the application"

After some debugging, nautilus will warned this error while it got empty info from glib/gio/gdesktopappinfo.c. 

Glib only support Type=Application so it return appinfo=NULL to nautilus.

So why glib does not support Type=Link as it is defined in freedesktop.org and in code?
Comment 1 Carlos Soriano 2015-05-12 08:34:43 UTC
->glib
Comment 2 tyang 2015-05-13 09:37:12 UTC
In nautilus, especially in function activate_files() in nautilus-mime-action.c

I can see if the launching .desktop file is a link, nautilus will call the glib function for the appinfo which will result in this issue. 
If it isn't, then nautilus will open the url in other application.

From source code, I can see the action equals to ACTIVATION_ACTION_LAUNCH_DESKTOP_FILE (link file) and ACTIVATION_ACTION_OPEN_IN_APPLICATION (launch the original file)

This judgment will lead the nautilus into different branches as I said before.

This is all I know so far.
Comment 3 Matthias Clasen 2015-05-14 03:19:38 UTC
> So why glib does not support Type=Link as it is defined in freedesktop.org and > in code?

GDesktopAppInfo is about applications. Type=Link and other such things are in the desktop entry spec mostly as historical accidents. Most of these other types are not useful.

For you example, you can just make it a regular desktop file with

Exec=firefox https://localhost:1311 

and it will work.
Comment 4 tyang 2015-05-15 04:33:19 UTC
(In reply to Matthias Clasen from comment #3)
> > So why glib does not support Type=Link as it is defined in freedesktop.org and > in code?
> 
> GDesktopAppInfo is about applications. Type=Link and other such things are
> in the desktop entry spec mostly as historical accidents. Most of these
> other types are not useful.
> 
> For you example, you can just make it a regular desktop file with
> 
> Exec=firefox https://localhost:1311 
> 
> and it will work.

During the debugging, I couldn't help agree with you.
I thought if someone wants to use Type=Link file, he could totally use "Exec" instead. I was just wondering why upstream has defined this type but not realize it.
Comment 5 GNOME Infrastructure Team 2018-05-24 17:50:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1037.