| Summary: | Ability to unassign apps | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Alexander Potashev <aspotashev> |
| Component: | kcm_componentchooser | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.4 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Alexander Potashev
2025-07-06 15:41:52 UTC
Is it a valid configuration to not have an email client set? What would you expect to happen when you click on mailto:// links? > Is it a valid configuration to not have an email client set? What would you expect to happen when you click on mailto:// links?
I think it's valid, at least it works best for me.
I typically use the web UI of email provider in a web browser to compose and send emails.
My rating of convenience, comparing different actions on clicking mailto: links (most convenient on top):
1. Opens confirmation dialog. If I say Yes/Confirm, an existing web UI tab starts message composing dialog. If no relevant web UI tab exists, opens new tab and starts message composing dialog.
* I don't know how to achieve this behavior with existing tools.
2. An existing web UI tab starts message composing dialog. If no relevant web UI tab exists, opens new tab and starts message composing dialog.
* I don't know how to achieve this behavior with existing tools.
3. Opens new web UI tab in the default browser and starts message composing dialog.
* I don't know how to achieve this behavior with existing tools. It feels like it's doable (with some more code in Plasma) because the action is probably equivalent to running kde-open for a (provider-specific) URL that is constructed from the mailto address, however I don't see relevant options in kcm_componentchooser.
* Would be better with a confirmation dialog because sometimes mailto links are hard to recognize: they often look like web links. I may be clicking a link thinking I'm opening a web page while I wouldn't want to send an email.
4. Opens an info dialog displaying the contents of the mailto link.
* Should be doable with a simple shell script wrapper around kdialog, but I don't have enough motivation to set this up.
5. Does nothing.
* This is what I have with /usr/bin/false.
6. Run an desktop email client.
* I'm not aware of an existing email client that supports my email provider well. Maybe I could do better research, but I don't want to spend time on this because I don't send emails often enough.
I agree that your top three options would be best. They would require creating and installing a tiny program to handle mailto:/ links, which would then know how to communicate with the browser. In their absence, allowing you to easily unassign the mail client would have the effect of making mailto:/ links do nothing when clicked. Which I guess would be better than opening a random WINE app. Why is that what shows up as the default mail client? Do you have a windows app installed through WINE that registers itself as a mailto:/ handler? > Which I guess would be better than opening a random WINE app. Why is that what shows up as the default mail client? Do you have a windows app installed through WINE that registers itself as a mailto:/ handler?
I don't know. I don't see any obvious email clients installed through Wine. I should have checked ~/.config/emaildefaults before changing the settings, but now it's too late.
Renaming ~/.config/emaildefaults didn't help - I still see "false" in the KCM.
|