Bug 1303 - (int-16392) Hildon does not follow freedesktop.org standard, ignores ~/.local/share/applications
(int-16392)
: Hildon does not follow freedesktop.org standard, ignores ~/.local/share/appli...
Status: RESOLVED WONTFIX
Product: Desktop platform
Application Menu
: 5.0-beta
: All Maemo
: High enhancement with 3 votes (vote)
: ---
Assigned To: unassigned
: task-navigator-bugs
: http://standards.freedesktop.org/base...
:
:
:
  Show dependency tree
 
Reported: 2007-05-07 15:32 UTC by David Hagood
Modified: 2010-01-25 20:50 UTC (History)
6 users (show)

See Also:


Attachments
Test case (extract to ~ in Fremantle Beta, then try to open the app menu) (565 bytes, application/x-compressed-tar)
2009-05-06 13:14 UTC, Thomas Perl
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description David Hagood (reporter) 2007-05-07 15:32:02 UTC
(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.
Comment 1 David Hagood (reporter) 2008-01-14 20:09:55 UTC
Tested under OS2008: Still there.
Comment 2 Eero Tamminen nokia 2008-01-15 10:33:16 UTC
> 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.
Comment 3 Andre Klapper maemo.org 2008-06-24 18:27:29 UTC
The internal ticket was closed as WONTFIX and therefore will be not fixed for
Fremantle. Well... :-/
Comment 4 Eero Tamminen nokia 2008-10-27 17:52:40 UTC
*** Bug 3817 has been marked as a duplicate of this bug. ***
Comment 5 Thomas Perl 2008-10-27 19:17:40 UTC
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
Comment 6 Eero Tamminen nokia 2008-10-28 10:06:41 UTC
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).
Comment 7 Thomas Perl 2008-10-28 10:15:10 UTC
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!
Comment 8 Quim Gil nokia 2008-10-28 10:32:11 UTC
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?
Comment 9 Sven Herzberg 2009-01-26 17:21:46 UTC
Any updates?
Comment 10 Sven Herzberg 2009-01-26 17:32:07 UTC
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?
Comment 11 Eero Tamminen nokia 2009-01-27 09:31:42 UTC
>   2.b. ln -s /usr/share/applciations /usr/share/applications/hildon

This is a recursive link... (except for the typo ;-))
Comment 12 Sven Herzberg 2009-01-27 13:27:44 UTC
(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.
Comment 13 Thomas Perl 2009-02-06 13:02:31 UTC
(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?
Comment 14 David Hagood (reporter) 2009-02-17 19:15:39 UTC
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.
Comment 15 Sven Herzberg 2009-02-18 11:55:16 UTC
(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.
Comment 16 Quim Gil nokia 2009-03-10 07:26:25 UTC
Any update now that the new version of Hildon has been released with Fremantle
alpha?
Comment 17 Andre Klapper maemo.org 2009-05-06 13:02:31 UTC
(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?
Comment 18 Thomas Perl 2009-05-06 13:12:24 UTC
(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.
Comment 19 Thomas Perl 2009-05-06 13:14:37 UTC
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
Comment 20 Andre Klapper maemo.org 2009-05-13 19:50:42 UTC
Updating version info.
Comment 21 Quim Gil nokia 2009-12-07 08:50:09 UTC
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.
Comment 22 Quim Gil nokia 2010-01-11 23:03:08 UTC
The fact is that Nokia won't fix this in Hildon anymore. Resolving as WONTFIX.
Comment 23 Eero Tamminen nokia 2010-01-12 16:03:29 UTC
(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?
Comment 24 Andrej Krutak 2010-01-25 20:50:24 UTC
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"...