FireFox mailto created undecoded URL's

[GreyGeek]

When Google teamed with Facebook and other Social Websites to censor "hate" speech I decided it was time to drop Google and GMail, which I did. I also deleted Chromium and switched to FireFox. FF has a "mailto" icon which you can add to the toolbar with the "Customize" menu in the upper far right corner. I made the "mailto" icon visible. I set the "Applications" setting in FF for "mailto" to use "KMail(default)", an option that was presented to me. When one is browsing a website and wants to email its URL and title to someone they left-click the mailto link and the chosen email client opens up with the subject line containing the title of the article and the body of the email containing the URL.

The problem was that special characters in both the subject line and the body of the email was being represented by escape codes, i.e., "/" was %2F. So, "http://..." was presented as "http%3A%2F%2F...", which recipients browsers choke on. Obviously using "KMail(default) didn't work.

I opened a tab to "about:config" and searched for "mailto". I found a page full of doublets:
gecko.handlerService.schemes.mailto.0.name
gecko.handlerService.schemes.mailto.0.uriTemplet
gecko.handlerService.schemes.mailto.1.name
etc...
All populated with Yahoo! and Gmail info.

I changed the 0 schemes to
gecko.handlerService.schemes.mailto.0.name;kmail
gecko.handlerService.schemes.mailto.0.uriTemplate; kmailservice %U
and emptied the others.

and in FireFox's settings I used the method shown in the following link:
https://userbase.kde.org/KMail/FAQs_...lto:_addresses

[B]Tell Firefox to use KMail for mailto: addresses[/B]

[I]Solution:[/I]  
Firefox 3 - In the [B]Firefox[/B] menu, select Edit -> Preferences, choose the Applications tab, then type mailto in the search box. 
  Choose Use Other... and find /usr/bin/kmailservice

Works perfectly!

[dequire]

That's a great tip! Thanks so much for sharing. I use Thunderbird but plan on switching to KMail's successor, Kube, very shortly. This tip will come in handy for that for sure!

[GreyGeek]

Where did you read that Kube was going to replace KMail?
The (one of) author of Kube indicated in March that he (they) were just beginning development. I suspect that IF it is in the works to replace KMail it may be at least a couple years before it reaches KMail's current strength and feature set. Maybe longer.

From the info in the following link:
https://cmollekopf.wordpress.com/201...ture-a-primer/
it seems that Kube will be a cross platform (just as QT is) PIM/Groupware type of app with the kitchen sink thrown in for good measure. The "Documentation" is here. It appears to be a re-hash of the classic QT Model-View-Controller programming discussion in QT's API, which features Models, Views, Controllers, Delegates, Sorting and Indexing. Where I worked before I retired I used the QT MVC paradigm a lot to present tables as grids on multi-tabular GUI interfaces. They are going to use Qt Quick and QML to build Kube, which is supposed to be a GUI RAD tool, since QML is the Qt Modeling Language. It sounds easy but on-the-fly modifications of table view columns, widths, lengths to coordinate with data content can be very tricky and is prone to breaking when Qt upgrades to the next version (I speak from experience!). Even before the introduction of Qt Quick and QML the QT API was and is a very very good GUI RAD dev tool.

[dequire]

Thank you for the explanation regarding Qt. I'm not sure any PIM-type app will ever reach the level of nuances, tools, and settings that KMail has. That's not a bad thing IMHO. If you took the average user and put them in front of Kontact for the 1st time and asked them to set everything up to their satisfaction I doubt many could. Only us grizzly vets who have been around KMail for a long time can seem to tame the beast with any level of satisfaction (search back-end not withstanding). And that is only after configuring what seems like 15+ tabs of settings.

I think I should clarify that I'm looking forward to Kube being my replacement for KMail / Kontact. In all the years of my using KDE, I still cannot bring myself to really enjoy KMail. At the end of the day, it just seems excessive, buggy, and too rigid in how it handles the things it tries to do. Right now I'm using a Kolab account sync'd to Thunderbird. However Kube + Kolab, when fully vetted, will fill my needs better across all form-factors without the need for 3rd-party add-ons to handle the sync'ing. Additionally, I love Kolab's privacy position. I also like that their collaborating with RoundCube on the project. I wish more open source organizations were more open to collaboration like that. And it all fits nicely within the KDE ecosystem

[GreyGeek]

There is a nice collection of GPL groupware available to Linux today.

The best groupware I ever used was LotusNotes, although it wasn't GPL. It was smooth as butter, had a well integrated email, calendar, notes, database, forms, form designer, and more. About a year before I retired a new tax commissioner was elected. He brought in an "assistant" tax commissioner (replacing one with two to save money LOL!) and that assistant only knew how to use MS software. So she mandated that 10,000 out of 13,000 Nebraska state employees toss toss LotusNotes and move to Microsoft apps to "standardize" the state. The result was disastrous. We lost the value of nearly $1 Million in LotusNotes licenses and replaced them with about $3 Million in MS licenses. OutLook, sharepoint and MSAccess were as about well integrated as oil and water. In addition, while we could export the data and files from LotusNotes, there wasn't a good way to import that data into Microsoft's mess. Productivity was cut by more than a half. Lots of history was now a nightmare to access, if it could be accessed at all. On a similar front, we had been using MS Visual Foxpro to write apps and keep data. The suits started talking about moving that data to a real database that could do selects for specific records without passing the entire db past the client's terminal, like VFP does. I recommended PostgreSQL. They turned it down because "there was no support". I referred them to the paid support sites for PostgreSQL but since the fees weren't very large they concluded that the support must be poor, so they weren't interested. They went with Oracle. When blades with multicore CPU's came out Ellison got the greedy idea of charging a per-cpu license fee, and a big fees they were. Suddenly a $10K/yr license for a single blade became a $40K license for the same blade. I am not privy to the exact Oracle license costs per year but they have to be in the several hundreds of thousands to a million or more per year. Meanwhile, PostgreSQL continued to be free and to improve as fast or faster than Oracle. My son became the Oracle admin and after several fruitless attempts to get problems fixed at the paid Oracle support site he turned to an opensource support site. Problems were usually answered within minutes or a couple hours, no charge. The same problem ticket on the Oracle support site languished for days or weeks, and the response was usually identical to what the open source site recommendations were. It turns out that the free help on the open source support sites were actual Oracle users and admins themselves, fed up with Oracle's lack of timely response.

[dequire]

Another example of Open Sauce doing it's thing better than the very in-efficient commercial counterparts. I've worked for a few large software / tech companies and in every case the support / maintenance contracts were where ALL the profit was made. It's literally 100% profit, since all of the revenue is realized upon the client signing the contract, with zero cost! This is because "support" is not an asset or a quantifiably tangible item. Also, more often than not, it will largely never be used anywhere near proportionately to the monthly cost. Add to this absolutely no incentive for the support person to prioritize your particular issue, or even know how to approach it, therefore needing it be "escalated" to someone else. And the process starts all over. So your story about the illogical rationale from a procuct perspective to your son's ability to get to the bottom of the issue faster on a community-supported site makes sense to me and fits with my experiences.

By the way, as for Kontact, it does seem that it will be going away at some point in the near-ish future. Kolab is the primary developer of Kontact and KDE PIM, and has been for a long time. The head (full time) developer of Kontact works for Kolab and is now the head developer of Kube. You can see his video where he talks about replacing Kontact in this video, taken from the Kolab Summit a few weeks ago:

Also, our good KDE friend Aaron Seigo, who is now the CTO for Kolab, speaks about it briefly here. Of course, this does not mean that KDE Applications will instantly abandon Kontact. However four things will ensure it's demise IMHO.
1) Without Kolab's developers working on Kontact, there's likely no way the community could step up and carry the torch. Even if there was a desire, the learning curve to actually be anywhere near efficient at coding for Kontact would likely be a pretty steep challenge
2) The code is very old. As pointed out in the video by Jeroen van Meeuwen, changes and especially new functionality are brutally hard to implement due to old code base
3) We live in a social, collaborative society. While Kontact is a good desktop PIM client, we are not chained to our desktops anymore. Konatct's collaboration capabilities are limited to email. Pretty 2001. And finally
4) Without using MS or Google as a conduit it becomes almost impossible to have a single PIM suite across PC's, phones, laptops, etc. I don't want to have to be at my PC to accept an appointment invite, and I don't want to fanangle with 3rd party (often paid-for) middleware Android apps to get it done.

I want an opensource, non Google solution and companies like Kolab are helping to make sure I can have it. Of course, if one only cares about performing IMAP email, notes, calendar, etc. on their desktop then Kontact, Thunderbird, and friends are more than capable.

[GreyGeek]

Interesting videos!
It appears that the email component will be completed by the end of the year and the other components by the end of next year. Eighteen months for such a complex suit is really aggressive! I like the fact that they are going to integrate with LibreOffice's cloud. LibreOffice is great!

I wondered where Aaron went. He's a sharp guy.

Now this has me wondering if their plans include compatibility with iPhone and/or Android.

[dequire]

Now this has me wondering if their plans include compatibility with iPhone and/or Android.

At about the 28 minute mark Jeroen mentions that since the back-ends are modular and separate from the UI, the plan for mobile is to write the front-ends for those in QtQuick. So yes, they are in the pipeline!

[GreyGeek]

That's good! Looks like Kube is in my future!

[dequire]

That's good! Looks like Kube is in my future!

Emphatic "dittos" from here as well!

[dequire]

Here's a recent update...Kube (KMail's supposed successor) has a preview release...finally!

https://cmollekopf.wordpress.com/201...of-kube-0-3-1/

Looks like we soon may have more options then just T-Bird or Kmail for KDE Plasma.

[GreyGeek]

How can you tell? The link to their latest release is broken!

[dequire]

How can you tell? The link to their latest release is broken!

Well I was going by the blog post and feedback. I'm not sure what link you are referring to?

https://github.com/cmollekopf/docker...kdesrc-buildrc

[GreyGeek]

Well I was going by the blog post and feedback. I'm not sure what link you are referring to?

https://github.com/cmollekopf/docker...kdesrc-buildrc

This one:
https://kube.kde.org/2017/07/04/0.3-released.html