Summary: | recommend underscore in reversed domain names, deprecate hyphen/minus | ||
---|---|---|---|
Product: | Specifications | Reporter: | Simon McVittie <smcv> |
Component: | desktop-entry | Assignee: | Allison Lortie (desrt) <desrt> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | alexl, faure, hughsient, matthias |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 103914 | ||
Attachments: |
desktop-entry-spec: New section "File naming"
desktop-entry-spec: Formalize file naming recommendations desktop-entry-spec: Formalize the reverse DNS convention desktop-entry-spec: Deprecate dashes in well-known names |
Description
Simon McVittie
2017-10-11 10:27:56 UTC
Created attachment 134789 [details] [review] desktop-entry-spec: New section "File naming" This combines the notes on file naming that were previously part of "Basic format of the file" with the former appendix "Desktop File ID". Created attachment 134790 [details] [review] desktop-entry-spec: Formalize file naming recommendations * Add a link to the canonical definition of a D-Bus well-known name * Specify punctuation in terms of Unicode code points * Split syntactic rules (character set) and semantic rules (relationship to domain names) into separate paragraphs Created attachment 134791 [details] [review] desktop-entry-spec: Formalize the reverse DNS convention Also mention the D-Bus convention for the part after the domain name, which is widely deployed and seems as good as anything else. Created attachment 134792 [details] [review] desktop-entry-spec: Deprecate dashes in well-known names We don't really need two parallel forms of punctuation, and in particular DNS domain names only have one (dashes). If we choose one representation and deprecate the other, it makes the recommendation clearer for app authors. Dashes are not allowed in D-Bus object paths and interface names, are only conditionally allowed in Flatpak app IDs (they can only appear in the last element), and have a special syntactic role in Freedesktop icon names. An alternative approach would be to allow dashes, deprecate underscores, have a trivial conversion from DNS domain name to desktop file ID (except in the case of leading digits), and always special-case the transformation from desktop file ID/well-known bus name to object path, interface name or Flatpak app ID. However, that seems more error-prone, because it would make naive code incorrect; and general-purpose conversion from DNS domain name to desktop file ID is always going to need a special case anyway, to deal with leading digits (allowed in DNS but not D-Bus). I've raised this on various relevant mailing lists: https://lists.freedesktop.org/archives/xdg/2017-October/013959.html https://lists.freedesktop.org/archives/appstream/2017-October/000193.html https://lists.freedesktop.org/archives/dbus/2017-October/017334.html https://lists.freedesktop.org/archives/flatpak/2017-October/000811.html This looks good to me. Yes, looks good to me too. Do you have git access, or should I apply and push the commits? (In reply to David Faure from comment #7) > Do you have git access, or should I apply and push the commits? I am not a member of the 'standards' group on fdo; if you are, please apply and push. (In reply to Simon McVittie from comment #0) > Whichever one is chosen, I'll update the D-Bus Specification to recommend > that one and deprecate (un-recommend?) the other. Bug #103914. (In reply to Simon McVittie from comment #8) > (In reply to David Faure from comment #7) > > Do you have git access, or should I apply and push the commits? > > I am not a member of the 'standards' group on fdo; if you are, please apply > and push. Is there someone who can land this, and preferably refresh the web-accessible Desktop Entry specification document to pick up the change? Thanks! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.