Identifying applications from windows to .desktop files
johnflux at gmail.com
Tue Feb 24 18:29:07 PST 2009
2009/2/24 Milan Bouchet-Valat <nalimilan at club.fr>:
> 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
> 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.
You need to be realistic and realise that you aren't going to get
every app to change.
It does seem that the best way is to simply parse all the .desktop
files, pull out the Exec= name, and try to match that against the
binary used to run each window (Most Windows have a WM_PID which you
can use to get the binary name). Then you'll have to manually
maintain an exceptions file for funny apps like openoffice.
More information about the xdg