Tested under OS2008: Still there.

Comment 2 Eero Tamminen 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 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 2008-10-27 17:52:40 UTC

*** 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

Comment 6 Eero Tamminen 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).

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 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?

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?

Comment 11 Eero Tamminen 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 ;-))

(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.

Comment 16 Quim Gil 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 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?

(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

Comment 20 Andre Klapper 2009-05-13 19:50:42 UTC

Updating version info.

Comment 21 Quim Gil 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 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 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?

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"...