What value should event.actor have?

Bug #488790 reported by Seif Lotfy on 2009-11-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zeitgeist Framework
Fix Released
High
Mikkel Kamstrup Erlandsen

Bug Description

Our DB has some inconsistency when we insert applications:
recently used inserts something like /path/to/app.desktop
while the other loggers use application://app.desktop
WHICH ONE SHOULD IT BE

Siegfried Gevatter (rainct) wrote :

2009/11/26 Siegfried Gevatter <email address hidden>:
> Just app.desktop.

Although I'm not opposed to prefixing application:// if we want to
allow other types of actors, but I'd like to see some use case for
this before we add this complexity.

I am unsure what to do. I, for one, have several versions of Firefox installed. To identify which one sending the event we'd need the whole path to the .desktop file. OTOH getting the correct path to the .desktop file might not always be easy.

In the .recently-used.xbel apps are identified simply by their name, eg. 'gedit'. So one way to generate a canonical application name would be to take the name of the .desktop file but strip the .desktop part. Eg /usr/share/applications/anjuta.desktop has name 'anjuta'.

Since we are not required to use URIs everywhere I think that a simple application name like 'anjuta' is easiest to work with. If we want to add other types of actors they can come with their own namespace. Fx. if we want to store tweets with actor set to the person sending it we could use the mailto:<email address hidden> URI scheme to identify the contact. So in some sense applications are in the "default namespace" because they don't require an URI scheme.

So in short i propose simply 'app'.

 - recent.py has code to find the .desktop file for an app.

 - I'd prefer to have the .desktop file name as that's what seems to
be used by other projects (eg. GNOME Shell) to identify applications.
(However, just using "app" would simplify inserting quite a bit so I
may still change my opinion in favour of yours).

summary: - inconsistency in DB
+ What value should "actor" have?
Changed in zeitgeist:
milestone: none → 0.3.0
Changed in zeitgeist:
milestone: 0.3.0 → 0.3.1
summary: - What value should "actor" have?
+ What value should event.actor have?
Changed in zeitgeist:
assignee: nobody → Mikkel Kamstrup Erlandsen (kamstrup)
importance: Undecided → High
status: New → Triaged
Siegfried Gevatter (rainct) wrote :

We need to settle this...

My vote is for "app://<name>.desktop".

Siegfried Gevatter (rainct) wrote :

Or maybe better "app://<application_name>", where <application_name> is a lowercase string without spaces, hard-coded in plugin loggers and defined (for recent.py, etc) as the command you execute on the terminal to run the application (we may need to maintain a "quirks list" here for distros using different executable names for different apps, etc).

This has the advantage that I can just say "give me everything for 'firefox'" and don't need to worry whether it'll be firefox.desktop, firefox-1.desktop, mycustombrowserlink.desktop or whatever, which would be rather complicated.

What do you think?

I think that you proposal is ok, except that <application_name> should be the base filename of the .desktop file for the app. The reason is that apps need to be able to find the corresponding .desktop file easily - to show icons, internationalized names, etc.

With your proposal one needs to sift through all .desktop files and find the one with the right Exec field. That seems inefficient and inconvenient. Another benefit of the my proposal is that alleviates the distro-quirks problem to some degree (not fully though). The Exec field can readily be looked up from the .desktop file.

To be concise: I propose that /usr/share/applications/firefox.desktop has id "app://firefox.desktop" , or in Bash-terms "app://$(basename $full_path)". This also coincides with GLib definition of "application ids" (except the app:// prefix): see http://library.gnome.org/devel/gio/stable/gio-Desktop-file-based-GAppInfo.html#g-desktop-app-info-new

Siegfried Gevatter (rainct) wrote :

Yeah, +1.

I just documented this in trunk.

Changed in zeitgeist:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers