desktop-entry-missing-recommended-key Reply-To: In-Reply-To: <[🔎] 200909131031.01204.Sune@vuorela.dk> <[🔎] 87ws43vcr6.fsf@windlord.stanford.edu> X-Public-Key-ID: 0xBD41714B X-Public-Key-Fingerprint: 9CFE 12B0 791A 4267 887F 520C B7AC 2E51 BD41 714B X-Public-Key-URL: http://www.benfinney.id.au/contact/bfinney-gpg.asc On 12-Sep-2009, Russ Allbery wrote: > Not being involved in desktop package maintenance, I have no idea > what this whole thing is about. Could you fill in some more > details? On 13-Sep-2009, Sune Vuorela wrote: > The spec says about the StartupNotification key: (That's the ‘StartupNotify’ key, just to be clear.) > | If true, it is KNOWN that the application will send a "remove" message when > | started with the DESKTOP_STARTUP_ID environment variable set. If false, it > | is KNOWN that the application does not work with startup notification at all > | (does not shown any window, breaks even when using StartupWMClass, etc.). If > | absent, a reasonable handling is up to implementations (assuming false, > | using StartupWMClass, etc.). (See the Startup Notification Protocol > | Specification for more details). > > Every one implementing something working with desktop files will > have read this and knows that they need to do a 'reasonable > handling' if this key isn't present and how to handle the two > possible values. Right, but the “reasonable handling” is a least-worst compromise <URL:http://mail.gnome.org/archives/desktop-devel-list/2002-December/msg00060.html> for those very old applications written before this key existed in the standard. If the foo.desktop file doesn't declare whether or not it notifies when the program has finished its startup, the desktop environment can't assume the program will ever notify when its startup has completed; and so the “reasonable handling” will be to not give any startup notification. For applications whose startup takes a long time (where “a long time” is on the order of a couple of seconds or more), the user is left wondering why the system appears to be doing nothing at all, with no indication from the desktop environment that anything is happening. The desktop environment, on the other hand, can't know in the absence of the ‘StartupNotify’ key whether this is an application that will ever signal that its startup is complete, so can't give any feedback to the user on that state. Far better for those applications which *do* notify of startup completion to have that declared in their ‘foo.desktop’ file. That way the desktop environment can give immediate feedback to the user that an application is undergoing its startup (e.g. by showing a “Starting now” icon immediately), and change that indicator once the application signals that its startup is complete. > I see no reason why we should ask debian package maintainers to add > this key to their desktop files. The reason is to improve the quality of the operating system. No modern desktop application should be without an explicit declaration of the ‘StartupNotify’ value. Of course, the upstream developers of the application (who are the ones that best know whether or not the application implements startup notification) would ideally be the ones writing the key explicitly into the ‘foo.desktop’ file. > And a bit statistics on my system: > > /usr/share/applications$ find . | while read file ; do if grep -q > ^StartupNotify $file ; then grep ^StartupNotify $file ; else echo no ; fi ; > done | sort | uniq -c > 364 no > 14 StartupNotify=false > 54 StartupNotify=true Yes, exactly; there are, as a matter of fact, a lot of applications installed without declaring ‘StartupNotify’. They should all be fixed, to allow the startup status of applications to be signalled properly instead of using the least-worst implementation-dependent compromise. -- \ “We can't depend for the long run on distinguishing one | `\ bitstream from another in order to figure out which rules | _o__) apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 | Ben Finney <ben@benfinney.id.au>
Attachment:
signature.asc
Description: Digital signature