Identifying applications from windows to .desktop files

[Milan Bouchet-Valat]

Le mercredi 25 février 2009 à 11:23 +0100, Francois Gouget a écrit :
> Milan Bouchet-Valat a écrit :
> > 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.
> 
> Hmmm, I believe I understand. The term application is misleading because 
> what you really want to track is usage of the Start Menu entries.
Sorry for not being obvious. I've used much this terminology, and I
forgot it's not really natural/explicit. What I call applications is the
application as seen by the user on the desktop, not the installing
process. But that's how gnome-app-install works too.

> But then that raises another question. Why not simply track the clicks 
> on these entries in the Start Menu? This would tell you precisely how 
> many times a given entry has been used.
Sure, that's a traditional way of measuring it. But for several reasons
it seems more accurate to make stats based on actual time usage., one of
which being that, as you say below, XEmacs should be taken into account
too.

> > 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:
> 
> See, I was more equating applications with packages. So I would rather 
> have mapped the binary to the corresponding system package. But since 
> what you want to track is Start Menu entries, obviously that would be no 
> good.
Yes.

> > This approach assumes that there's no alternative way other than the one
> > referenced in the .desktop file to start the window.
> 
> Which is obviously a bad assumption. For instance I use XEmacs every day 
> and I can tell you I never once started it from the Start Menu.
> You will also have false positives. For instance I use the Firefox I 
> downloaded from Mozilla.org. So if you see a window called 'Firefox', 
> will you assume that this matches the .desktop file called 
> 'firefox.desktop'? If you do you'll make a mistake because the desktop 
> file refers to /usr/bin/firefox while the one I run is 
> '/opt/firefox/firefox'.
You're right, this scenario is a real pain to handle, but I can see no satisfying solution. Assuming that you start /opt/firefox/firefox using the absolute path, and not using $PATH, and that a .desktop file is installed in a standard dir (and using absolute path too), the commandline approach would work. But if you start it manually using ./firefox because you're hacking on it, that model is broken.

Relying on WM classes would be problematic too, since it would
require /opt/firefox/firefox to use a different class than distro
Firefox, which is not really possible.

> You will also make a mistake if any '.desktop' file contains a URI that 
> causes it to be opened in some application. This could be some 
> documentation in a PDF format, or maybe an html file in a web browser. 
> You will think that the user uses 'firefox.desktop' every day when in 
> fact he's using 'OpenOffice Tutorial.desktop' every day.
These are complex issues that come from the fact our desktops are not
rally document-centric, but not app-centric either. We work around that
be not showing applications known as being only viewers (Evince, Eye of
GNOME - could be oKular too); distributions do this in their .desktop
files already.

But for Web browsers and office suites, it's not really clear whether
users use them only from documents, or "for themselves", i.e. starting
them before to open documents. When browsing the Web, you tend to
consider the browser as a whole, with different tabs realted to very
different topics: the browser is a first-class object in the desktop (at
least for now). This is similar with word processing: you can open it to
look for recent text documents; but that could be changed to a
document-centric model. Other apps are clearly not document-centric at
all: mail apps, instant messengers... But this is a whole debate we
can't solve here... :-)


> > 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.
> 
> I don't see any direct relation between applications, .desktop files and 
> even less windows. And certainly not a one to one mapping.
> 
> I guess my perspective is also colored by my work on Wine. Microsoft 
> Word does have a desktop file, but I doubt its window properties will 
> let you  match the two. But then maybe you don't care about applications 
> that are not shipped with the OS. But then, if your goal is to optimise 
> the presentation of the Start Menu to show the most used entries, then 
> you cannot afford to ignore an application on this ground.
I had thought about this case, and we definitely care, but I don't
really know of you manage these .desktop files in Wine. Do you install
them in a spearate directory? Would the commandline directly match a
windows application then? Else I'm not sure if Wine can use the two
strings composing WM_CLASS to set this: first could be the name of the
window app, and the second could be Wine. For now, it's often set to the
same string, with differing case. See:
http://tronche.com/gui/x/icccm/sec-4.html

What I can say is that the whole issue is not easy to deal with. I'm OK
to use commandline if I can be sure we've considered every major problem
that can arise with this method.

Cheers