KDE-Forum.org

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

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

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

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? ;-)

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?

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.

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

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.

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

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