On Tuesday 27 December 2005 11:45, you wrote: > > - XDG_DATA_DIRS. this has already caused problems for us with the menu > >spec in that it can't be changed within a session, > > Why would you want that?
because they are set wrong. so the user has to set up the env var then log out, log back in ... innevitably they try and just set it in a terminal window; or they'll set it, rebuild sycoca (and now things are good) and then get annoyed when it "randomly" breaks again (e.g. when a new .desktop file appears or the cache is some other way invalidated). it's very confusing for normal, average users (where "normal, average" is meant to refer to our current user base demographics, not even the larger world of computer users). no, it should've been a simple configuration item set in a file in a system wide config location. that way new desktop installations could just install an updated file (or a new file altogether). look at the layout of /etc/profile.d; now there's a good solution. we already look at hardcoded locations for certain vars, so it's not like that's not doable. > >can't be changed by > >installing a new desktop (think of multiple desktops on the same > > system) > > Each desktop startup sequence can adjust it accordingly, if so desired. and yet they don't. i chalk this up to it being an ephemeral "environment variable" rather than a well defined file-backed value. it also means we have one mechanism for overriding values for group policy (cascading configuration flies) and another for overriding these values for XDG_DATA_DIRS (different env profiles based on group membership, sth you generally have to hack up yourself just like the bad old days before kiosk's profile dirs in /etc/kderc. it probably ought to become /etc/xdgrc in the future and handle these things. > >and if often just plain set incorrectly (if at all) by packagers. > > Possibly, yes. often. with 3.5 we've seen this problem with both Red Hat and Kubuntu. > >honestly, > >using XDG_DATA_DIRS was a huge mistake. i have the numerous (invalid) > > bug > > >reports to back that statement up. let's not replicate that mistake to > >other specs. > > I think there is some value in consistency here. By using XDG_DATA_DIRS > consistently across specs, the problems associated with it only need to > be fixed once. one can fix a leaky dinghy all they like, doesn't change the fact that it may well be time to get a new one. given that this creates problems for real world people over and over, and not just neophytes but even people doing deployments and people designing operating systems, it is worthwhile to reconsider the whole approach. > Note that a lot of the problems seen with XDG_DATA_DIRS are actuallly > problems of the menu specification. See no. these are problems with XDG_DATA_DIRS. i've been dealing with them with increasing frequency since KDE 3.4 on bugs.kde.org and irc both. very frustrating. -- 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)
pgp9VDyBisGj9.pgp
Description: PGP signature
_______________________________________________ Desktop_architects mailing list [email protected] https://lists.osdl.org/mailman/listinfo/desktop_architects
