SUMMARY if i receive a notification, that i have a new email, i should be able to click on the email subject, and it opens the actual email. It makes the notification interactive then, rather than being passive, if that makes sense? STEPS TO REPRODUCE 1. close kmail, and when you receive a notification that you have new email, try to click on the subject line. It's not possible. OBSERVED RESULT notifications are passive, and not interactive. EXPECTED RESULT click on the kmail notification, and it should open the email directly from the notification screen. SOFTWARE/OS VERSIONS Linux/KDE Plasma: OpenSUSE TW (20190930) (available in About System) KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1 ADDITIONAL INFORMATION Could also be expanded to include other KDE applications, i would guess.
It's up to the individual apps to implement this behavior (most do, but KMail does not for some odd reason). Kai had a patch that implemented this a few years ago that got rejected: https://phabricator.kde.org/D10068 Might be worth revisiting that patch and the decision to reject it.
Already implemented...
Nice! What was the commit that implemented this?
I don't see any changes to the relevant code files: https://cgit.kde.org/kdepim-runtime.git/tree/agents/newmailnotifier/specialnotifierjob.cpp#n153
Looks like this is not actually fixed. The reporter is asking for the body of the notification itself to open KMail or bring it to the front hen clicked. This is what virtually all other apps do, and the KDE community voted for Consistency as one of the long-term goals, so I think we should consider implementing the requested feature.
(In reply to Nate Graham from comment #5) > Looks like this is not actually fixed. The reporter is asking for the body > of the notification itself to open KMail or bring it to the front hen > clicked. > and? did you enable the plugin and test?
What plugin? If something needs to be enabled, then this isn't fixed. What's being requested should be the default behavior, as it is for everything else.
Created attachment 123091 [details] current notification dialog
We're asking about making the popup clickable, not a "Show email" button
(In reply to Kai Uwe Broulik from comment #9) > We're asking about making the popup clickable, not a "Show email" button Yeah. Another advantage is that if the proposed click-to-open-KMail behavior were implemented, you could remove the "Show email" button and its optional feature, making the notification popup as well as your configuration window a bit cleaner.
(In reply to Kai Uwe Broulik from comment #9) > We're asking about making the popup clickable, not a "Show email" button And how do you implement the other actions exactly? These are useful actions wanted by users. See https://bugs.kde.org/show_bug.cgi?id=376286
(In reply to Nate Graham from comment #10) > Another advantage is that if the proposed click-to-open-KMail behavior were > implemented, you could remove the "Show email" button and its optional > feature, making the notification popup as well as your configuration window > a bit cleaner. The show email button is only shown when one single message is received. How would you magically deal when there are dozens of emails if various folders exactly?
The proposal is that clicking on a notification's *background* opens/shows KMail with that email. Any *buttons* in the notification (such as the "Mark as read" button) would do what they already do when clicked. For the case that multiple emails have come in, my expectation would be that clicking on the background would show the oldest of the new emails.
(In reply to Nate Graham from comment #7) > What plugin? > > If something needs to be enabled, then this isn't fixed. What's being > requested should be the default behavior, as it is for everything else. For you each feature must be activated by default ?! We have plugin when we can or not activate feature as for other apps.
(In reply to Nate Graham from comment #13) > The proposal is that clicking on a notification's *background* opens/shows > KMail with that email. Any *buttons* in the notification (such as the "Mark > as read" button) would do what they already do when clicked. > > For the case that multiple emails have come in, my expectation would be that > clicking on the background would show the oldest of the new emails. Ah why only show the oldest of the new emails ? I don't want to see the oldest I want to see the specific email and it's not possible when we have multiple emails.
(In reply to Nate Graham from comment #10) > (In reply to Kai Uwe Broulik from comment #9) > > We're asking about making the popup clickable, not a "Show email" button > Yeah. > > Another advantage is that if the proposed click-to-open-KMail behavior were > implemented, you could remove the "Show email" button and its optional > feature, making the notification popup as well as your configuration window > a bit cleaner. Why it's complicated to click on a button ? As I explain if we click on notification for closing it and don't click on specific cross we will open email as it's not that I want... It's for that that it will not changed
(In reply to Nate Graham from comment #13) > For the case that multiple emails have come in, my expectation would be that > clicking on the background would show the oldest of the new emails. *your* expectation, indeed.
(In reply to Laurent Montel from comment #14) > For you each feature must be activated by default ?! > We have plugin when we can or not activate feature as for other apps. Making everything configurable does not remove the responsibility to set appropriate defaults. Keep in mind "Simple by default, powerful when needed". (In reply to Laurent Montel from comment #15) > Ah why only show the oldest of the new emails ? > I don't want to see the oldest I want to see the specific email and it's not > possible when we have multiple emails. All right, for the multiple email case, maybe it should just bring KMail to the front without highlighting any particular email. (In reply to Laurent Montel from comment #16) > Why it's complicated to click on a button ? > As I explain if we click on notification for closing it and don't click on > specific cross we will open email as it's not that I want... That's out of sync with what every other app does though. The KDE community has voted for Consistency. This kind of thing is important to our users. We need to keep that in mind.
(In reply to Nate Graham from comment #18) > (In reply to Laurent Montel from comment #14) > > For you each feature must be activated by default ?! > > We have plugin when we can or not activate feature as for other apps. > Making everything configurable does not remove the responsibility to set > appropriate defaults. Keep in mind "Simple by default, powerful when needed". > > (In reply to Laurent Montel from comment #15) > > Ah why only show the oldest of the new emails ? > > I don't want to see the oldest I want to see the specific email and it's not > > possible when we have multiple emails. > All right, for the multiple email case, maybe it should just bring KMail to > the front without highlighting any particular email. Ok we open kmail great and what we will do ? we don't know where are new emails... So no really useful. > > (In reply to Laurent Montel from comment #16) > > Why it's complicated to click on a button ? > > As I explain if we click on notification for closing it and don't click on > > specific cross we will open email as it's not that I want... > That's out of sync with what every other app does though. The KDE community > has voted for Consistency. This kind of thing is important to our users. We > need to keep that in mind. Thunderbird does it for example ?
(In reply to Laurent Montel from comment #19) > Ok we open kmail great and what we will do ? we don't know where are new > emails... Perhaps this demonstrates the different ways that we handle email, but my new messages are all in my inbox. As long as the inbox is visible, I'll see the new emails. Maybe KMail is focused on users who filter everything into different folders and isn't suitable for users who don't? (In reply to Laurent Montel from comment #19) > Thunderbird does it for example ? It used to, but that broke recently (i.e. not doing it is a bug and not a design decision).
Hopefully I'm getting the formatting correct! __ Please see my inline comments below. On 08/10/2019, 16:42, "Laurent Montel" <bugzilla_noreply@kde.org> wrote: https://bugs.kde.org/show_bug.cgi?id=412579 --- Comment #19 from Laurent Montel <montel@kde.org> --- (In reply to Nate Graham from comment #18) > (In reply to Laurent Montel from comment #14) > > For you each feature must be activated by default ?! > > We have plugin when we can or not activate feature as for other apps. > Making everything configurable does not remove the responsibility to set > appropriate defaults. Keep in mind "Simple by default, powerful when needed". > > (In reply to Laurent Montel from comment #15) > > Ah why only show the oldest of the new emails ? > > I don't want to see the oldest I want to see the specific email and it's not > > possible when we have multiple emails. > All right, for the multiple email case, maybe it should just bring KMail to > the front without highlighting any particular email. >>Ok we open kmail great and what we will do ? we don't know where are new >>emails... >>So no really useful. Sorry but I *am* able to see the number of unread emails for each folder when I open kmail. Just because you don’t find this useful, doesn’t mean that it's not useful to others. It's possible to code for this functionality to switch the 'click to open email' function off. That way I think you can be happy, or? > > (In reply to Laurent Montel from comment #16) > > Why it's complicated to click on a button ? > > As I explain if we click on notification for closing it and don't click on > > specific cross we will open email as it's not that I want... > That's out of sync with what every other app does though. The KDE community > has voted for Consistency. This kind of thing is important to our users. We > need to keep that in mind. >> Thunderbird does it for example ? I'm pretty sure that Apple does it, and so does outlook __ -- You are receiving this mail because: You reported the bug.
(In reply to James Th from comment #21) > Hopefully I'm getting the formatting correct! __ > Please see my inline comments below. > > On 08/10/2019, 16:42, "Laurent Montel" <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=412579 > > --- Comment #19 from Laurent Montel <montel@kde.org> --- > (In reply to Nate Graham from comment #18) > > (In reply to Laurent Montel from comment #14) > > > For you each feature must be activated by default ?! > > > We have plugin when we can or not activate feature as for other apps. > > Making everything configurable does not remove the responsibility to > set > > appropriate defaults. Keep in mind "Simple by default, powerful when > needed". > > > > (In reply to Laurent Montel from comment #15) > > > Ah why only show the oldest of the new emails ? > > > I don't want to see the oldest I want to see the specific email and > it's not > > > possible when we have multiple emails. > > All right, for the multiple email case, maybe it should just bring > KMail to > > the front without highlighting any particular email. > > >>Ok we open kmail great and what we will do ? we don't know where are > new > >>emails... > >>So no really useful. > > Sorry but I *am* able to see the number of unread emails for each folder > when I open kmail. You are lucky if you don't have folders with unread email. > Just because you don’t find this useful, doesn’t mean > that it's not useful to others. I can told you the same for you. > It's possible to code for this > functionality to switch the 'click to open email' function off. That way I > think you can be happy, or? There is still the code as defined previously with a button.
> Why it's complicated to click on a button ? Because you need to enable this button first; and it's hidden under 5 levels of nesting, which is not feasible to find for an average user. > For you each feature must be activated by default ?! No, only those that make sense to enable by default. Clickable notifications are something that users of most mail clients out there are used to, so coming to KMail that requires them to open the app by hand every time they see a new message coming, along with a ton of other inconveniences all over the welcome experience, they think KMail is fundamentally flawed. If I was paid for explaining how to enable at least the buttons and why we can't have clickable notifications, I'd be rich by now :)
Also, clickable notifications is classical behavior for almost all systems. User already knows, click on notification should open app. This is expected behavior, why KMail is exception?
Personally I've given up on KMail due to the kind of user-hostile attitudes by developers showcased in this bug report. I'm not the first KDE dev to say this either, and I hear it from users all the time. Ultimately KMail can adapt to the desires of its users, or its userbase can shrink to be just the Kmail developers. That's really all there is to it.
@Laurent Montel, you seem to keep developing kmail as a karma you've acquired. Why don't you give it up and get on with your life? Let someone else who really has an interest and passion for what you do take care of it. You treat people as inferior and disagree with all your opinions. I don't think the KDE community can be contaminated with toxic people like you. Btw, I've never seen any KDE application have so many bugs and not work like KMail. KDE really needs an e-mail client. I don't understand how this is not prioritized.
Enough. Parker will be banned.
Do that. Kick me out for telling the truth. It's good to know how things work around here.
You know, it's been my
*observation that when users are restive like this, it's something that ought to be listened to, even if sometimes they express themselves harshly. You need to look past that and see the underlying problem that they're complaining about. I personally happen to agree with the complaints. In my experience, some of the KMail developers have not been interested in listening to VDG recommendations or respecting the community-set goals. Like I said, KMail can evolve, or it can become obsolete. If you don't pick the former, the latter happens by default.
Give me a break. KMail is not just KMail. It consists of dozens of repositories that are maintained by a single developer 365 days each year. If you want it to evolve beyond that, find more developers who are not scared by the complexity of the codebase. Most bugs, by the way, are in the multi-process design dictated by Akonadi. It needs many developers and many years to fix that design. > KDE really needs an e-mail client. These types of statements usually come from users who don't like the available alternatives.
"[...] that are maintained by a single developer 365 days each year." Did you realize you just agreed with what I said earlier? He works alone because the people who try to help him can't. If you want everything to be done your way, you don't have patience with those who are learning and you think you're right about everything, so there's no surprise if you work alone. This isn't just about lines of code, it's also about the person you are. Treating people who come here to make a suggestion or report a bug well is essential and necessary. KMail has a lot of bugs and a lot of things don't work, but that doesn't mean it's dead. It just needs to be more open to contributions. If that's done, other people will contribute.
*** Bug 436643 has been marked as a duplicate of this bug. ***
*** Bug 392243 has been marked as a duplicate of this bug. ***
Same issue here. Clicking on a notification doesn't open kmail or take you to the email.