You are not logged in.

Dear visitor, welcome to KDE-Forum.org. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Monday, September 13th 2004, 6:50pm

How to "transport" a Desktop configuration?

Hi,

is there a way to non-interactively "transport" a configuration you did on one KDE desktop to another one?

Short story:

I went through the trouble to configure everything I need on one computer but now I need to merge the changes to use them on a different display.

Idieally, is there something like (made up command names)
`kdecontrolcenter-diff` which would give me a file with all the changes I made from the default and then
`kdecontrolcenter-merge` which would apply those changes.

Long story:
--------------

The major reason why I spent my time so far with fvwm2 and xterm is that I have a 12-year history of fine-tuned dotfiles and a script which adapts them to new accounts that I get. I need something to configure a KDE desktop from the commandline.

I basically see two ways to do that:

1) Support from KDE control center in emitting my changes in a form that can be applied non-interactively

2) Transport (probably by diff/patch) changes in ASCII config files.

I already spotted that defaults are not kept in one place, but that wouldn't be too bad. Most of the config work is in the Window manager, and some in Konsole. I can live with only automatically configuring those two.

Any idea appreciated
Martin

anda_skoa

Professional

Posts: 1,273

Location: Graz, Austria

Occupation: Software Developer

  • Send private message

2

Monday, September 13th 2004, 7:16pm

Assuming that you start with a new account on th other machine, you could more or less just copy the contents of $(HOME)/.kde to the new machine.

Or maybe using a tar archive like this
#> tar cvf kde.tar .kde/

other machine
#> tar xvf kde.tar

(the directory could have a different name if $KDEHOME is set)

Mabye additionally ~/.kderc

Cheers,
_
Qt/KDE Developer
Debian User

3

Monday, September 13th 2004, 7:23pm

That's not sportish :)

But seriously, what happens if there is a slight version difference?

And this way I cannot make different changes on both sides and get them merged together. That will be quite common with my notebooks on one hand and desktops on the other hand.

anda_skoa

Professional

Posts: 1,273

Location: Graz, Austria

Occupation: Software Developer

  • Send private message

4

Monday, September 13th 2004, 7:31pm

Quoted

Original von Martin Cracauer

That's not sportish :)

But seriously, what happens if there is a slight version difference?

Well, if the new machine has a newer version, it should be able to import the older files.
This is more or less the same situation as upgrading installed KDE

Quoted


And this way I cannot make different changes on both sides and get them merged together. That will be quite common with my notebooks on one hand and desktops on the other hand.

Right.
I heard from people with similar setups that they found unison http://www.cis.upenn.edu/~bcpierce/unison/ a nice tool for synchronising their alternatively used machines.

Cheers,
_
Qt/KDE Developer
Debian User

5

Monday, September 13th 2004, 8:12pm

Hm, manually inspecting the files in ~/.kde/share/config I find they hold the default values, not my changed values.

Mumble, reverse engineering stuff was exactly what I wanted to prevent...

6

Monday, September 13th 2004, 8:24pm

I wonder where the stuff is actually stored?

$ cd ~/.kde
$ ls -ltr `find . -type f`

==> newest file is from August 3rd.

anda_skoa

Professional

Posts: 1,273

Location: Graz, Austria

Occupation: Software Developer

  • Send private message

7

Tuesday, September 14th 2004, 8:10pm

Quoted

Original von Martin Cracauer

Hm, manually inspecting the files in ~/.kde/share/config I find they hold the default values, not my changed values.

Yes, this is/was a known deficiency. The new config framework ensures only value differing from the defaults are saved.

Quoted


I wonder where the stuff is actually stored?


It should be .kde/share/config
Which apps' configs did you change?
Do you have KDEHOME set?

Cheers,
_
Qt/KDE Developer
Debian User

8

Wednesday, September 15th 2004, 2:30am

Ah!

$KDEHOME

That was it. I forgot about that one. I have it set to a well-chosen place, not knowing it would keep my config there, and then forgot about it

OK, I'll give it a try to sort it out with ASCII patch/diff or cvs manually.

I only need to transport window manager config and Konsole.

9

Wednesday, September 15th 2004, 4:43am

Quoted

Original von Martin Cracauer

OK, I'll give it a try to sort it out with ASCII patch/diff or cvs manually.

I was about to suggest CVS. That's what I use to keep certain (not all) KDE config files in sync between my machines at work and at home, e.g. konqueror's bookmarks, the address book, the kopete contacts, ...

What's somewhat annoying in recent versions of konqueror: It stores usage stats for each bookmark (number of accesses, last access date, ...). So just browsing with konqi modifies the bookmark file. My solution is to strip out that additional info with a script just before I commit or update the file.

Still, this way of doing things (using diffs of text files) feels like a hack. I would like to be able to define for each setting (not only for each complete config file) that is changed by me whether it's for all my machines or just for the local one (not to be synced, but maybe still stored in a version control system, for backup and history purposes).

I may be wrong but AFAIK there's no concept in KDE yet for this problem. Am I wrong? ;-)

m4ktub

Intermediate

Posts: 257

Location: Lisbon, Portugal

Occupation: Software Engineer

  • Send private message

10

Wednesday, September 15th 2004, 2:37pm

All this talk made me imagine a future where the concept of user was more than just the guy who seats in front of the computer.

Where one could have different KDE boxes in sync. I login here and have a personalized desktop. Logoff. Go home and login there and have the same desktop. Like if I changed place and carried the computer with me.

Of course this is all a little futuristic right now but having to configure KDE the way we want in every time is a little frustrating. In my case a had a distro fight. I change from one distribution to other frequently in the last 2-3 years and although I copied my config I could never achive the same desktop. One distro has additional themes, the other has even different directories under .kde, etc. A constant struggle (well ... no one forced me to change so frequently :wink:).

So, what kind of infrasructure would be needed to have the concept of "one user, one KDE, multiple boxes"? What would be needed to have this work even on public computers?

What do you all think about this?

11

Wednesday, September 15th 2004, 8:24pm

Quoted

Original von m4ktub

All this talk made me imagine a future where the concept of user was more than just the guy who seats in front of the computer.

Where one could have different KDE boxes in sync. I login here and have a personalized desktop. Logoff. Go home and login there and have the same desktop. Like if I changed place and carried the computer with me.
There are some approaches to do that even today:

- Booting from a Knoppix CD, home directory on a USB stick you carry around. Problems: Flash memory can only bear a limited number of writes. Gigabyte size USB sticks are still expensive.

- Booting from a Knoppix CD, home directory "somewhere" on the net (where you only have an ssh account, for example). That "somewhere" must be accessible from anywhere you want to use a computer.

- Complete Linux installation on a USB hard disk you carry around, with automatic hardware detection on boot. Problem: BIOS must support booting from USB disk, or one needs a floppy disk or a CD to boot from.

Related stuff, but doesn't work outside the company's LAN, etc.:

- Home directory as exported filesystem on a server, booting locally from a Linux installation. Problem: Maintenance of the local software installations, but that can probably be solved.

- One big server with dumb XTerminals, or better two servers for fail-safety. Software is installed and runs on the server. Booting the XTerminals with an image from the server. IIUC this is what the Linux terminal server project is about: http://www.ltsp.org/ . I think there's also a way to have programs run locally on the XTerminals if they are not too low-end.

12

Wednesday, September 15th 2004, 8:33pm

Quoted

Original von cmbofh

- Complete Linux installation on a USB hard disk you carry around, with automatic hardware detection on boot.

There's a solution from Mandrake I read about a few weeks ago:
http://www.mandrakesoft.com/products/globetrotter

13

Thursday, September 16th 2004, 1:10pm

When I said "diff/patch", that actually means CVS. For 12 years now I carry a CVS checkout directory with a ./configure script with me which installs my dotfiles (and personal binaries/scripts) and adapts them as needed to the target machine.

What would better in the KDE case is not messing with the ASCII files directly, but instead have a commandline KDE control center. It would do both reporting changes made in an interactive control center as commandlines, and taking such commandlines and applying them.

Advantages would be:
- works ever after desktop is up (changes will be applied)
- configuration items not understood by the target desktop will be ignored and not written to config files, or they might be translated if the program has a database of updated config items
- no CVS conflict markers in config files :shock:

After all this, the next trouble I appear to face is that the machine I "develop" my configuration on has an orginal KDE from kde.org. The target machine is a Fedora Core 2 machines and guessing from my first looks which suddenly required double-clicks where the native one required one click I guess that I have to develop an "defedoraizer" first.

m4ktub

Intermediate

Posts: 257

Location: Lisbon, Portugal

Occupation: Software Engineer

  • Send private message

14

Thursday, September 16th 2004, 3:52pm

CDs and USB storage devices are not my computer. If I go from a place to another and bring the USB disk with me then I could bring my laptop to achive the same result. The difference is that the USB disk is smaller and more pratical to carry.

For example if KDE had a server dedicated to the users. Some kind of hidden CVS to accomodate Martin Cracauer idea. One could login and KDE would update the configuration from that server. It had to be a light operation because it has to complete before you can see your desktop.

I can see a big problem here. Part of the user experience and configuration is given by the amount of toys we have installed. So or this would be a limitation or some solution would ave to be found (and it wouldn't be simple for sure). But even more natural things would be a pain. If I changed my desktop background the image used in the bacground would need to be acessible everywhere. Even if it was automatically transfered this would mean a great wait time.

In fact I think that the "big server with dumb XTerminals" best suits current needs and limitations. I didn't thought of that common solution when I first posted.

I've heard a new remote desktop technology that anounce to be ultra bandwidth light. It was different from VNC and used their one compression algorithms. If kdm had an option to login remotly then the goal would be achieved. In public computers some standalone client tool could be used (like vnc as currently). Of course network bandwith would be the main limitator. It would be difficult to play Quakes and UTs in that conditions over a 56K modem for example.

anda_skoa

Professional

Posts: 1,273

Location: Graz, Austria

Occupation: Software Developer

  • Send private message

15

Thursday, September 16th 2004, 8:49pm

Aside from application data files like bookmarks or images, it would be possible to manage config data differently.

KConfig allows to have other backends than the INI style files, AFAIK someone once implement a XML based backend as proof-of-concept.

It would be possible to implement a LDAP based or CVS based backend.

Cheers,
_
Qt/KDE Developer
Debian User

m4ktub

Intermediate

Posts: 257

Location: Lisbon, Portugal

Occupation: Software Engineer

  • Send private message

16

Monday, September 20th 2004, 12:20pm

Oh! Great! so I think that it's a mater of time and not technological support.

You would have some problems like wallpapers and other stuff that is managed by user and not KConfig but it already allows to automate things in a powerfull transparent way.

KDE really rocks! :-D