From kde-pim Thu May 06 20:12:07 2010 From: Ingo =?iso-8859-15?q?Kl=F6cker?= Date: Thu, 06 May 2010 20:12:07 +0000 To: kde-pim Subject: Re: [Kde-pim] KDE Addressbook on an Appliance Message-Id: <201005062212.08696 () thufir ! ingo-kloecker ! de> X-MARC-Message: https://marc.info/?l=kde-pim&m=127317679129105 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0925452242==" --===============0925452242== Content-type: multipart/signed; boundary=nextPart8014988.P9jBH1TOt1; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit --nextPart8014988.P9jBH1TOt1 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable On Thursday 06 May 2010, Anne Wilson wrote: > On Wednesday 05 May 2010 20:30:07 Ingo Kl=F6cker wrote: > > I think the problem we are having is that you are stating a problem > > without first stating the situation or the use case. You seem to be > > talking about a user who does already have an address book in > > electronic form. Otherwise there wouldn't be an alternative to > > entering each record by hand. >=20 > True. There are two cases, then. One where no addressbook exists - > but then users would expect to simply add addresses as they needed > to, so I didn't consider this as a problem. >=20 > The other case, the one I addressed, is that the user has had an > addressbook, either in a previous install or on another computer, > and wants to use that existing addressbook. >=20 > > But if one does already have data then the first thing I would look > > for is a way to import this data. And indeed there is an entry > > Import in the File menu. Of course, I'm not Joe User so I'm not > > the kind of person we are talking about. >=20 > That was the first thing I looked at. What I saw was >=20 > Import vCard > Import CSV file > Import LDIF file > Import from LDAP server > Import GMX file. >=20 > None of these seemed to me to fit the bill. The only possible one > was the first one - but logic said that that would import a single > address card - and what I had was a file with 100 or so addresses. Yeah, I also noticed this. I would have tried it anyway. :-) Of course, it would be even better if KAddressBook tried to figure out=20 the format of the file automatically instead of asking the user to make=20 a choice between four different file formats. For many users this will=20 be as understandable as Chinese. > > > If you do it the way I did, you have two addressbooks, and then > > > have to go through the process of marking one of them as > > > default. Anyone who tries to remove the std.vcf after simply > > > copying across the entries is likely to find that he can't, > > > because it could well be being seen as the default. Of course > > > it's all editable, but it's a hassle that should be avoided. > >=20 > > The problem here is that your way of doing it is extremely > > complicated. It's not the recommended way of getting your old data > > into KAddressBook. The recommended way is to use the import > > functionality provided by the application. >=20 > See above. >=20 > > > IMO what would really help is if the first run could register > > > whether it found any records to migrate. If it didn't, it > > > should re-run at the next boot - and each time until it actually > > > finds records. That would allow for users to panic and close > > > the addressbook because it's empty, realise that the old one has > > > to be made available, fix that, and still have an automatic > > > migration. > >=20 > > Maybe. OTOH, for automatic migration to work the user will have to > > copy the old address book to a specific location. That's > > error-prone and IMO too complicated. Instead, if auto-migration > > didn't find an old address book, then the first-run assistant > > should offer importing an old address book (giving the user a hint > > where he has to look for the old address book). >=20 > Copying a single file to a directory known to have been its address > in earlier releases is a natural enough thing to do, for anyone that > has used file managers. Yes, the first-run pausing and allowing you > to point to a location would help a lot. Particularly if it happily > waits for a usb drive to be added. >=20 > > > Of course it's easy to tell others what to do :-) I would have > > > thought that just setting a flag might accomplish this, but if > > > it's not so easy, I apologise. I'm simply reflecting the > > > problems that some users have reported. > >=20 > > Understood. What do you think about the proposal outlined by me? >=20 > I'm not happy about the Import situation - either the descriptions > are not good, or there isn't one for the job in hand. I'm pretty sure it's just the descriptions that are not good. > OTOH, your > suggestion of pausing the first-run assistant to allow for a > location to be defined sounds a good one to me - although I'm not > sure that it could hint at the location, as it would have found the > addressbook automatically if it was in the expected place. Well, I meant it could hint at the (most likely) location on the old=20 computer. If the old address book is already on the new system then you=20 are right. In this case it should migrate the address book=20 automatically. Regards, Ingo --nextPart8014988.P9jBH1TOt1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEABECAAYFAkvjIpgACgkQGnR+RTDgudjzzwCfQ7+9zOPynKS7vA3+j493T0mj I9cAn0UJqax3XUAZwBTfL2imCaPs1nt8 =YJX1 -----END PGP SIGNATURE----- --nextPart8014988.P9jBH1TOt1-- --===============0925452242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KDE PIM mailing list kde-pim@kde.org https://mail.kde.org/mailman/listinfo/kde-pim KDE PIM home page at http://pim.kde.org/ --===============0925452242==--