On Tuesday 07 February 2006 16:56, Waldo Bastian wrote: > Watch out what you ask for, you may get it.
;) > With such scheme it means that > after installing 6 applications your search path for a number of resources > also becomes 6 path's longer. this is what we have caches for, though, right? so that the extra paths only come into play, performance wise, on cache updates. > It also means that applications (in KDE's > case kded) will need to be modified to watch /etc/xdg.conf in order to pick > up new applications. yes. though that's easy enough to do. > Apart from that there will be a transition period in > which only recent applications/distributions will support /etc/xdg.conf. the sooner we start, though ... ;) > If there is concensus that that is the right long term direction and that > the benefits outweigh the disadvantages then I guess we should go that way. > I would like to hear some more cheers of support for that direction first > though. the only concern i have is whether or not it's easy enough for 3rd party apps to modify an xdg.conf file. i don't see why it wouldn't be, but i can see scenarios happening where 2 apps both add the same path causing useless clutter. i wonder if we shouldn't provide some simple command line tools to add/remove paths. this way in the future if we change course again ISVs won't have to change what they do (just call "addxdgdatadir /the/new/path" or what-have-you), we'll just update the tools. this would have the added bonus of Getting It Right(tm) without app developers having to do much work. thoughts? -- Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
pgpetElU9cthn.pgp
Description: PGP signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
