[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: desktop-base status (Was: gdm theme changes!)



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: pgpfD1KFBf3j_.pgp
Description: PGP signature


Reply to: