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

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

On Thu, Nov 09, 2006, cobaco (aka Bart Cornelis) wrote:
> >  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?

 I explained it in my message, and we discussed this in a long IRC
 conversation as well.  But let me repeat some arguments nevertheless.

 First, the simple fact that it's a longish shell script run on each
 login with intermediate files is scary.  Sample things which scare me
 right away:
 - 20desktop:42:
  #make sure we start with empty variables
  => IIUC, KDEDIRS set manually by an user in the past would be discarded
 - full of sort + cat + grep + cut + sh (!!) + expr invocations, on
   *each* login; spawning commands has a cost, and will slow all logins,
   even those that don't care about KDE settings
  => bad performance-wise
 - 20desktop:46:
  => adds a *write* on login; and if I ^C my ssh, the tempfile isn't
  deleted (you might want a cleanup trap)

 So, IMO introducing a package like this one on *all* desktop installs
 in a no-go at this point in the release.

 If you consider the hook I proposed in the list of dirs scanned by KDE
 for KConfig instead, it is far less intrusive and simply requires
 running a merge at package installation time, not on each login.

 Second, per-login flexibility is not useful for desktop-base.  This is
 about setting the defaults.  For example, a derivative can simply edit
 desktop-base to change the artwork of the whole distro.  Sure,
 desktop-profiles permit doing more, and one can still install
 desktop-profiles, it should work.

> 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).

 No, the third proposal I made for KDE is not about setting KDEDIRS.
 Beside, with proposal 2 I only set KDEDIRS, nothing more, nothing less.
 Your shell script calls a lot of commands, generates files etc.; it is
 not comparable, sorry.  I already acknowledged that desktop-base could
 rely on the same "KDEDIRS" mechanism you use for desktop-profiles, but
 this is simply because this is the only public hook for overriding
 KConfig items...

 And FWIW, I still consider the solution to set KDEDIRS very ugly; I
 only investigated this option because it requires zero patching of
 kdelibs and was suggested by a KDE maintainer.

> 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.

 It's nice you have ultimate goals that go beyond desktop-base needs,
 but this is *too* generic, and your genericity has a high cost.  I can
 understand that you have some use cases where you want to change
 KDEDIRS on each login because membership to a UNIX group changed, but
 this is far from being common, and adds a lot of complexity as well as
 risks.  On an off-topic note, I think DEs are moving away from
 environment variables as configuration source; the future looks like a
 dbus world.

> 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

 So, you're saying that your solution has a broader spectrum in that it
 can help an administrator to enforce a configuration upon all DE at
 once.  Sorry, but I think this is bullshit: desktop-profiles doesn't
 hide the name of the actual GConf settings/KConfig items that one needs
 to change in order to say, set the background.  What desktop-profiles
 currently do is permit configuring the order in which completely
 unrelated databases of settings are cascaded.  How does that help?

 You seem to claim that suddenly, there is a one stop shop for
 configuring all of KDE and GNOME and Xfce in a couple of clicks, but
 one still has to write:
 for KDE and:
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE mcs-option SYSTEM "mcs-option.dtd">

            <option name="brightness_0_0" type="int" value="0"/>
            <option name="color1_0_0" type="color" value="            7936,           16128,           28416,           65535"/>
            <option name="color2_0_0" type="color" value="           26880,           34048,           46848,           65535"/>
            <option name="colorstyle_0_0" type="int" value="1"/>
            <option name="imagepath_0_0" type="string" value="/usr/share/images/desktop-base/desktop-background"/>
            <option name="imagestyle_0_0" type="int" value="3"/>
            <option name="showdm" type="int" value="1"/>
            <option name="showdmi" type="int" value="1"/>
            <option name="showimage_0_0" type="int" value="1"/>
            <option name="showwl" type="int" value="1"/>
            <option name="showwli" type="int" value="1"/>
 for Xfce / XDG.

 To me, the bulk of desktop-profiles is about login-time cascading of
 configuration, and no, we don't need that for desktop-base which is
 simply a one stop package for derivatives to change the very default

>    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	

 I agree we need some form of categorization.  update-gconf-defaults
 demonstrates one way of doing this.  I like the general concept, just
 not the fact that it happens at login time, under a long shell script.

>    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.

 Yes.  And I agree that desktop-profiles has a form of "priority
 handling" -- just like GConf has.  Except in the end GConf offers a
 single database of merged settings for this use case, while
 desktop-profiles only cascades database of each use case, which doesn't
 scale well, but that's irrelevant.

> >  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.

 No, the case of a /usr/env/10_desktop-base.sh which would statically
 set KDEDIRS to $KDEDIRS:/usr/share/desktop-base is very different from
 the case where KDEDIRS is computed from a set of commands (possibly
 expensive, such as looking up groups) and files.

>    If you're concern is that you don't want to have 100 packages all adding
>    their own configuration set then:

 Well, one could discuss the scalability of the desktop-profiles chain
 of KDEDIRS, but that's not the point I was making.

> >  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

 I've listed some, but I've problems with the very design and goals of

 In the interest of constructiveness, I could imagine a desktop-profiles
 rework which would work at package installation time only to generate a
 static list of KDEDIRS to append and prepend to $KDEDIRS on startkde
 time.  Ideally, desktop-profiles would also cover merging of
 configuration keys from multiple databases into a single one.  Finally,
 I could imagine desktop-profiles remapping well known config keys from
 some databases to translate them into another language (setting the
 wallpaper in a GConf database would affect Xfce).

 For the very long term, I think C bindings offered to the various
 desktops make more sense, and I think this is what DConf is about:

 I think both of these are irrealistic for the short term though.

> >  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). 

 It's nice to read that it only affects ssh -X logins; I suppose your
 shell snippet is still spawned, but exits immediately though.

 I agree it's nice that it works for ssh -X logins as well, but if you
 look at the third solution I proposed for KDE, it achieves the same
 result ... without one config file per possible shell...

>    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

 That's nice, but the settings exposed by desktop-base are not useful
 over ssh -X (splash, desktop background, greeter theme).  This is again
 too generic for the needs of desktop-base.

> > >  	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.

 Yeah, I would go as far as saying it's a bad idea to mess with the
 env vars in the first place, but since this is trivial to implement and
 the only public interface to extend KConfig...

Loïc Minier <lool@dooz.org>

Reply to: