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