After a waaaaaay to long “break” I have finally tagged another release.
The largest change in this release is the addition of the calendar view, which is not only useful, but also marks an important milestone in our development roadmap; We finally have all the pieces together from a technology perspective.
The calendar was a major undertaking due to a couple of challenges:
- It’s synchronized over its own protocol (CalDAV)
- It’s for once not a list, so it’s visually a completely different beast than everything else.
- It has lots of fun special cases such as recurring events, timezones, overlapping events, multiday vs. single day events, …
- We wanted to avoid loading your complete calendar (including the past 10 years) into memory, while making sure you get recurring events displayed even if they started 10 years ago.
The work done so far solves most of the important challenges, but there are also definitely a couple of holes in it still, such as no drag and drop support.
While the calendar is certainly the biggest new feature, there’s also a bunch of other improvements in there:
- A new editor view, providing a much cleaner look than what we used to have.
- Basic support for scheduling via iTip (both for sending an invitation to attendees, and for interacting with invitations you have recieved).
- Autodiscovery support for CalDAV and CardDAV servers (So https://example.com instead of https://caldav.example.com/calendars/user@example.com/ is enough to configure your account).
- Builds and runs on MacOS and Windows (it admittedly is not getting a lot of testing on those platforms, especially on Windows, but the baseline is there).
- A fastmail account configuration dialog.
- It’s now possible to create and modify contacts.
- We no longer default to displaying HTML email
- … and a bunch of other stuff in a little over 226 commits to sink and 561 commits to kube.
Tarballs
Tarballs are available at the usual locations:
- http://download.kde.org/unstable/kube/0.8.0/src/kube-0.8.0.tar.xz.mirrorlist
- http://download.kde.org/unstable/sink/0.8.0/src/sink-0.8.0.tar.xz.mirrorlist
Get It!
Of course the release is already outdated, so you may want to try a flatpak or some distro provided package instead:
https://kube.kde.org/getit.html
“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
Finding New Ways... 
Great work, thank you! Can’t wait to see a 1.0 release of Kube. 🙂
Hey!
error: Can’t load uri https://files.kube-project.com/flatpak/com.kubeproject.kube.flatpakref: Server returned status 404: Not Found
😦
Sorry about that, should be back now.
Is this project under the “KDE’s umbrella”? KDEPIM seems almost abandoned, many bug reports and feature sugestions dont even get replies from developers, and the worst of all is that the same bugs and deficiencies present 4 or 5 years ago still persist.
Kube looks great, fortunately away from that old fashioned Breeze widgets theme that look so 2000-ish, looks much cleaner and uncluttered. But a nice and contemporary design, no matter how much can make the experience pleasant and thus the work session less stressing and more productive and motivational, isn’t the most important part, obviously. Things need to be functional and complete, finished, something that many often lacks in FLOSS projects, that seem to be unfinished for decades.
Those “meditations” are to explain my point of view: Since KDEPIM seems bogged down at a no way out road but Kube still seems too “unfinished” (I know that a software program is never really “finished”, it’s always a work in progress, but you know what I mean), are you, the Kube developers, in the “KDE house” so may be you could get help from other KDE developers, wishfully from the KDEPIM team? Or, if not, have you considered it? Maybe that if you would enter KDE some developers from the KDEPIM team, that seem overwhelmed and unmotivated might join or at least help you, and with the help of his experience perhaps Kube would reach a “finished” state that made it usable by the general public soon and finish the Kmail & co, especially the Akonadi nightmare, something of the past?
I’m just speculating, obviously, but you know, it’s, sadly, so common in the FLOSS ecosystem to have several projects that are supposed to satisfy the same needs and none of them is really complete and satisfying the majority of users’ needs…
I know nobody can force the developers to join efforts and talents and work together in one or two, at most, projects with the same purpose and goals, that would kill the liberty of libre software, of course, but don’t the developers feel sometimes that there should be some kind of agreement and common goals for the community, including you as users, sake?
I know many developers would like to have more robust applications, and more complete, with more features, and I cant understand why there isn’t a bit more of cooperation and fusions of several small isolated projects into less projects but bigger, better and much better maintained. Being into the “KDE state” won’t help (in case you are not already)?
Well, thank you, anyway for your work, and excuse if I have said many nonsense, I don’t know the interiorities of software development nor of KDE as organization nor Kube.
Hi Joan,
It’s not nonsense and it’s a very common sentiment.
The short answer is:
Yes it’s developed under the KDE development umbrella, but it doesn’t necessarily therefore also strife to be primarily a KDE integrated client (more a works everywhere piece of software that is hopefully eventually also integrated in various places). Joining forces is of course generally desirable, but usually we end up with separate projects for reasons (most of which seem at least at the time good).
So I don’t think it would be easy to just join forces as many of the existing reasons why we have multiple projects in the first place still apply.
On the plus side, it’s much easier to move fast if you can have focus and don’t have to cater to all existing usecases simultaneously.