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
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
"Gonkulator" should show up in one of the menus.
"Gonkulator" does not show up in any results.
Creating a "hildon" subdirectory and placing the file there does not work
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
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?
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
a) The standard path needs to be the only system path to be taken into account
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
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
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
(In reply to comment #16)
> Any update now that the new version of Hildon has been released with Fremantle
Can somebody please answer Quim's question by testing this in Fremantle SDK
(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
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.
* A new application icon named "MODEST TEST" appears
* 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
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
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"...