[kdepim-users] New computer

Sun Aug 15 12:10:31 BST 2010

On Sunday 15 August 2010, ianseeks wrote:
> On Saturday 14 August 2010 22:07:20 Ingo Klöcker wrote:
> > On Friday 13 August 2010, ianseeks wrote:
> > > On Friday 13 August 2010 19:52:49 Ingo Klöcker wrote:
> > > > On Friday 13 August 2010, ianseeks wrote:
> > > > > On Friday 13 August 2010 09:44:01 O. Sinclair wrote:
> > > > > > Got a new laptop and am busy installing it. So far so good.
> > > > > > Next step is to move data from old to new.
> > > > > > 
> > > > > > This time I am not going for the easiest solution, to copy
> > > > > > everything under /home/myname, but I want an as clean as
> > > > > > possible solution. BUT want my mail, my mail accounts, my
> > > > > > contacts, notes and information such as replied-to, filters
> > > > > > etc copied over.
> > > > > > 
> > > > > > I am aware of this info:
> > > > > > http://userbase.kde.org/KMail/FAQs_Hints_and_Tips#Transfer_
> > > > > > mail _and _setting
> > > > > > s_to_another_computer_.28or_another_user_account_on_the_sam
> > > > > > e_ma chi ne.29
> > > > > > 
> > > > > > but is it still up to date after KAdressbook started using
> > > > > > Akonadi?
> > > > > > 
> > > > > > I also found this in an old email:
> > > > > > Substitute the appropriate path below.
> > > > > > 
> > > > > > You need the following config files:
> > > > > > 
> > > > > > .kde4/share/config/emaildefaults
> > > > > > .kde4/share/config/emailidentities
> > > > > > .kde4/share/config/kmail.eventsrc
> > > > > > .kde4/share/config/kmailrc
> > > > > > .kde4/share/config/kaddressbookrc
> > > > > > .kde4/share/config/kresources/contact
> > > > > > .kde4/share/config/korgacrc
> > > > > > .kde4/share/config/korganizerrc
> > > > > > .kde4/share/config/knotesrc
> > > > > > 
> > > > > > and the following directories:
> > > > > > 
> > > > > > .kde4/share/apps/kmail
> > > > > > .kde4/share/apps/kabc
> > > > > > .kde4/share/apps/korganizer
> > > > > > .kde4/share/apps/knotes
> > > > > > 
> > > > > > If you use Akregator within Kontact, you will also need:
> > > > > > 
> > > > > > .kde4/share/config/akregator.eventsrc
> > > > > > .kde4/share/config/akregatorrc
> > > > > > .kde4/share/config/kopete.eventsrc
> > > > > > 
> > > > > > and the whole .kde4/share/apps/akregator directory.
> > > > > > 
> > > > > > is that a more "complete" list and has something changed
> > > > > > since migration to Akonadi (this was pre-Akonadi Contacts)
> > > > > 
> > > > > Wouldn't it be nice to have a ".kontact" folder that included
> > > > > links to all the kontact data scattered all over your home
> > > > > directory then you could just type one "cp" command.
> > > > 
> > > > Nice idea. But this would only allow you to backup the data
> > > > easily. On the new system you still would have to put all
> > > > files into the correct locations.
> > > 
> > > Yes, i think this is a big problem that goes wider than kontact.
> > > There seems to be no standard that all the apps should follow
> > > where data and config files reside.  They all seem to make it up
> > > as they go along.
> > 
> > No. They don't.
> > 
> > For KDE applications this is pretty much standardized:
> > - settings are stored in ~/.kde/share/config
> > - data is stored in ~/.kde/share/apps/<appname>
> 
> Except kmail is ~/Mail in my home directory

Many years ago KMail was using ~/Mail. For new KMail setups this has 
already been changed long ago to ~/.kde/share/apps/kmail/mail.

> and the home directory is littered with "." files.

Historical reasons. In the stone age of Unix user specific configuration 
was stored directly in '.' files in the home directory.

> Its all a matter of making things
> self-explanatory e.g. why is the data directory
> "~/.kde/share/apps/<appname>" not called "~/.kde/data/<appname>"

Historical reasons.

> All "." files should be under a directory called ".config" (or
> similar)

And that's exactly what newer applications do. Old applications cannot 
simply move their '.' files from the home directory to .config because 
this would break many installations relying on the current location.

> Home directories should not be littered with files, it
> looks like the very old MSDOS days where people should file in the
> route directory until it filled up.

Well, Unix predates MS DOS. ;-)

> > It gets a bit more complicated because of background components
> > used by many KDE applications, e.g. kabc (the old KDE service for
> > accessing address books) or Nepomuk.
> 
> Yes, thats why its got to be rationalised to make it more user
> friendly and self explanatory.  Its probably a task for for a
> Usability team to create a simple template structure that all KDE
> programs should follow and not get into the main stream until the
> adhere to the standard.

I disagree. Regardless how we structure the directory layout it will 
never be user friendly. Why? Because messing around with files and 
folders is no user friendly. Consequently, there's no way on earth to 
make it user friendly by creating "a simple template structure that all 
KDE programs should follow". (BTW, it wouldn't help a bit if just KDE 
applications follow it.)

A user friendly solution is a simple migration assistant which takes 
care of all the details. The user should not have to care for the 
details.

> > And then there is Akonadi which is not a KDE background component.
> > Therefore Akonadi uses the standard locations for non-KDE
> > components, i.e.
> > ~/.config/akonadi - for settings
> > ~/.local/share/akonadi - for data
> 
> I understand that Akonadi is not a KDE component but as it is being
> integrated into main KDE programs and is now by association, an
> absolute KDE app dependency as certain apps will not run without it.
> In my opinion, it should follow the KDE config and data structures.

I'm sorry, but that's not how it works. Akonadi aims at being used not 
only by KDE but also by Gnome, OpenOffice, Thunderbird, Firefox, etc. I 
guess this makes clear why putting Akonadi's settings and data below 
~/.kde makes absolutely no sense.

> > So, the problem is not that we use random locations for settings
> > and data (they are not random). The problem is that you need to
> > know which background components are relevant for Kontact.
> 
> Thats more or less my point.  They may not be random to a developer
> but as a user i shouldn't need to know this sort of developers
> detail.

Exactly my point.

> I should just be able to "cp/rsync" a single directory for
> the whole of kontact or if i want just to back up kmail then its
> "cp/rsync" "kontact_dir/kmail" - i shouldnt care if the data is
> stored in old or new formats

This is where you are wrong. It does not have to be easy for people like 
you who mess around with files and folders via cp or rsync or some 
graphical file manager. Akonadi uses a database. You cannot simply cp or 
rsync the database's files without shutting down Akonadi before doing 
so. This means if you want to mess around directly with the files and 
folders then you need to know exactly what you are doing. It is so 
error-prone that anybody except for experts should be discouraged from 
doing so.

> I hope you see this as constructive criticism and not an attack on
> KDE. Obviously a comprehensive backup app would help.

I do, but I don't think your ideas go into the right direction. The 
internal setup of modern applications is much too complicated for normal 
users to deal with. That's a fact. There's nothing one can do about 
this. Therefore the internal setup should be hidden from normal users as 
far as possible and they should never have to deal with it.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20100815/4aca68b7/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
kdepim-users at kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users