Re: Re: konqueror/desktop user settings
>There is no smart way :)
>We are working on similar stuff here with our Thin Client server stuff here,
>but the problem is that their are lots of settings in .kde which have the
>complete paths embedded..
>IE when you set up, you can set a user to have defautl email addresses and
>the like.. One day this should be a project
>Currently we have a bunch of scripts which update all the users home
>directories.. and the configuration files inside of .kde, and a bunch of
>sedding needs to be done..
>You can do this with a default template, but once you customize, trying to do
>a cp -a and chmod aren't going to work anymore..
>We should have some kind of way to register individuals user settings
>Each app that stores information in .kde should use path variables at least..
>We still aren't really sure of a better way to deal with this, but globally
>updating users is a pain the way things stand now.. Maybe the template
>concept needs to be escalated, so that you can have certain settings in .kde
>that can't be overridden... If all users say had country/language set by the
>template user, then only the template user should have to be changed.
>This way you could also lock down things like background settings, clock
>settings etc.. and save a lot of administration headaches..
>Like when users loose their file associations, or when you want to lock down
>java settings, et al. Currently no real way to restore a persons settings
>unless you take .kde from backup, or reset them up from scratch.
>We're trying to use the template user approach here, and create the .kde
>directories as much as possible to the template user's settings, which they
>don't have permission to change. Then you can log into template, and update
>everyone's background at the same time, or change everyone's proxy settings
>in konqueror etc..
I apologise for replying with so much delay, but I didn't subscribe debian-kde
ML so I coulnd' read your answer.
I'm not sure I've understood your point.
Do you mean that copying .kde to /etc/skel is no worth ?
(...a lot of "fine-tuning" must be done)
Thanks for your time.