Re: [kde] Akonadi acting up (again)
Sorry Kevin but I think you have missed the point on the not relevant aspect. Entire post this time really. They may be very relevant from a coding standpoint but not for a user other than one who says Gee this uses an amazing structure and others are using it too so I don't care if it's slow or keeps having problems. :-) Maybe an extreme way of putting things but in essence what matters most? User experiences or implementation/structure if the latter spoils the former. I am not saying that there is anything fundamentally wrong with the structure that is being used either. Just that there seems to be a significant difference in the performance aspects of email in KDE3 as against default email in KDE4. Maybe it's a Windows approach - ah well people will upgrade and Intel plus Moore's law will sort it out. I have noticed that in some ways a 2.6gh dual core plus 8gb of ram can struggle at times running KDE4. Perhaps the problem is not structure but implementation. Going on some other applications it does seem that C++ can have this effect. On the other hand this is not always the case. Makes me feel that there are 2 forms of writing C++ software, OOPs and OOP. In terms of actual performance in the real world Moore's law is a bit dubious anyway. Akanadi etc. Yes different services. I new that there was some tie up but hadn't looked to see what it was. http://cmollekopf.wordpress.com/2013/02/13/kontact-nepomuk-integration-why-data-from-akonadi-is-indexed-in-nepomuk/ Interesting read linked to of the user basefrom here http://userbase.kde.org/Akonadi From this it seems I may well be using KDE4 file indexing even with it turned off. Fine if so as it hasn't done any of the things I don't like. The problem with using inactivity as a trigger was demonstrated when it was forcibly used on SuSe to spin down the disks. As things stand there is no way of determining when an inactive period will end. It also seems that if I really do disable indexing I may loose my digital clock and perhaps one or two other things. The clock sounds like someone thinking wouldn't it be nice to use to me. Hanging too much off a service may be a bad idea any way. Me well I am not against change and also realise that windozy things are a mature technology. All arrangements boil down to some patch of screen with icons or the results of some application in it etc. Difficult to change really but things move on. :-) I sometimes think there are too many software people about with too little to do. On the other hand it's a frightening thought that a PC user such as my wife can do all she generally does on an iPad with a lot less power and sadly more ease. Speed - well printing does take some time to send the data but might not if airprint was available. In all other respects it's way way quicker to use than a net book for instance and just about does all of the things a lot of people want to do. My son bought me one for my birthday and I have to admit it's the most definite step forwards I have seen in a long time even with it's limitations which in practice for many people are few. John - Original Message - From: Kevin Krammer kram...@kde.org To: kde@mail.kde.org Cc: Sent: Tuesday, 24 September 2013, 18:33 Subject: Re: [kde] Akonadi acting up (again) On Tuesday, 2013-09-24, John Woodhouse wrote: - Original Message - From: Kevin Krammer kram...@kde.org 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
Re: [kde] Akonadi acting up (again)
On Friday, 2013-09-27, John Woodhouse wrote: Sorry Kevin but I think you have missed the point on the not relevant aspect. Entire post this time really. Not at all. I was replying to a part of a mail that introduced development aspects such as programming paradigm and code-reuse. Users of KDE software can be quite advanced or even be developers themselves, so it made sense to respond to those items with the appropriate details. have this effect. On the other hand this is not always the case. Makes me feel that there are 2 forms of writing C++ software, OOPs and OOP. I am not aware of a paradigm names OOPs, but C++ supported development along the lines of many paradigms, usually used in a mixture of them. It is mostly imperative programming, often object oriented, but also sometimes functional. http://cmollekopf.wordpress.com/2013/02/13/kontact-nepomuk-integration-why- data-from-akonadi-is-indexed-in-nepomuk/ From this it seems I may well be using KDE4 file indexing even with it turned off. Very unlikely. The approach described in Christian's blog does not involve file indexing either. The problem with using inactivity as a trigger was demonstrated when it was forcibly used on SuSe to spin down the disks. As things stand there is no way of determining when an inactive period will end. Yes, but it is a starting point for doing the necessary work when it is least intrusive. They do employ other techniques as well AFAIK. It also seems that if I really do disable indexing I may loose my digital clock and perhaps one or two other things. The clock sounds like someone thinking wouldn't it be nice to use to me. I would be surprised if the clock applet interacts with the index in any way. But I am not on the most recent workspace release. 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] Akonadi acting up (again)
On Fri, Sep 27, 2013 at 04:07:26PM +0200, Kevin Krammer wrote: Ah, being a regular user, I didn't know of the job tracker yet. :) It shows thousands of Akonadi::CollectionFetchJob being entries being created and processed. I recently came across a code review request that fixes a bug that sounds a bit like that. It is triggered in situations when, if I remember correctly, the number of favorite folders goes beyond 10. Might that be the case for you? Nope, I only have three. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Gegen Pechsträhnen sind auch Friseure machtlos. signature.asc Description: Digital signature ___ 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 kram...@kde.org 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)
Le lundi 16 septembre 2013 01:49:05 Frank Steinmetzger a écrit : Do you have any advice that might help me here? I don’t relly want to delete the resources and download everything anew again. If at least I could find out what the hell is keeping Akonadi up. Hi, I just realized this : you don't have to delete the resources, just clear the database. I'm using a system-wide mariadb server, and it came down to connecting to maridb, dropping the db, creating it anew, and granting necessary privileges. No need to reconfigure any resources. I admit I don't know what to delete to only delete the akonadi internal db. I suggest you only do that, it's relatively pain-free. Martin ___ 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 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. Akonadi, like Evolution Data Server (short EDS) before [1], is a service oriented approach to PIM data access. 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? Cheers, Kevin [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 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] Akonadi acting up (again)
On Wednesday 18 September 2013 20:32 Chao Feng wrote: Please check the note in Arch Wiki: https://wiki.archlinux.org/index.php/KDE#Clean_akonadi_configuration_to_fix_kmail AFAIK this is *not* good advice. You should check at the kdepim-users ml: https://mail.kde.org/mailman/listinfo/kdepim-users -- Med venlig hilsen / Best Regards Thomas Tanghus ___ 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)
Hi Frank, On Monday, 2013-09-16, Frank Steinmetzger wrote: On another machine I had the same symptoms at first, but then it behaved again. But that was a 32 bit system. On my current main 64 bit machine, it just isn't happening. Akonadi has been clogging the CPU for 20 minutes now. Closing the KMail or Kontakt window doesn't help, the CPU load is still there. I have to kill the KMail/Kontact process which still lingers in the background, only then will Akonadi return to being quiet. That sounds a lot like the problem being in KMail or in something that KMail does. It not exiting on quit is a hint that there is some active action inside it that inhibit application exit, e.g. some long running job. Also, the fact that killing it stops the observed CPU usage again suggests that it is the origin of the load. I am not sure how best to check what it is doing right there. One thing you could try is to run akonadiconsole before launching KMail and then check the Job Tracker tab when the high usage occurs and look which type of job is reported as running for KMail. 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] Akonadi acting up (again)
On Mon, Sep 16, 2013 at 11:38:40AM +0200, Kevin Krammer wrote: Hi Frank, On Monday, 2013-09-16, Frank Steinmetzger wrote: On another machine I had the same symptoms at first, but then it behaved again. But that was a 32 bit system. On my current main 64 bit machine, it just isn't happening. Akonadi has been clogging the CPU for 20 minutes now. Closing the KMail or Kontakt window doesn't help, the CPU load is still there. I have to kill the KMail/Kontact process which still lingers in the background, only then will Akonadi return to being quiet. That sounds a lot like the problem being in KMail or in something that KMail does. It not exiting on quit is a hint that there is some active action inside it that inhibit application exit, e.g. some long running job. Also, the fact that killing it stops the observed CPU usage again suggests that it is the origin of the load. I am not sure how best to check what it is doing right there. One thing you could try is to run akonadiconsole before launching KMail and then check the Job Tracker tab when the high usage occurs and look which type of job is reported as running for KMail. Ah, being a regular user, I didn't know of the job tracker yet. :) It shows thousands of Akonadi::CollectionFetchJob being entries being created and processed. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Even a Bonsai dreams of greatness. signature.asc Description: Digital signature ___ 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.