PATCH: Menu Spec - Categories

[Aaron J. Seigo]

On Friday 08 September 2006 14:08, you wrote:
> * Wrt Control Panels in KDE, these are KDE specific anyway, aren't they?

essentially, yes. even those that configure things like printing or samba
require kdelibs, so ... =)

> The KDE Control Center only handles modules that implement the KCM
> interface, no?

currently, yes. ditto for apps that use the KCM mechanism.

> The question there is mostly whether KDE will continue to
> show regular applications that list "Settings" as a category in the KDE
> menu.

not with the apps. instead we can support this much like we did with kicker:
through menu add ons.

> * Wrt Screensavers, even though KDE itself can store its screensavers
> under services, it could still also look under applications/ for
> .desktop files with a Screensaver category.

it could. but then why bother with services/ at all? i'd rather it be one way
or the other rather than a combination.

> In KDE3 there was
> kde-screensavers.menu that filtered applications with a
> "X-KDE-ScreenSaver" category into "System/ScreenSavers", effectively
> merging it with the entries under
> $KDEDIR/share/applnk/System/ScreenSavers/ Unfortunately that means that
> the Screensaver category is not universally supported on existing
> systems.

yes.

> The remaining question is whether it is sufficient to just have a
> .desktop file marked as being a screensaver or whether there are
> additional hidden assumptions made by either desktop.

there are... as William noted we use the actions support of .desktop files to
help with launching configuration, in-window and in-root display of
screensavers. he's comfortable with that mechanism as well, though it isn't
in GNOME yet.

kde doesn't actually use the Exec= parameter in the screensaver .desktop
 file.

and then of course there's the X-KDE-Category= key which lets us sort them
into categories like OpenGL, Flatland, etc. there's also kiosk stuff in
the .desktop files IIRC (e.g. "modifies screen", "requires gl") ...

> * Unrelated to the menu spec: There are existing third party
> screensavers such as Google's Picasa that use
> applnk/System/ScreenSavers/ to integrate with KDE. It would be
> unfortunate if KDE4 chose to break such applications.

William also mentioned Picasa; the way they manage cross-desktop screensaver
support is just a mess.

there are parts of KDE that simply are not designed appropriately for 3rd
party use. still, some have used those parts while the majority have been
scared off by them ;) it's a question of how much cruft is supported in newer
versions; how much do we lose? what do we gain?

i'd much, much rather see a "this is how screensavers are done" concept laid
down in a standard and then just use that. app developers can then target
that One True Way and they can keep their current hacks for supporting older
systems.

that said, i'd really like to see screensavers not in applications/; that's a
compromise i can see making for xdg purposes but it's not a design decision
i'd make otherwise. which says to me that it's probably not a great design
decision ;)

-- 
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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20060908/3f91d9a8/attachment.pgp