On Thursday 09 November 2006 10:58, Loïc Minier wrote: > On Thu, Nov 09, 2006, cobaco (aka Bart Cornelis) wrote: > > > * I heard a hint from Kevin Krammer who suggested putting a .sh > > > script in /usr/env to let startkde source it, it could change > > > KDEDIRS which is a list of directories to search for various > > > things, in particular configs; I thought about this, but I'm not > > > sure it can be cleanly implemented, in particular it should work > > > with locally modified environments, or other scripts setting > > > KDEDIRS; > > > > the above essentially describes re-implementing desktop-profiles > > as it applies to kde-specific settings > > Not really, I agree that desktop-profiles relies on KDEDIRS as well, > but desktop-profiles is intrusive and too generic for the problem of > setting the "simple" default. why do you find it to intrusive? for KDE all it does is set up KDEDIRS to include the wanted configuration sets. As you say above you _need_ to do that, and desktop-profiles by itself doesn not add any configuration. Idem for the other frameworks using environment variables (i.e. everything but gconf). As for being generic that's 'A Good Thing' as: Ultimately it's the local admin that should (be able to) decide what configuration sets get activated when. In the presence of multiple agents providing configuration sets that reuires a central, generic way of controlling them. Where 'controlling them' means 'controlling of certain specific environment variables' for all DE's but gnome, and in the case of gnome as a whole (as opposed to single apps using gconf) you still need to control the freedesktop variables in addition to the gconf sources. In the absence of a central generic mechanism you end up with multiple specific hacks all messing with the same variables, which means the local admin needs to: 1) identify all agents providing configuration sets 2) figure out the necessary environment variables and the specific semantics for each variable 3) for each agent figure out how it sets up those variables 4) figure out in which order the various agents variable set mechanisms are executed 5) given 3 and 4 figure out what the result is and then add in your own hack to adapt it to what you want NOTE: agents definining configuration sets would be upstream, the user, debian proper, various CDD's, the local admin, and (in bigger organizations) maybe some central ICT-department. -> at a minimum you'd have 2 sets: upstream and user -> by default you'd have 3: upstream, debian proper (through desktop-base), and the user NOTE: we'll already have desktop-base and debian-edu-config packages providing configuration sets' (and other CDD's are sure to follow), so the existence of multiple such agents inside debian is a reality that needs to be handled. > My biggest concern goes to the > per-startkde run configurability instead of a simple per-package > installation configurability; (? not sure If I'm getting your point here) starkde is per-run just like desktop-profiles. And for all non-gnome desktops (and for gnome where it uses freedesktop specs) where talking about setting up an environment variable which, by definition[1], is a dynamic per-run setting. If you're concern is that you don't want to have 100 packages all adding their own configuration set then: I agree that this isn't desirable BUT that's a different discussion that's completly orthogonal to mechanism used to activate the configuration sets that are present. [1] http://en.wikipedia.org/wiki/Environment_variable > it is of course possible to use > desktop-profiles to solve this problem, but as I explained, I don't > want to hook a piece such as desktop-profiles in 1) the default install if several debian-packages (and desktop-base will make this fact if it isn't already) are going to add configuration sets it should be done in a standard central way. As it stands that means desktop-profiles. -> if desktop-profiles has problems then let's get them out in the open so they can be adressed > 2) the list of things launched on every login, even over SSH. The desktop-profiles script is only run on 'ssh -X' logins, not all ssh logins, and this is a necessity for any such mechanism (IMO). After all when starting a graphical app, you need it's configuration -> you need to make sure the normal configuration sets are loaded when starting the app -> which means you need to activate the configuration sets of the various graphical/desktop frameworks on ssh -X login NOTE: that's not an academic concern, I added that after getting a bug repport due to a user running into kmail missing the part of it's configuration that was preconfigured by debian-edu-config, when logging in remotely > > NOTE: depending on exactly what the settings are set in the added > > config set (not applicable for just setting background, splash) setting > > KDEDIRS in startkde it isn't sufficient (as kde apps can be started > > outside a kde-session) > > The current goal is to set things such as desktop-background and splash > image, I think this is always in a startkde use case. as explained above I think it's an extremely bad idea for each entitiy providing a configuration set to mess with the environment variables in it's own way. Hence a generic solution is a must, which makes adding specific desktop-base KDEDIRS adapting code to startkde a poor solution IMHO. -- Cheers, cobaco (aka Bart Cornelis)
Attachment:
pgpK1z1mO0pNB.pgp
Description: PGP signature