[kdepim-users] New computer

[ianseeks]

On Sunday 15 August 2010 12:10:31 Ingo Klöcker wrote:
> 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.
I know, but thats not a reason for lack of improvement. 
> 
> > 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.
Sure, but KDE3 -> KDE4 would have been a good time to change it and a few of 
the other points i've suggested.
> 
> > 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.
Yes, but a link could be used until the application gets updated to use the 
correct place at which point the app can remove the link automatically.  
> 
> > 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. ;-)
Yep, but MSdos is where a lot of people cut their teeth on computers and 
learnt very bad habits through ignorance which have been passed down the 
chain.
> 
> > > 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. 
True but it would be a lot easier to understand/comprehend and so by 
implication, 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.)
If they don't follow it, they should not be allowed to known as a true KDE 
application and get stuck in the playground.,

> 
> 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.
That would be wonderful. A migration assistant should always be part of a new 
install. 
> 
> > > 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.
Question:  does each application that uses Akonadi have its own settings and 
data or do all apps share one database and settings database , a bit like the 
Registry on that other OS?
> 
> > > 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. 
I think it should be as it makes it easier to get new users (and more 
importantly keep them) if they know its simpler than the other OSes.

> 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 agree with regards to databases that there are added complications for 
backups which hopefully will be dealt with at some point e.g. a backup process 
in kontact that will work on exit or perhaps when a screensavers launches. 
> > 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.
I don't think the structure of the data and config directories should be 
complicated. 
I'll never be a power user (and nowhere near it) but i do like to have 
automated backups using rsync etc on logging out. I like making as small and 
simple a script as possible as I don't want to back up my whole home dir just 
the data i would not be able to replace.
> 
> Regards,
> Ingo
_______________________________________________
KDE PIM users mailing list
kdepim-users at kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users