touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #04545
[Bug 784478] Re: application:// URIs are malformed
** Changed in: unity (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity in Ubuntu.
https://bugs.launchpad.net/bugs/784478
Title:
application:// URIs are malformed
Status in Unity:
Fix Released
Status in Unity 2D:
Fix Released
Status in Unity Applications Lens:
Fix Released
Status in “unity” package in Ubuntu:
Fix Released
Status in “unity-lens-applications” package in Ubuntu:
Fix Released
Bug description:
For installed applications, the applications place daemon returns URIs of the form "application://filename.desktop", for example "application://gnome-sudoku.desktop".
According to the Nameprep RFC (http://www.rfc-editor.org/rfc/rfc3491.txt), host names should always be converted to lower case. The way those "application://" URIs are built, the desktop file name is the hostname. This is not a problem if the filename is already all lowercase (this is the case of most desktop files), but it becomes a problem with e.g. "SearchAndRescue.desktop".
This is a problem with the implementation of drag’n’drop from the dash
to e.g. the desktop in unity-2d, because the underlying toolkit (Qt)
strictly enforces the Nameprep RFC for URIs, and as a consequence
"SearchAndRescue.desktop" is converted to "searchandrescue.desktop".
I can think of at least two ways to fix this issue in the daemon
itself:
1) For installed applications, pass around the actual "file:///usr/share/applications/filename.desktop" URI
2) Or change the form of the "application://" URI so that the desktop file name is not the host name, e.g. "application://packagename/filename.desktop" like what is done with "unity-install://" URIs (this may be an issue though if package names are authorized to have upper case letters)
Solution 1 is probably simpler as ultimately client code will likely
convert the "application://" URI back to the real "file://…" URI
anyway.
To manage notifications about this bug go to:
https://bugs.launchpad.net/unity/+bug/784478/+subscriptions