Re: Menu system rewrite update (Aug 6 2002)
On Aug 06, Chris Lawrence wrote:
> What's new today:
>
> - Not a lot of code; just integrated Moshe's .startswith suggestion to
> make the code cleaner in parse_menus.py.
>
> - Two specification docs:
>
> * group_spec.txt: a replacement for the submenus that people seem to
> want to graft onto the official hierachy.
>
> * draft_policy.txt: a first-cut of a draft menu policy.
I guess I forgot the url... http://www.phy.olemiss.edu/~cnlawren/debmenu/
For convenience, the two documents are attached. The group spec I
will also forward to the XDG list.
Chris
--
Chris Lawrence <lawrencc@debian.org> - http://www.lordsutch.com/chris/
Proposed extension to .desktop specification
--------------------------------------------
New keyword: Group (<GroupName>;)+;
Type: string
Mandatory in .desktop files: no
Required interpretation by parsers: no
The "Group" keyword represents a request that the given .desktop file
be included in a submenu of the current menu (or grouped together in
the same menu with a subheader, if appropriate), if a "critical mass"
of entries in the same group appear in the menu and/or the parent menu
is "too crowded". The size of the "critical mass" is left entirely to
the implementor of the menu system (although the menu system may want
to make this "critical mass" parameter easily changeable by
end-users). The menu system may choose any specified GroupName for a
particular entry if multiple GroupNames are specified. No menu system
is required to implement this request.
If a Group keyword is specified, files <GroupName>.directory must
appear in the regular search path for desktop files, of type
Directory.
A GroupName is specified as <Vendor>-<MeaningfulName>, where Vendor is
the domain name of the Vendor (e.g. mozilla.org), the common name of
the vendor (e.g. Mandrake), or an accepted desktop environment name
(e.g. XFCE). The MeaningfulName should be selected such that vendors
do not produce non-conflicting packages with the same meaningful name.
The GroupName need not be user visible (i.e. the Name and GenericName
of the associated GroupName.directory need not be the same as the
GroupName).
Example uses:
- Components of a multiapplication suite of packages, such as
OpenOffice.org and Mozilla.
- Multiple user interfaces for the same program.
- Related menu entries to directly manipulate the behavior of a
running process (for example, Start/Stop/Update Buffers for a
distributed computing client).
Draft Policy for Debian Menu System
-----------------------------------
Incorporated by reference:
freedesktop.org Desktop Entry Specification 0.9.2
http://www.freedesktop.org/standards/desktop-entry-spec.html
VFolder .desktop Files Proposal Version 1.5
https://listman.redhat.com/pipermail/xdg-list/2002-July/000569.html
Where this document and the above documents disagree (including
changes introduced later versions of the above documents), this
document shall be controlling. We hope the differences are minimal.
Requirements:
-------------
.desktop files to be inserted into the Debian menu that are shipped by
Debian packages must be installed in /usr/share/applications.
.desktop files installed in /usr/share/applications by Debian packages
must comply with this policy. This policy does not affect any other
.desktop files that may be installed on the system.
.desktop files must comply with the standards mentioned above, with
the following amendments:
- The LegacyMixed encoding is forbidden. All .desktop files must be
in UTF-8 encoding.
- All .desktop files must include the Version and Encoding keys.
- All .desktop files must declare conformance with Version=1.
- All .desktop files must comply with the Debian menu
internationalization requirements, outlined below.
- All .desktop files must include a header X-Debian-Standards-Version
that indicates the version of this policy they comply to. The
definition of this header is identical to that in the mainline
policy document.
- All .desktop files must include a reasonable Categories key, per the
VFolder 1.5 specification (XXX - as extended). This will enable the
construction of the proper menu hierarchy by menu implementations.
(Incidentally, these requirements mean that no existing third-party
.desktop files will comply out of the box. You will need to modify
them to comply with this standard.)
Additional Headers:
-------------------
X-Debian-Standards-Version: an ASCII string that is a valid Debian
version number. The required content is outlined above.
X-Debian-TryPackage: an ASCII string that is a valid name for a Debian
package. The menu system may decide whether or not to include the
item in the menu based on this header. (In general, TryExec is more
portable and should be used instead for new menu entries.)
X-Debian-Legacy-Section: an ASCII string that gives the location of
the menu entry in Debian's former hierarchy. Deprecated and likely to
be ignored by most menu implementations.
Internationalization Requirements:
----------------------------------
All menu entries marked "localestring" must be in the UTF-8 encoding
of Unicode.
The untranslated "localestring" entries must appear in the English
language, using the most widely used variant of that language for
spelling and grammar. "Widely used" is defined as "requiring the
least number of unique translations to localize for all places." For
example, in general British spellings (from the Oxford English
Dictionary) should be used, along with North American terminology.
For example, a game of association football (the popular global sport
played with a round ball and 11 players per side) presented in color
should be referred to as a "colour soccer game," not a "color soccer
game"; "colour football game"; or "color football game" (Yes, this is
a contrived example - a better one is welcome.). Translations into
en_US and en_UK should be provided as necessary.
The following rules apply for other unqualified translations:
C, en: Do not use unqualified. (See above.)
es: Castillian Spanish as used in Spain.
fr: Modern French as used in mainland France.
pt: Modern Portuguese as used in Portugal.
(compare pt_BR)
zh: Unqualified zh is not acceptable; use zh_TW for traditional and
zh_CN for simplified Chinese.
Reply to: