KDEPIM 4.6 prob^Wimpressions

[Kevin Krammer]

On Thursday, 2011-06-30, Duncan wrote:
> Kevin Krammer posted on Thu, 30 Jun 2011 09:00:45 +0200 as excerpted:

> > It is just weird that this would be introduced now since the move to
> > Akonadi is also about decoupling applications from some of their low
> > level functionality, so e.g. KOrganizer can send mail without having to
> > go through KMail or vice versa (KMail creating a calendar entry from a
> > received invitation without having to go through KOrganizer).
> 
> Indeed.  But adding that ability means the code to create that calendar
> entry must be in kmail too, or "borrowed" from korganizer in the form of
> a dependency, which is how I'm interpreting this, assuming it's not the
> double-specified bug above or simply a mistake of some sort.

The invitation comes as an ical attachment and ical handling is part of the 
KDE PIM libraries. So there should be no dependeny on application code for 
handling invitations correctly.

> That's actually a question I had, but hadn't asked (or tried) yet,
> whether email searches, etc, now require nepomuk.  I'll probably enable
> it for that at some point, but the basic functionality that I use
> normally, doesn't require it, and there's still a bit of weirdness going
> on (every time a mail comes in, I get a warning about two copies... I
> suspect I have two different resources pointed at the same place or
> something but haven't had a chance to investigate yet... but don't spend
> too much time on that unless you happen to have a simple solution or bug
> you can point me to, as I'll create a separate thread for it when I'm
> ready, given that it's really a separate topic and this thread's
> convoluted enough already), so I'm not worried about /extra/
> functionality yet, just trying to keep it reasonably simple to deal with
> until I'm sure the basics are working correctly.

I don't have a bug number at hand but I think this is a know one.
Something triggering the change collision detection when there is none.

> > Ah, so you were referring to the mail importer (executable kmailcvt),
> > not the migrator (executable kmail-migrator).
> 
> Yes.  By that point the migrator had finished, failing to detect the
> local mail store at all, according to the migrator log which has no
> mention of it, no errors, nothing.  So I was doing the manual import
> thing.
> 
> But I had assumed that the migrator was simply an automatic trigger for
> what would otherwise be a manual import/conversion process, thus more or
> less conflating them in my discussion, I suppose.  It appears that I
> assumed wrong, and they're two entirely separate things.

Yeah, the best thing at that point would have been to simply create a KMail 
Folders resource and point it to the KMail mail directory.
The kmailcvt tools is a very old one and should probably be replaced at some 
point.
I had a GSoC student on that topic last year but we didn't reach a state where 
we could think about replacing kmailcvt. Unfortunately no development on that 
since last year. A lot of ideas but way to much other things to do.

> What I found interesting was that it wasn't /all/ messages unread or all
> read, it was /mostly/ unread.  If there wasn't support for the index
> files at all, they should all be unread (or all read, arbitrary choice of
> the importer).

Maildir messages also carry their read/unread status as part of their 
filename, so maybe the importer interpreted that for some of them.
It could also be a bug in the interaction between the importer and Akonadi, or 
the importer and KMail (no idea if it has been ported to work with Akonadi or 
still works through KMail).


Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20110701/1f2722c7/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.