maemo.org Bugzilla – Bug 1303
Hildon does not follow freedesktop.org standard, ignores ~/.local/share/applications
Last modified: 2010-01-25 20:50:24 UTC
You need to log in before you can comment on or make changes to this bug.
(for more information, search Maemo developers mailing list for "Can .desktop files live under /home/user?") Placing .desktop files into /home/user/.local/share/applications does not work - the files are ignored by the Hildon system, and do not show up in the menus. Steps to reproduce: 1) Create /home/user/.local/share/applications. 2) Place a .desktop file into there which can be identified in the menus. e.g. copy osso_calculator.desktop from /usr/share/applications/hildon and change the application name to "Gonkulator" 3) reboot device Expected results: "Gonkulator" should show up in one of the menus. Actual results: "Gonkulator" does not show up in any results. Extra information: Creating a "hildon" subdirectory and placing the file there does not work either.
Tested under OS2008: Still there.
> Tested under OS2008: Still there. The bug was missing internal ID, added. Unfortunately the fix seems unlikely to get into next release either, there were some unexpected issues(?) with other apps when the standard directories were used, so probably it goes to the release after that.
The internal ticket was closed as WONTFIX and therefore will be not fixed for Fremantle. Well... :-/
*** Bug 3817 has been marked as a duplicate of this bug. ***
Eero: bug 3817 is about getting rid of /usr/share/applications/hildon. Although the bugs are related, I just wanted to note that moving from /usr/share/applications/hildon to /usr/share/applications is the thing that needs to be fixed for bug 3817. Is this what's intended? Bug 3817 is also mentioned in http://wiki.maemo.org/Mainstream_Linux_Alignment
Hm. I was following the internal bug which this links. That old internal bug was about /usr/share/applications/hildon, but maybe more appropriate would have been to move the internal alias from this bug to the new one & marking that also as WONTFIX like the internal bug is (for Diablo & Fremantle).
Why is it so hard to just change /usr/share/applications/hildon to /usr/share/applications (which is a widespread standard btw!)? You could at least deprecate the hildon folder and make sure all new apps go into /usr/share/applications for Fremantle, so that in the next release you can finally remove this nonstandard folder path altogether. Also, lintian checks could then probably warn packagers that .desktop files have to go in to /usr/share/applications!
I haven't follow the internal history of this bug but let me interpret what has happened: 1 - A bug was filed a while ago and cloned internally. 2 - A busy developer or project manager decided that this was not an agreed requirement for his work on release X, and resolved as wontfix. I'll start again the process, this time through the right door as an enhancement request for the Maemo architecture. Let's see what can be done in the Fremantle timeframe although considering in the point we are it looks like a fix for Harmattan. Perhaps signaling the deprecation can be done in Fremantle, if the architects agree to the change?
Any updates?
Wouldn't is be a good start if TN's debian package would basically do this: 1. Create /usr/share/applications (if required) 2. If /usr/share/applications/hildon is a folder 2.a. mv /usr/share/applications/hildon/* /usr/share/applications/ 2.b. ln -s /usr/share/applciations /usr/share/applications/hildon This way: a) The standard path needs to be the only system path to be taken into account for TN. b) Applications/packages using old paths will still work trough the symlink The two things that are missing in this case are: I) How does an application find out whether it should use /u/s/a or /u/s/a/h? Possibly through the maemo-version.pc file; if it exists and is less than a cartain version, then use the old path. II) How do we identify legacy packages that use the old folders; we should have at least one OS version that properly supports both (so people have time to migrate)? How will we test those packages? How should application-manager react if /u/s/a/h is used?
> 2.b. ln -s /usr/share/applciations /usr/share/applications/hildon This is a recursive link... (except for the typo ;-))
(In reply to comment #11) > > 2.b. ln -s /usr/share/applciations /usr/share/applications/hildon > > This is a recursive link... (except for the typo ;-)) Yes, but issues with this can be solved pretty easily (eg. keeping and inode hash table for already read folders and always resolve symlinks before opening). I don't think it's really hard to solve.
(In reply to comment #12) > (In reply to comment #11) > > > 2.b. ln -s /usr/share/applciations /usr/share/applications/hildon > > > > This is a recursive link... (except for the typo ;-)) > > Yes, but issues with this can be solved pretty easily (eg. keeping and inode > hash table for already read folders and always resolve symlinks before > opening). I don't think it's really hard to solve. Why not simply get rid of /usr/share/applications/hildon altogether starting with Maemo 5 and let all the app developers that assume /usr/share/applications/hildon/ fix their (now-wrong) assumptions. It's easy to have a look at all the (binary) packages in Maemo Extras and "flag" or report packages that still put .desktop files in /usr/share/applications/hildon. For normal applications, it's just a matter of installing the .desktop files in a different location (just a matter of changing build/install files in the packaging code). For applications that deal with "all" .desktop files (Menu systems, app selectors, etc..) it's just a matter of changing one string in the source code. Or are there non-free components that depend on the .desktop files being in /usr/share/applications/hildon? I.e. apps that we can't change in the future?
I think this bug report has drifted significantly: This is about not supporting ***/home/user/.local/share/applications*** as a location for .desktop files. All the comments about /usr/share/applications/hildon, while interesting, are off-topic for this bug! The whole point of ***this*** bug is that users should be able to create .desktop files in a directory they normally have write privileges to, rather than a system directory that is normally read-only for a user.
(In reply to comment #14) > I think this bug report has drifted significantly: > > This is about not supporting ***/home/user/.local/share/applications*** as a > location for .desktop files. > > All the comments about /usr/share/applications/hildon, while interesting, are > off-topic for this bug! > > The whole point of ***this*** bug is that users should be able to create > .desktop files in a directory they normally have write privileges to, rather > than a system directory that is normally read-only for a user. Feel free to change the bug title to something which emphazises your intentions and to clone this bug for discussing the other issue.
Any update now that the new version of Hildon has been released with Fremantle alpha?
(In reply to comment #16) > Any update now that the new version of Hildon has been released with Fremantle > alpha? Can somebody please answer Quim's question by testing this in Fremantle SDK beta?
(In reply to comment #17) > (In reply to comment #16) > > Any update now that the new version of Hildon has been released with Fremantle > > alpha? > > Can somebody please answer Quim's question by testing this in Fremantle SDK > beta? I tried it in the beta SDK by copying the .desktop file provided by modest to .local/share/applications/testing.desktop and renaming the title. It did not work (i.e. pressing the top left button to show the applications did not show my new application icon.
Created an attachment (id=1192) [details] Test case (extract to ~ in Fremantle Beta, then try to open the app menu) Extract this tarball into your $HOME in Fremantle Beta. Then, start the environment with af-sb-init.sh start and click on the app menu icon. Expected outcome: * A new application icon named "MODEST TEST" appears Actual outcome: * The new icon does not appear
Updating version info.
Can someone help summarizing the situation in Fremantle (whether it's problematic or not)? Also, if you have a specific question to the Harmattan architects about freedesktop.org compliance I'm happy to forward it. To make sure we do things right in the new Qt based framework.
The fact is that Nokia won't fix this in Hildon anymore. Resolving as WONTFIX.
(In reply to comment #22) > The fact is that Nokia won't fix this in Hildon anymore. Resolving as WONTFIX. Is it fixed for Harmattan?
quite pitty actually, that the ~/.local/share/applications (/hildon) dir can't be used to store additional .desktop files - now, unless the user installs rootsh package (which is a risky bussiness for a regular user) and does some voodoo, he can't make a custom app icon (like specify custom parameters to an app, if he e.g. wanted to create a link to app, that always opens specified internet radio).. one thing is that maemo/Hildon doesn't (currently) support creating custom app shortcuts - it only uses those specified by .desktop files... but even if it could, they'd have to be put to /usr/.../hildon - which requires root access.. I however don't think it's a good idea to store user files to dirs other than "~" anyway... I see similar approach (requirement to use root account to perform trivial UI stuff) on many places in Maemo - and it bothers me.. this is not how a linux system should work, and it certainly could turn against (Nokia) developers - many security holes could exist in the system... bottom line is, ~/.local/share/applications should deffinately be supported as a search path for .desktop files - I can't think of reason, why this trivial task (worth 10 lines of code? tops...) should be marked "won't fix"...