On 09/09/10 03:50, Ohly, Patrick wrote:
On Wed, 2010-09-08 at 20:25 +0100, Alexander Bokovoy wrote:
On Wed, Sep 8, 2010 at 21:29, Auke Kok<auke-jan.h....@intel.com> wrote:
Do we need bugs against handset components for not providing the proper
"MimeType=..." fields in the respective handset app's .desktop files?
Yes, we do need that. See libcontentaction for details.
Ah, great! That was what I was looking for. Thanks for the pointer.
We also need libcontentaction in the Meego, if it is not yet there.
It's there, but I think developers are not aware of it. None of the
Handset app .desktop files contain a MimeType, or even specific actions
for libcontentaction. I'll ping some people.
I've built the docs for libcontentaction (unfortunately not bundled in
any of the .rpms). I think the introduction page is clear enough,
although I still need to experiment a bit.
First, in the section "Writing .desktop files for actions", is the idea
that there is one .desktop file for each application, or one .desktop
file for each action? I think it is the latter, because the same
application might support multiple actions, but it is not mentioned
explicitly.
there's a way to do multiple actions per application:
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-0.9.4.html#example
I'm not sure if that helps in this case, but it's worth looking at..
Type=Application in the example is a bit misleading. Is there no better
type that can be used instead? The solution with "Type=Application" and
"NotShowIn=X-MeeGo;" seems a bit hacky. Just asking, I'm sure this was
considered already ;-)
from the spec:
Type There are 4 types of desktop entries:
Application, Link, FSDevice and Directory.
so no, nothing useful there. Seems like Application is the only value
most people will see here.
BTW, some parsing code is unhappy about the ;; comments in the example:
duihome: MDesktopEntryPrivate: Invalid .desktop entry line: ";; Defining a
localization method:"
...
I think this needs to be a # for the comments.
it does, that's a bug.
Here's the result of a little bit of experimenting. contact:78216381 is
a real contact, as found by tracker-explorer:
$ grep -v '^#' /usr/share/applications/show-contact.desktop
[Desktop Entry]
Type=Application
Icon=gallery.png
NotShowIn=X-MeeGo;
Name=View contact
MimeType=x-maemo-nepomuk/person-contact;
Exec=/usr/bin/echo %U
$ lca-tool --actionsformime x-maemo-nepomuk/person-contact
show-contact
$ lca-tool --tracker --print contact:78216381
show-contact
$ lca-tool --tracker --triggerdefault contact:78216381
contact:78216381
nice
It
already implements mapping of handlers for the ontology parts.
Ideally, it also need to be bound on Qt at QDesktopServices's url
handler provider so that QDesktopServices::openUrl() will work with
any of those. I think it is done in harmattan but not in the stock Qt
yet.
What would the URL look like for the Tracker example above?
You mentioned elsewhere that you didn't find a pointer to that code.
Marius, do you know more about that?
I see that /usr/share/applications/show-contact.desktop also has entries
for calendar, for example:
<tracker-condition name="calendar-event">
{ ?uri a ncal:Event . }
</tracker-condition>
Do you have an action for that in Harmattan? May I ask how you solved
the problem that I mentioned to Alvaro (extracting the right
recurrenceId from Tracker)?
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
