https://bugs.kde.org/show_bug.cgi?id=292606
Nate Graham <n...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aleix...@kde.org,
| |dvra...@kde.org,
| |fa...@kde.org,
| |k...@davidedmundson.co.uk,
| |k...@privat.broulik.de,
| |mon...@kde.org
--- Comment #20 from Nate Graham <n...@kde.org> ---
Unlike Bug 350663, this one seems a lot tricker. Here are the results of my
investigation tonight:
Selecting "Use different email client" in the KCM and entering some text there
results in ~/.config/emaildefaults being updated: it adds or updates
EmailClient[$e]=<the text you entered>. This is very reliable and happens 100%
of the time.
This ~/.config/emaildefaults file seems to be something KDE-specific:
https://cgit.kde.org/kconfig.git/tree/src/core/kemailsettings.cpp#n228. It
appears to be read in only one place:
https://cgit.kde.org/kservice.git/tree/src/kdeinit/ktoolinvocation_x11.cpp#n132,
but that invokeMailer function is used all over the place:
https://lxr.kde.org/search?_filestring=&_string=invokeMailer
However, somehow nothing set in that file actually seems to be getting used;
mailto: links totally ignore it.
~/.config/mimeapps.list also stores information on the default mailto: handler.
The [Default Applications] section always seems to have
x-scheme-handler/mailto=org.kde.kmail.desktop;. This can be overridden in the
[Added Associations] section. Mine has
x-scheme-handler/mailto=thunderbird.desktop; in there. It seems that
Thunderbird added itself there when it asked whether or not it could be the
default email client and was told yes. The config data stored there seems to
take precedence over ~/.config/emaildefaults.
This feels fragile. Conceptually, it seems like we might want to deprecate
~/.config/emaildefaults and just rely on ~/.config/mimeapps.list, which is a
cross-desktop standard. All the functionality is still there via the apps'
desktop files. Also, when an app implements its own "do you want to make me the
default program?" UI, it will update the shared config data so the KCM can
update its own UI display automatically, rather than the two drifting out of
sync and making the KCM inaccurate, which is what's happened here.
Does any of this make sense? I'd very much appreciate if someone of a more
veteran KDE tenure could let me know if I'm on the right or wrong track here. I
CCd a bunch of you, hope you don't mind!
--
You are receiving this mail because:
You are watching all bug changes.
