[Kde-mobile-users] Setup problems for Kontact touch

[Bernhard Reiter]

Hi Eike,

Am Sunday, 11. December 2011 21:13:34 schrieb Rolf Eike Beer:
> I tried to get my KoMo setup working again on my N900, which looks
> basically impossible. Here is a sum up of things that stopped me, hoping
> that someone can have a look at.

which version did you try in particular?

Just a few quick hints:

> I have two IMAP accounts, one of them has mails and contacts, the other one
> contacts and calendar data. So I used KMail Mobile to set up the first one.
> That was the rather easy part.
>
> The folder holding the contacts is shown as a mail folder, which is normal
> when not specially set (I know this from the desktop version). 

On a server were annotations are supported (e.g. Kolab Server's cyrus IMAPD)
the type of the folder should be detected automatically. So I assume you are
using a regular IMAP server.

> When will Kontact ask if a folder called "Contacts" has contacts in them? 
> Shouldn't be too hard to guess from the contents. And accept this settings 
for all subfolders?

You are correct that it could be guessable, if all object types in a folder 
are specific. However I do not think this feature has been implemented. So it 
probably needs to be set manually. 

> Ok, I thought about going to the folder properties like in the desktop
> version. Sadly the controls in this screen are very small, the font is
> about 2 pixels height. As you can surely guess this makes it impossible to
> do something useful with it. I also did not see a combobox there to change
> things to be contacts, so I guess it is not there. How am I supposed to get
> this setup working then?

Maybe you need the akonadiconsole for this. I don't know.

> Then the calendar application seems to be gone from recent versions of KoMo
> on the N900, at least regarding it's desktop shortcut. The other things
> like Notes and Mail can have a shortcut on one home screen, the calendar
> one disappeared.

Huh, should be there.

> Then I created the other account in Calendar. Now it uses a default name,
> but I found no way to change that name from within the Calendar
> application.

On the top level, editing the account should let you change the name of the 
account. You may need to restart it for the change to propergate in some 
situations.

> I had to switch to KMail to be able to do it. Now both the 
> contact and calendar application say that they are able to store their
> stuff in my first mail account. Sadly they don't find everything there. Let
> me sum up what I now have:
>
> KMail shows both IMAP accounts, even if one of them has no mails (but
> that's ok so far, that I also have on the desktop). It shows the Contacts
> folder in the first account, listing all it's subfolders and showing the
> contents.
>
> Calendar shows the first email account, even if there is no "Calendar"
> subfolder in it. It doesn't show the second account at all.

Usually any groupware aware IMAP account must have all default type folders.
Otherwise the client must create them. How this work in the current 
implementation in the manual imap server case is beyond my knowledge. 

> Contacts shows the first email account and the contacts in the "Contacts"
> folder. It does not show any subfolders even if they are visible in KMail,
> nor any contacts in those subfolders. It does not show the second email
> account at all.
>
> I have a strong idea why the second account does not show up: it was
> created with an early version of KMail2 and has the contact and calendar
> folders created with their German names. This is no problems for the
> desktop version where I can change what KMail/Calendar/akonadi thinks what
> is in this folders.

In the Kolab Concept the imap folder name is irrelevant, the client only 
detects types via the imap annotation or by an explicit setting.

> But I found no way to change that in the mobile 
> version. And neither in the desktop nor mobile version Kontact get's it
> that if there is a folder "Contacts" that has contacts all of it's
> subfolders contain contacts, too. A confirmation dialog is ok, but the
> default assumption should be that whatever a folder contains this will also
> be in all subfolders.

I don't think the assumption holds in the general case that any subfolder 
of "Contacts" should only hold contacts. It is okay to fix folder types in 
hierarchies so far.

> If you edit a contact the layout is also very bad. The edit boxes are
> small, the second column of buttons is very wide, probably because
> "Bevorzugte Telefonnummer" in the German localisation is rather long. And
> the last column of buttons is cut off and not completely visible.

There have been attempts to port the Kontact Touch to newer versions of KDE 
Plattform and Qt, because of different defects, some of the layout were 
affected in these porting attempts. Therefore this might depend on the 
particular version you have been trying.

> I found no way to select one or multiple contacts and delete them. From
> what I got used to in KMail Mobile I expected to tap on the folder when
> it's open, select the contact(s) and have an entry "delete" in the context
> menu.

This works with my version of Kontact Touch. ;)

> What I also miss is an easy way to show the contact information as barcode
> on the display so I can allow other people to import that stuff from my
> phone without using any bluetooth/network connection at all.

Nice idea. ;) I'd usually prefer a network connection, especially for 
transfering more than one contact, but why not using barcodes...

Bernhard

-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- 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/kde-mobile-users/attachments/20111214/1a69e640/attachment.sig>