PATCH: Menu Spec - Categories

[Aaron J. Seigo]

On Thursday 07 September 2006 21:49, William Jon McCann wrote:
> That said, it seems to me that your changes are worthwhile.  So, what
> should we do?  Are you trying to explicitly forbid this type of usage?  Or
> can we interpret this, as written, as a strong recommendation but not a
> requirement?  Can we promote Screensaver to a main category similar to
> Settings?

William contacted me yesterday about screensavers as well with the hope that 
both GNOME and KDE can share some implementations which i agree would be very 
nice and make a lot of sense. =)

that said, i recently moved the screensaver.desktop files out of applnk/, 
which was something like applications/ before that existed. we have removed 
support for applnk/ in KDE4 so i had to do something with the screensavers, 
so i moved them to services/ which is where we put all of our 
non-application, defined-by-.desktop-file components. 

this keeps applications/ clean and clear in purpose and is a natural place for 
screensavers in KDE. putting them in applications/ which is really more 
geared towards creating application menus and launchers doesn't feel like a 
clean design.

in any case, we don't really have anything defined for screensavers across 
desktops. 

i see three possibilities here:

1) put screensaver files in applications/
	pros: both desktops already have code for finding entries in applications/
	cons: i'd have to change how KDE is finding screensavers, though that's not a 
huge amount of work. it does "pollute" applications/, making it a sort of 
dumping ground for all things .desktop. given that the screensaver .desktop 
files have categories that are actually pretty generic like "OpenGL" i'd be 
concerned about possible minor annoyances in setting up menus with rules such 
as "OpenGL, but not Screensaver"
2) put screensavers somewhere else altogether by themselves, e.g. in 
screensavers/
	pros: keeps the purpose and usage of applications/ clear
	cons: means altering screensaver loading code on both desktops. for kde this 
wouldn't be a big issue but still more work, similar to option #1 (i can't 
speak for gnome, but i assume it would be similarly easy?). it also means 
adding yet another directory somewhere which would need to be standardized.
3) make services/ a standard location where desktops apps can expect 
components, such as screensavers, to be
	pros: would keep applications/ clear, provide a precedent for future sharing 
of other similar types of services that might also exist there
	cons: would mean adding support for loading .desktop files from services/ to 
GNOME as well as standardizing anything unique about the .desktop files in 
services/, for example probably the ServiceTypes= key

i really don't like option #2 much, prefer option #3, but can understand 
William's leaning towards #1 given that that is how GNOME is doing it.

-- 
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/eb92e7ac/attachment.pgp