PATCH: Menu Spec - Categories

[Bastian, Waldo]

Based on Aaron's mail I'm inclined to say that use of the Screensaver
category is not sufficiently standardized between the desktop
environments as they exist today. I suspect that the same is true for
the TrayIcon and Applet categories (And what about Shell?)

I think we should come up with a separate specification for screensavers
which for now would have a this-is-where-we-want-to-go status and not a
this-is-what-works-today status, like the Menu Spec 1.0. Looking at
Picasa I suspect that the Google people have some additional items that
they would like to see addressed wrt screensavers.

Wrt the Menu Spec. Would it make sense to mark the Screensaver, Applet
and TrayIcon as "Reserved", with a note saying that they are in use for
desktop specific purposes that's beyond the scope of the spec and that
they should only be used with an appropriate OnlyShowIn= line?

Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/opensource
OSDL DTL Tech Board Chairman

>-----Original Message-----
>From: xdg-bounces at lists.freedesktop.org [mailto:xdg-
>bounces at lists.freedesktop.org] On Behalf Of Aaron J. Seigo
>Sent: Friday, September 08, 2006 2:05 PM
>To: xdg at lists.freedesktop.org
>Subject: Re: PATCH: Menu Spec - Categories
>
>On Friday 08 September 2006 14:30, Bastian, Waldo wrote:
>> that things will work properly. One option is to make ScreenSaver a
main
>> category with a note that recommends the inclusion of
>> "X-KDE-ScreenSaver" as well, KDE must of course be willing to
(continue
>> to) support that in KDE4 then.
>
>i'd really prefer One Way of doing it so that application developers
can
>target that and we can move forward and not have N different mechanisms
>within KDE4. particularly since in this case it would mean adding
something
>new that would be marked as "deprecated" at the time of addition. i am
>willing to patch KDE 3.5 if it makes sense to do so, though of course
that
>does nothing about historical releases.
>
>i guess it comes down to whether or not we're targeting KDE3 with this
or
>figuring that xdg screen saver support is a "for the next releases"
thing.
>
>we already have things to sort out within the .desktop files to get it
to
>all
>work together, which between William and myself i'm sure we can do, so
it's
>not particularly like the only blocker at the present time is the
location
>of
>the .desktop files and the Categories= entries.
>
>reading over the whole patch to the appendix again, it crystalized
quite
>clearly in my mind that where there's a bit of a difference of
viewpoint is
>whether applications/ is meant for, well, applications or if it is
really
>meant as a dumping ground to describe all available software inc 3rd
party
>contributions. the Applet category, for instance, is much like the
>ScreenSaver one to me. we don't put kicker applets in applications now,
and
>i
>don't see that changing particularly. the only benefit i see to
providing
>an
>Applets category in applications/ is to provide a Well Known place for
>those
>entries to go for third parties. which seems something of an abuse of
>applications/, but otherwise a good idea.
>
>personally as an external developer -or- as someone designing with
"making
>a
>great desktop" first in mind, i'd expect there to be a place to throw
such
>components that weren't applications, which would allow namespacing and
>which
>was Well Known. where i wouldn't have to worry about Categories= which
is
>suited for building visual hierarchies and networks or running into
>application entries that are using Categories= appropriately for those
>purposes, but instead have a mechanism to define the purpose of the
>component
>so the applications that use them can easily query for them.
>
>it would make the menu spec more straightforward as well since it would
>have
>one particular purpose in mind only.
>
>--
>Aaron J. Seigo
>Undulate Your Wantonness
>GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
>Full time KDE developer sponsored by Trolltech
(http://www.trolltech.com)