Identifying applications from windows to .desktop files

[Milan Bouchet-Valat]

Le mardi 24 février 2009 à 23:38 +0100, Francois Gouget a écrit :
> On Sun, 22 Feb 2009, Milan Bouchet-Valat wrote:
> [...]
> > We are now tracking applications usage to build stats and present the
> > user with the most used apps. For this, we identify windows with their
> > WM classes, and want to map this to a specific application, i.e.
> > a .desktop file.
> 
> Why start from the window name/class? Why not enumerate running 
> processes to identify which binary is running? From that binary it seems 
> like you could get back to the package name if needed.
Well, first, we don't want to track background processes, but only
applications we've seen the user interacting with. The model is clearly
centered around objects that the user works with, which are windows.

Sure, we could see what command was used to start the app owning a given
window, and then get the desktop file associated with it. But this
method suffers from the same problems, as I said before in this thread:
> The "Exec" field can be used if we get the command that was used to
> start the app owning a given window;
> but that's a problem if we can use different commands, and
> OpenOffice.org can be started using "oobase" and used to edit text
> files.
This approach assumes that there's no alternative way other than the one
referenced in the .desktop file to start the window. I'm not an expert
in this area, but I fear there may be many breaches to this assumptions
if you take into account interpreters, symlinks, versioned files...

This is tricky and IMHO makes us go really far from the direct
relationship between applications, windows they own, and .desktop files
they're described by. And at the end, since we want to be able to
identify apps over the time, we would need to use either the command, or
the .desktop file name. The first can be versioned, move, etc., so we
need the other, which then becomes an app identifier. Any way I look, I
can't help thinking that this unique identifer is needed at the end -
and it's almost existing, since many apps already rely on its stability.

Cheers