[kde] KDE filter on 'is in category' doesn't perform filtering
This may be a minor matter, and since I have googled and failed to find any reports of the same problem it may be that I have missed something obvious, perhaps in my configuration of Kontact. Suppose I set the Category field for several of my contacts to XYZZY. I then wish to filter mail from these contacts to a subfolder Inbox/xyzzy, so I create a filter with criterion From is in category XYZZY and action Move into folder Inbox/xyzzy, and save it. Applying filters manually with ^J does nothing, the mail from XYZZY contacts stays firmly in the Inbox. Similarly, incoming mail from my XYZZY contacts goes unfiltered into the Inbox. This filtering trick worked fine with pre-akonadi versions of kmail and was one of the features that made kmail so attractive to me. Filters based on email headers are working fine. I have a secondary filtering problem which I have worked around but which remains an irritation. For years I used fetchmail and exim to retrieve email from a variety of sources and direct it into one destination, either an mbox or a Maildir according to the whim of the moment. With the arrival of akonadi the filters just seemed to stop working altogether in incoming mail, although they worked fine when applied manually. This was a major obstacle to my using Kmail and I went elsewhere. Recently I was prompted to try abandoning my homebrew mail processing and get kmail to fetch from all the different remote POP servers, and hey! all the filters (except those noted above) work fine. But I don't want to do it this way, so can anybody tell me if its possible to run automatic filtering on fetchmail/exim inputs? Rosalind ___ 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.
[kde] KDE filter on 'is in category' doesn't perform filtering
This may be a minor matter, and since I have googled and failed to find any reports of the same problem it may be that I have missed something obvious, perhaps in my configuration of Kontact. Suppose I set the Category field for several of my contacts to XYZZY. I then wish to filter mail from these contacts to a subfolder Inbox/xyzzy, so I create a filter with criterion From is in category XYZZY and action Move into folder Inbox/xyzzy, and save it. Applying filters manually with ^J does nothing, the mail from XYZZY contacts stays firmly in the Inbox. Similarly, incoming mail from my XYZZY contacts goes unfiltered into the Inbox. This filtering trick worked fine with pre-akonadi versions of kmail and was one of the features that made kmail so attractive to me. Filters based on email headers are working fine. I have a secondary filtering problem which I have worked around but which remains an irritation. For years I used fetchmail and exim to retrieve email from a variety of sources and direct it into one destination, either an mbox or a Maildir according to the whim of the moment. With the arrival of akonadi the filters just seemed to stop working altogether in incoming mail, although they worked fine when applied manually. This was a major obstacle to my using Kmail and I went elsewhere. Recently I was prompted to try abandoning my homebrew mail processing and get kmail to fetch from all the different remote POP servers, and hey! all the filters (except those noted above) work fine. But I don't want to do it this way, so can anybody tell me if its possible to run automatic filtering on fetchmail/exim inputs? Rosalind ___ 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.
Re: [kde] Akonadi acting up (again)
- Original Message - > From: Kevin Krammer > To: kde@mail.kde.org > Cc: > Sent: Monday, 23 September 2013, 18:26 > Subject: Re: [kde] Akonadi acting up (again) > > On Monday, 2013-09-23, John Woodhouse wrote: > >> :-) I'll refrain from commenting on OOPsers ideas on modularity and > code re >> :use and have never looked to see how it's organised so shouldn't. > On the >> :other hand why such a difference between Kmail 3 and 4. > > Not sure what OOP refers to here but I assume it doesn't mean Object > Oriented > Programming. > Afraid it does - when things look to have gone wrong I hope it catches on. Me well I'm an OOD man. In this case I feel that maybe oops has the right connotations. > Akonadi, like Evolution Data Server (short EDS) before [1], is a service > oriented approach to PIM data access. > In some ways that comment isn't relevant. Users are more interested in over all functionality not the implementation. Oh so easy to forget. > > I am also not sure which two versions of KMail the second sentence is > referring to. Is that KMail based on Qt3 and one of the two versions of KMail > based on Qt4 or KMail1 and KMail2? Help Kmail about for the one I am using from kdepim3 shows Kmail 1.9.10 using KDE3.5.10 "release 67" The KDE I am running shows KDE Platform Version 4.10.5 "release 1" I assume the releases in bunny rabbits relate to OpenSuse. I'm fairly sure other QT4ified Kmail's from KDE3 may be available elsewhere as well. > > Cheers, > Kevin > Must admit I may have a jaundiced view of Akonadi. This goes back to when it was introduced. Appeared to slowly scan my disks to index them. I shut it off after a several days. Fed up with disks tinkling and concerned about wear. It should have quickly got out of the way if I needed to use the disk and didn't. Very noticeable pregnant pauses instead. I keep reading odd comments about it as well -rewrites and should be faster, Needs to index more types of files. Slow. Bloatware. Kmail can't handle the volume of mail I get etc. Jaundiced view? Maybe not. I used windows at work and remember when they introduced file indexing. Optional with a warning that it might have some impact on performance. It took maybe a couple of mins to generate the index and there after was un noticeable. I assume the index was updated on file writes. A user would expect a bit of a delay then and marginal increases wouldn't be noticed. Software work so many many files on the machine. :-) Too many years worth really. KDE4 though. Brilliant. I've generally had good experiences with it. Okular has always been slow. On my previous machine I have to wonder about machine loading re a pop something like - very busy down here - turning effects off. Detecting that must increase the machine load. Actually it was very busy up here. Surely effects complete naturally and I would notice the slowness - if it mattered. Leaves me wondering what else lies buried underneath it all. Best John > > [1] EDS actually only offers contacts and calendar via its service but they > are working on adding email as a service: > http://www.superlectures.com/guadec2013/evolution-as-email-service-for-the- > gnome-desktop > > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring > ___ > 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. > ___ 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.
Re: [kde] Akonadi acting up (again)
On Tuesday, 2013-09-24, John Woodhouse wrote: > - Original Message - > > > From: Kevin Krammer > > To: kde@mail.kde.org > > Cc: > > Sent: Monday, 23 September 2013, 18:26 > > Subject: Re: [kde] Akonadi acting up (again) > > > > On Monday, 2013-09-23, John Woodhouse wrote: > >> :-) I'll refrain from commenting on OOPsers ideas on modularity and > > > > code re > > > >> :use and have never looked to see how it's organised so shouldn't. > > > > On the > > > >> :other hand why such a difference between Kmail 3 and 4. > > > > Not sure what OOP refers to here but I assume it doesn't mean Object > > Oriented > > Programming. > > Afraid it does - when things look to have gone wrong I hope it catches on. I actually assumed it meant that, but since it didn't make any sense in the context it appeared in I found it better to ask. The server/client based architecture made reusable components more viable but that is the case independent of the client side programming technique/paradigm being used. For example previously it wouldn't have been worthwhile to invest into separating the email viewer into a component since email backend access is a rather tricky business. By not needing to do that anymore in each client it became a viable goal to create a library for email viewing functionality. As a positive side effect it becomes more viable to consider alternative viewers, since the separation reduces implicit coupling. > > Akonadi, like Evolution Data Server (short EDS) before [1], is a service > > oriented approach to PIM data access. > > In some ways that comment isn't relevant. I was just clarfying that the change wasn't about programming paradigm but architectural. And that similar projects are arriving at very similar architectures due to similar requirments. It's just to show that given the same requirements and constraints, arriving at very similar solutions isn't mere conincidence. > > I am also not sure which two versions of KMail the second sentence is > > referring to. Is that KMail based on Qt3 and one of the two versions of > > KMail based on Qt4 or KMail1 and KMail2? > > Help Kmail about for the one I am using from kdepim3 shows Kmail 1.9.10 > using KDE3.5.10 "release 67" > > The KDE I am running shows KDE Platform Version 4.10.5 "release 1" > > I assume the releases in bunny rabbits relate to OpenSuse. I'm fairly sure > other QT4ified Kmail's from KDE3 may be available elsewhere as well. I was asking because there have been changes between the Qt3 based version of KMail and the Qt4 based one, as well as changes between version 1 of the application and version 2. The differences between the first two is mostly a result of changes in the underlying libraries. Some of those were more involving than other, so the two code bases are not identical. But considering the size and age of the code base changes there can be considered rather limited. There were more significant changes between versions 1 and 2 of the application, due to the architectural nature of the changes below. For example synchronous and asynchronous data access require very different handling. Sometimes it is viable to hide the difference in some way, sometimes it isn't and it becomes more viable to specifially address the difference, leading to a more significant change. > Must admit I may have a jaundiced view of Akonadi. This goes back to when > it was introduced. Appeared to slowly scan my disks to index them. I shut > it off after a several days. Fed up with disks tinkling and concerned > about wear. It should have quickly got out of the way if I needed to use > the disk and didn't. Very noticeable pregnant pauses instead. I think you are referring to a different service there: Nepomuk. Quite some improvements have been made to its operational behavior over the last couple of releases. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message 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.
Re: [kde] Kickoff launcher doesn't save settings
On 24/09/2013 00:47, Duncan wrote: > One thing missing from your post, the version of kde/plasma you're > using. Never-the-less, I just duplicated your results here, post > kde-4.11.1 4.11-branch live-git build, tho I've not updated in a week > or two. Meanwhile, while I do have kickoff on a panel, I don't tend to > actually use it that much as I have my own hotkey-triggered launcher > menu script configured for apps I use frequently enough to bother. And > for stuff not on my hotkey-launcher, if I know the name I'll often > simply type it into krunner. So pretty much the only time I actually > use kickoff is when I'm browsing the menu for stuff I so seldom use I > neither have it on my hotkey launcher nor remember the name in ordered > to type it into krunner, which is very likely under 1% of my launches, > perhaps a couple times a month, if that. At that usage level, I don't > care much what the settings are as long as it's somewhat usable, which > it is. =:^) Apologies, I'm on 4.11.1 (Chakra). Thanks for your comments and for going to the effort of duplicating; I may well open a bug report, although of course now that I've posted about it, it's stopped doing it... Huw ___ 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.
[kde] KMail/PIM two ideas
Hi, This morning in my sleep deprived state I finally decided to grumble a bit =) + Wouldn't it be neat if I set folder properties on a folder in the KMail part of the suite and all sub-folder inherit the same property, or not according to property management? Today, this works as in Outlook (we have at work) and it's can be a major pita to set the same property on all frelling sub-folders. Please point me to how this is done if it indeed can be done today. + Also, KMail: Right-click on a message and I find two menu options for adding to Todo or Note. But why the ... not to Calendar? Just a morning thought. /M. ___ 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.
Re: [kde] Kickoff launcher doesn't save settings
huw posted on Tue, 24 Sep 2013 20:55:48 +0100 as excerpted: > On 24/09/2013 00:47, Duncan wrote: >> One thing missing from your post, the version of kde/plasma you're >> using. Never-the-less, I just duplicated your results here, post >> kde-4.11.1 4.11-branch live-git build, tho I've not updated in a week >> or two. > Apologies, I'm on 4.11.1 (Chakra). Thanks for your comments and for > going to the effort of duplicating; I may well open a bug report, > although of course now that I've posted about it, it's stopped doing > it... LOL. But while I like hover-change here and thus wouldn't change that setting except to duplicate your issue, while I was in kickoff settings I did notice one option I DID want to change, show apps by name (instead of by function, the default). While as I said I don't normally use kickoff enough to have previously worried about it, now that I know the option is there and in fact TRIED to change it, I'm getting frustrated by your bug as well, since THAT setting is taking immediate effect but not sticking around after a plasma restart. And while it wasn't bothering me before, now that you made me aware of the problem, IT'S BOTHERING ME NOW!! =:^( Thanks for the frustration. Just what I needed (not!). But oh, well, I guess if it gets frustrating enough I'll bug it myself. Tho it's not there yet, but it's heading that way, thanks to you... Tho in all seriousness I'd rather be aware of the bug than not, so thanks, even if I'm frustrated with it now. Meanwhile, I did a full system update last nite, including rebuilding the latest kde-4.11-live-branch, and unfortunately the problem remains... so apparently there's no fix committed upstream yet. If the problem went away for you, perhaps chakra added a distro patch and you caught it in an update, or maybe it just started working for reasons unexplained, which I always hate because if it just starts working for unexplained reasons, it can just as easily just stop working again too, since the root problem isn't known to have been addressed. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ 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.
