“Kube is a modern communication and collaboration client built with QtQuick on top of a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todo’s and more. With a strong focus on usability, the team works with designers and UX experts from the ground up, to build a product that is not only visually appealing but also a joy to use.”
For more info, head over to: kube.kde.org
Kube 0.3.1 is out the door.
Over the past months we’ve been working hard on turning Kube into something more useful than a pure techpreview, and while Kube 0.3.1 still isn’t anywhere near production ready, I can finally say that I can use it for most of my email needs.
First, let’s get out of the way what doesn’t work just yet so you know what you can expect.
- We don’t provide any upgrade path, so with every release it is necessary to run “sinksh upgrade” manually, which currently simply nukes all your local caches (but not the config, so you’ll just have to resync).
- Email sending is limited to plaintext (we convert html mails to plaintext on reply).
- Passwords are stored in plaintext in configuration files, which may not be acceptable to you.
- It’s of course also possible that you will experience unpleasant surprises if you use it for any relevant emailing.
- The scrolling experience depends a lot on your input devices. This seems to be a Qt internal defect that we hope will resolve itself with Qt 5.9.
What we do have though is:
- A working composer that is right now very basic but has a lot of potential (more about that in a separate blogpost).
- Support for reading encrypted and and signed mails (although the UI support is still very basic for details on validitiy etc).
- A basic CardDAV based Addressbook.
- A fairly pleasant reading experience (IMO anyways).
Lot’s of work also went into the application architecture, UI feedback for user interactions (e.g. progress during synchronization), cleanup of our dependency tree and the concept of how we will continue to evolve Kube.
The UI team did excellent work on the UI front (surprise!) and has cleaned up the look considerably. Due to the realization that our look depends a lot on the looks of the icon theme, we are now shipping an icon theme with Kube (based on breeze). This will also further our goal to work equally well on a variety of platforms where we cannot assume a specific icon theme to be available.
We have also transitioned mostly to QtQuickControls2, the remaining bits will require Qt 5.9. We’ll then plan on staying on this LTS release for the time being.
Overall, while not quite ready for prime time, this release marks a very important milestone on our road to a production ready release and I’m very happy to have a lot of issues, that have been bothering us for long, finally resolved.
I also think that while we’ll still have to do one or the other large change every now and then, the codebase can now start to settle as we have resolved our largest problems.
If you’d like to read more or give it a shot, please head over to kube.kde.org for installation instructions for experimental builds for Fedora 25 and Archlinux.
Tarballs
https://download.kde.org/unstable/sink/0.3.0/src/sink-0.3.0.tar.xz.mirrorlist
https://download.kde.org/unstable/kube/0.3.1/src/kube-0.3.1.tar.xz.mirrorlist
Randa
Unfortunately I can’t attend Akademy this year, but if you’d like to work on Kube, talk to us, have a Beer or just go for a hike, make sure to come to Randa for the annual Randa Meetings from the 10.09.2017 – 16.09.2017. To register click here.
Finding New Ways... 
The installation instructions link doesn’t lead anywhere!
https://kube.kde.org/join.html
if you are on Arch you can install it from AUR:
https://aur.archlinux.org/packages/kube
Sorry, it does now. Thanks for pointing it out.
Error: nothing provides sink >= 0.3.0 needed by kube-0.4-0.fc25.x86_64
So far so “good”… (your COPR)
Not sure why the build worked on copr anyways… Triggered a build with sink 0.4 now, thanks for pointing it out.
Let me suggest a couple of ideas for your cool (and highly anticipated, Kontact has aged so badly) project.
Would be great if Kube became a universal messaging client, not only email but also able to configure Telegram, Signal, Facebook, etc, accounts; a complete center where users were able to receive, send and keep our messages from different plattforms.
There was KTP, but it’s abandonware now, and it only worked for instant messaging systems, not really a “total” messaging software.
Also, if multimedia content were reproducable inline, similar, again, to Telegram, which can play audios, GIFs, videos from Youtube, Twitter and others, and show web links like those documents created with its telegra.ph plattform and websites like Medium; and all this without leaving the app, it would be THE message center.
I suppose this kind of embedding must imply a lot of complication to the development, but I also think it would be real development and innovation, big stuff. Otherwise I don’t see the difference with common email clients besides a more modern aspect and “mechanics”, but still yet another email and notes client.
Oh, BTW, talking about notes. Do you plan to support HTML and Markdown notes? Kjots was never a complete notes app since image or audio embedding never were implemented. There’s a nice app for Markdown notes for Plasma called Qownnotes (http://www.qownnotes.org/), but to my taste depends too much on Next/Owncloud’s notes app and doesn’t integrate with Akonadi, but just works, and very decently.
Cheers.
BTW, in case you want to include this info to https://kube.kde.org/join.html, Kube is also available en Gentoo’s repos. Just “emerge -qa kube” will install it quietly after asking for confirm. It’s masked (obviously due to its early development state), but I have just installed without problems.
Also, during installation I’ve seen how small weighted is Kube. I suppose that as it becomes more “finished” it will grow, but I like it light and, I hope, agile (Kontact, well, Akonadi, to be more exact, is everything but agile), so perhaps my former suggestion of supporting differente messaging platforms would add a noticeable weight to the app. Besides, not all users would need more than email support, so, what about making Kube expandable via plugins, like thunderbird and Firefox? This would keep the core app light and permit to increase its strengths depending od the users’ needs.
I can’t recall now, but I think I’ve seen some app (not for Linux) that reunites several messaging systems under the same app (could be Slack? My memory isn’t doing its job very well now…). I don’t know, but if you know what I’m talking about maybe you can take some ideas from it.
Thanks for the hint with gentoo, I’ll include that.
We’ve worked hard to make it as lightweight as it is and I intend to keep it that way. It will grow some, but not vastly and only with in itself reasonable dependencies. Should we indeed start pulling in lots of different protocols and thus potentially dependencies, as said in the other reply, we have the plugin system, but I want to avoid splitting it up too much prematurely because that will just introduce more friction into the development process.
Thank you for your input!
As for the unified messaging: This is very much in the scope of what we try to do. We’re trying to do communication and collaboration, and not per se any specific protocols. Sink (Kubes storage and synchronizatoin core) provides a plugin system that would allow us the write backends for all sorts of protocols and would also allow us to split the packaging up so we don’t end up with all sorts of dependencies. In any case, email is just a first step and not the end goal. However, there are also a lot of problems left to be solved as we don’t just want to implement a new UI for instant messaging services (they already provide that), it should be about conversations with persons so this will also require a good deal of thought for the application model and design.
With regards to inline media. In principle we already have the capability as HTML mail already forces us to use a fully-fledged browser (webengine) to be able to render those, and that brings the capability to display embedded media. However, I’d rather not venture too far that rabbit hole and limit the use of complex HTML as far as possible.
For writing we are a big fan of Markdown, but we’ll have to see what we end up with. In any case theres a balance to be struck between allowing for rich messaging (including picutres/videos/…) and not having to deal with technically insane things like browsers that are also ridiculously resource hungry. The same conundrum applies of course for notes.
Thanks for your detailed and easy to understand by non techies explanation. I find your points very reasonable.
Nevertheless I’d like to note that nowadays, when the frontier between mobile and desktop becomes more diffuse every day, notes have become more audiovisual, many are in fact drafts that one completes later to end as ODT or PDF documents. Many people don’t even take text-only notes on their mobile devices (many don’t use text notes at all) but audio notes, video notes, hand made sketches, or illustrate some audio or text note with a couple of pictures. Evernote is the “standard de facto”, but also MS OneNote is rather good.
Well, I’d like Kube to support all these features so notes stop being the “poor cousins” in the Linux desktop and become first class citizens, because is rather frustrating not being able to continue editing the multimedia notes we have taken on our tablet if not using FOSS hostile tools like Evernote.
I hope you can find a good solution that doesn’t imply the use of complex HTML, as you said, but also doesn’t limit modern note taking habits; or at least make a plugin system potent enough to allow that someone in the future can write a complete plugin.
A last thing: where can one contribute reporting bugs? Kube doesn’t seem to accept as correct anything I type after “imaps” in that protocol://server:port scheme in the account configuration page.
For now we just have https://phabricator.kde.org/project/view/43/ for development coordination. We’ll probably create a Bugs subproject there, feel free to contribute other ideas there as well.
Being able to deal with richer content would certainly be valuable. The challenge is in not killing interoperability while doing so. There is no standard for notes, so whenever you venture outside of plaintext you risk being incompatible with backends. Also, while I agree there is value in supporting a variety of media types, even having a well functioning plain-text solution would be a huge step forward for me, so that’s likely what we will work towards in the beginning (although we also might just go straight to what the composer supports by then, which will probably include simple html and attachments, and perhaps markdown).
Thanks again.
So I must wait for that bugs subproject to report my problem when trying to add an IMAP account. What about bugs.kde.org? Wouldn’t it be the natural place to report bugs and suggest features?
You can just add an issue to the Kube project for now.
bugs.kde.org tends to become a black hole for issues if nobody is actively looking at it and relentlessly closing stuff that won’t get fixed in a useful timeframe. Further it’s a completely separate system which adds a lot of friction to the process, so we’ll keep everything within phabricator for now (and possibly forever).
We now also have a dedicated place for bugs on phabricator: https://phabricator.kde.org/project/profile/238/
For easier handling of encrypted communication , you might want to talk to the people of pretty easy privacy pep-project.org.
Less interaction needed by users and might be helpful with the display part of relevant information.
Yeah, I’m aware of the project. I can’t guarantee that we’ll follow exactly their footsteps, but automatic keyexchange, the color concept and opportunistic encryption are definitely planned.
Hi! Are you planing to support Gmail’s unique(unfortunately) way to deal with folders aka labels? IMAP is the most used way people get letters. As of now, Kmail treats labels as folders and we have duplicated letters all over the place, each time you’ve read something you need to mark as unread in a few places (label, All Mail, Inbox) instead of one. I know its Google fault but they clearly won’t fix anything, will you solve this problem?
It’s not a high priority item but we’re certainly open to patches. What we’re doing right now is to just limit the available folders so you don’t end up with duplicates but also don’t have support for labels.
have it installed via AUR on Manjaro Linux works realy good for an experimental build
That’s great to hear, happy it works for you =)
How can I donate to this project, specifically Kube? Linux is in dire need of a modern email/calendaring app.
The flatpack for kube is not working.
Warning: Can’t find dependencies: No entry for app/org.kde.kube/x86_64/master in remote summary flatpak cache
Installieren: org.kde.kube/x86_64/master von org.kde.kube-origin
Fehler: No such ref ‘app/org.kde.kube/x86_64/master’ in remote org.kde.kube-origin
Hello I just installed your 0.3.1 version from AUR for manjaro latest KDE 17.0.7 _testing and it took quite a while (about 25 mins compiling, thought it was not running hahah) I feel quite happy telling that it is working perfectly well.. very light, smooth and fast. I actived my “work” Gmail account and connected it immediately..out of the box .. Awesome freaking job!