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)
pgpf5Pxt4Q3mw.pgp
Description: PGP signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
