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
KDEDIRS='';XDG_CONFIG_DIRS='';XDG_DATA_DIRS='';CHOICESPATH='';GNUSTEP_PATHLIST='';UDEDIRS=''
=> 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:
PROFILES=`tempfile`
=> 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:
[Desktop0]
BackgroundMode=VerticalGradient
BlendBalance=100
BlendMode=NoBlending
ChangeInterval=60
Color1=30,114,160
Color2=192,192,192
CurrentWallpaper=0
LastChange=0
MinOptimizationDepth=1
MultiWallpaperMode=NoMulti
Pattern=
Program=
ReverseBlending=false
UseSHM=false
Wallpaper=/usr/share/images/desktop-base/desktop-background
WallpaperList=
WallpaperMode=Scaled
for KDE and:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mcs-option SYSTEM "mcs-option.dtd">
<mcs-option>
<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"/>
</mcs-option>
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
artwork.
> 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
desktop-profiles.
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:
<http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs>
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: