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 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
