[Akonadi] [Bug 317709] Add an option to disable Akonadi
https://bugs.kde.org/show_bug.cgi?id=317709 --- Comment #3 from Woodsman darre...@hushmail.com --- kdepim* uses akonadi so we can't do it. So this is non-negotiable? End of discussion? -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 317709] New: Add an option to disable Akonadi
https://bugs.kde.org/show_bug.cgi?id=317709 Bug ID: 317709 Summary: Add an option to disable Akonadi Classification: Unclassified Product: Akonadi Version: 4.10 Platform: Other OS: other Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: darre...@hushmail.com Akonadi is useful to certain types of users, such as enterprise users, users with a significant amount of personal data, those who store personal information remotely, etc. Such users welcome the Akonadi framework. At the other end of the spectrum are users who have no data coordination needs yet still would like to use KDE PIM apps. One unpalatable option --- both for users and for KDE public relations --- is for such users not to use KDE PIM apps. Another option is to provide some kind of method to disable Akonadi. The traditional KDE approach is to let users decide how to configure their systems. KDE developers accomplished a significant milestone when they added options in Systems Settings to control the behavior of Nepomuk, including disabling. KDE developers could achieve another milestone with a similar approach toward Akonadi. Initially disabling Akonadi is straightforward: ~/.config/akonadi/akonadiserverrc StartServer=false. A remaining challenge is for all Akonadi enabled apps to honor the akonadiserverrc StartServer setting and function as stand-alone apps rather than function only within the Akonadi framework. Currently no run-time option exists to disable Akonadi within KDE PIM apps. Other than KAlarm, currently no options exist to compile other KDE PIM apps without Akonadi. Adding either support would be a great public relations effort for KDE developers as well as encourage many KDE users to again use KDE PIM apps. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 316860] Recent Addresses no longer appear in the Select Recipient dialog
https://bugs.kde.org/show_bug.cgi?id=316860 --- Comment #2 from Woodsman darre...@hushmail.com --- Great, thanks. Let me know if I can help test. :) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 301282] Add option to disable KWallet integration completely
https://bugs.kde.org/show_bug.cgi?id=301282 Woodsman darre...@hushmail.com changed: What|Removed |Added CC||darre...@hushmail.com --- Comment #1 from Woodsman darre...@hushmail.com --- This bug still exists in 4.10.1. I would like to see that functionality returned. In Kmail1 the passwords were stored in the kmailrc and were encrypted. Users moving from KMail1 to KMail2 who are not using or never used kwallet get confused when KMail2 asks for passwords with each fresh KDE session. When creating POP3 accounts in KMail2 the password text box is disabled and users can't enter a password because kwallet is the only option in KMail2. Being required to use kwallet is not intuitive to users who don't use or never have used kwallet. Currently the only solutions are to type all passwords every fresh session or use kwallet. Using kwallet is a reasonable approach but there are many non enterprise users who do not need or want that complexity. :) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 316815] No KMail2 notification with local mail
https://bugs.kde.org/show_bug.cgi?id=316815 --- Comment #1 from Woodsman darre...@hushmail.com --- A work-around: create a filter to move the mail from the Local Account folder to the inbox. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 316860] New: Recent Addresses no longer appear in the Select Recipient dialog
https://bugs.kde.org/show_bug.cgi?id=316860 Bug ID: 316860 Summary: Recent Addresses no longer appear in the Select Recipient dialog Classification: Unclassified Product: kmail2 Version: 4.10.1 Platform: Slackware Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: composer Assignee: kdepim-bugs@kde.org Reporter: darre...@hushmail.com In a Compose window, after pressing the Select button, the Select Recipient dialog no longer shows the list of Recent Addresses. Reproducible: Always Steps to Reproduce: 1. Open a Compose window. 2. Press the Select button. 3. Verify the Select Recipient dialog does not contain the list of Recent Addresses. Actual Results: The Select Recipient dialog does not include the Recent Addresses list. Expected Results: The Select Recipient dialog should include the Recent Addresses list This always worked in KMail1. A nominal work-around is using the type-ahead feature in the To: text box, but users can't always remember an email address. In the KMail1 Select Recipient dialog users saw something like this: = All Default Address Book Personal Contacts Distribution Lists Recent Addressess - This does not appear = The KMail1 dialog had a button at the top to filter which list the user wanted. The default was All, but the user could change the filter. Not having the Recent Addresses list in the Select Recipient dialog is cumbersome to non enterprise users who have no need for full scale contact lists. The Recent Addresses list is present as can be verified by using the type-ahead feature or in Settings - Composer - General - Edit Recent Addresses. I suspect the regression occurred with the move to the akonadi backend. I'm guessing the Select Recipient dialog is now expected to be populated only with akonadi resources. The previous code for grabbing the Recent Addresses list from the kmail2rc file was inadvertently forgotten. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 316815] New: No KMail2 notification with local mail
https://bugs.kde.org/show_bug.cgi?id=316815 Bug ID: 316815 Summary: No KMail2 notification with local mail Classification: Unclassified Product: kmail2 Version: 4.10.1 Platform: Slackware Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: darre...@hushmail.com I receive a notification when receiving POP3 mail but never when I receive mail from my local system account. I have tested with both a sound file and the popup system. As far as I can tell, notifications are global and should play for all received mail. I don't see any special notification configurations for local system mails. Reproducible: Always Steps to Reproduce: 1. Send a message to the local mail box, such as: echo This is a test. | mail -s Testing root@localhost 2. Verify KMail2 show sthe message in the Local Account folder. Actual Results: No notification is received. Expected Results: A notification. KDE 4.10.1 -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 316815] No KMail2 notification with local mail
https://bugs.kde.org/show_bug.cgi?id=316815 Woodsman darre...@hushmail.com changed: What|Removed |Added Component|general |commands and actions -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 316816] New: New mail notification is always delayed
https://bugs.kde.org/show_bug.cgi?id=316816 Bug ID: 316816 Summary: New mail notification is always delayed Classification: Unclassified Product: kmail2 Version: 4.10.1 Platform: Slackware Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: commands and actions Assignee: kdepim-bugs@kde.org Reporter: darre...@hushmail.com I do not receive a notification for about 15 to 30 seconds after fetching mail. Unlike bug report 283033, thus far I believe I have always received a notification, just oddly delayed. Reproducible: Always Steps to Reproduce: 1. Fetch mail. 2. Wait 15 to 30 seconds for a notification. Actual Results: Delayed notification. Expected Results: Based upon long usage of Kmail1, faster notification. I have only three POP3 accounts, no IMAP accounts, and one local system account. I do not receive a high volume of mail. Two of the POP3 accounts are with the local mom-and-pop ISP and response is always fast to receive mails. With KMail1 fetching and notification were fast. This report is similar to bug report 283033, but not exactly the same. I don't mind if the two reports are merged, but I did not think this problem was exactly the same. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
