Code review comment for lp://staging/~larsu/indicator-messages/lp1365408

On Fri, 2014-09-19 at 07:10 +0000, Lars Uebernickel wrote:

> I've tried to keep it semantically similar to the 'Icon' key, which
> takes an absolute path and doesn't look at 'Path'. Icons are also
> something that is definitely part of the installed app, not its
> runtime directory. What benefit would we get from adding 'Path'?

I see what you're saying there, in thinking of Path as the runtime
directory. The way that we're building the desktop files for click
packages is that Path is the directory of the package. So path would be
the appropriate place to look for any relative icon locations. But,
that's overloading the key in that case.

So I guess that means we can think of this a couple ways:

Long term: We really need the messaging menu to get proper Click package
support. We've used the legacy FD.o dirs to limp through, but we should
do the work to do this right. It should be able to read the symbolic
icon name and figure out how to resolve that properly. That's not going
to happen for 14.10.

Short term: Perhaps we should add special handling for the generated
desktop files for the symbolic icon that resolves the directories and
provides absolute paths. Work arounds on top of work arounds, but that
would resolve the directory issue of the symbolic icon today.

I'll go ahead and add a UAL task to the bug and handle that in the
desktop hook, as I think that makes sense for the short term, but we
should definitely look at how to make messaging menu more click aware
sooner rather than later.