KubeProject
ActivePublic

Details

Description

A modern groupware client based on QtQuick and Sink.

The code can be found at: git://anongit.kde.org/kube

The documentation can be found at: http://kube.readthedocs.io/en/latest/

Also, see https://kube-project.com

Recent Activity

May 22 2020

cmollekopf triaged T13189: Qt 5.14 compatibility as Normal priority.
May 22 2020, 1:10 PM · Kube
cmollekopf closed T8577: I guess we need memory hole support now... as Resolved.

We have read-only memory hole support and decrypt messages on sync for local search support.

May 22 2020, 1:05 PM · Kube
cmollekopf closed T7809: It's near impossible to get to the end of the mail list if it is long as Resolved.

Not really a problem in practice, and a solution would be search.

May 22 2020, 1:03 PM · Kube
cmollekopf closed T7740: Simplify delivery and update as Resolved.

We're using flatpak

May 22 2020, 1:02 PM · Kube
cmollekopf moved T9560: Calendar: Support for recurrence exceptions from Backlog to 0.9 on the Kube board.
May 22 2020, 1:01 PM · Kube
cmollekopf moved T9443: Account configuration improvements from Backlog to 0.9 on the Kube board.
May 22 2020, 1:01 PM · Kube
cmollekopf added a comment to T9443: Account configuration improvements.

Also, support configuring starttls in the UI (necessary for some services).

May 22 2020, 1:01 PM · Kube
cmollekopf raised the priority of T8130: Search View UI from Low to Needs Triage.
May 22 2020, 12:58 PM · Kube

May 5 2020

thomasklein added a comment to T13093: Kube: Unread emails / Sorting view.

@mbohlender I've taken the liberty of adding you here. I appreciate you're pretty busy.

May 5 2020, 9:45 AM · Kube
thomasklein created T13093: Kube: Unread emails / Sorting view.
May 5 2020, 9:44 AM · Kube

Apr 4 2020

cmollekopf added a comment to T11104: Spellchecking.

Initial support for syntaxhighlighting based on sonnet is now available.

Apr 4 2020, 6:16 PM · Kube
cmollekopf closed T10813: Global setting to disable HTML as Wontfix.

I'm closing this due to inactivity, feel free to reopen if it becomes relevant again.

Apr 4 2020, 6:11 PM · Kube

Feb 22 2020

cmollekopf closed T7069: resource database uses a lot more space than it actually requires. as Resolved.

The reason was that we had a concurrent read-only transaction so we ended up accumulating a lot of free pages. Fixed in 0dc8aa249d063a3d6eaa248950c57ed5a1709524

Feb 22 2020, 9:31 PM · Sink, Kube

Jan 13 2020

Orage added a watcher for Kube: Orage.
Jan 13 2020, 8:01 PM

Dec 20 2019

cmollekopf closed T12315: Crash with latest kasync master as Resolved.

Thanks that did the trick.

Dec 20 2019, 6:10 PM · KASync, Kube

Dec 19 2019

dvratil added a comment to T12315: Crash with latest kasync master.

OK, I have reverted the commit in master now. Sink tests pass again.

Dec 19 2019, 1:38 PM · KASync, Kube
cmollekopf added a comment to T12315: Crash with latest kasync master.

To be honest I think it makes most sense to revert back to default constructing T for the time being.

Dec 19 2019, 9:30 AM · KASync, Kube

Dec 18 2019

dvratil added a comment to T12315: Crash with latest kasync master.

There's no easy way how to fix this without reverting back to default-constructing T in Future<T>::Future().

Dec 18 2019, 1:30 PM · KASync, Kube
dvratil added a comment to T12315: Crash with latest kasync master.

It's not exactly the lifetime- it's a more deep-rooted issue with error handling.

Dec 18 2019, 9:58 AM · KASync, Kube

Dec 17 2019

cmollekopf added a comment to T12315: Crash with latest kasync master.

Generally, I'm wondering if I should deprecate this API and introduce a promise-future based API, where, instead of being passed a future from KAsync, the continuation would construct a Promise object internally a return a Future that KAsync would wait for....internally the continuation would own the Promise - it's closer to the common promise-future pattern and solves the lifetime issue, since the Promise is owned by the continuation, rather than by KAsync (which only holds the Future).

Dec 17 2019, 3:48 PM · KASync, Kube
cmollekopf added a comment to T12315: Crash with latest kasync master.

Hmm, I believe the bug might be in the Sink code. Here specifically, it's ResourceControl::flush():

The function registers two callbacks, both operating on the future reference. When the resource crashes (happens to me, I don't know if it's part of th etest), then sendFlushCommand fails, so future.setError is called (line 111). However, around the same time a notification is received with information about the crashed resource, invoking the lambda passed to registerHandler function, which then also calls future.setError() (line 98) - depending on which happens first, the future is finished at that point and completes the execution, which may delete the Future object, leaving the other lambda with a dangling reference....

Dec 17 2019, 3:42 PM · KASync, Kube
dvratil added a comment to T12315: Crash with latest kasync master.

Generally, I'm wondering if I should deprecate this API and introduce a promise-future based API, where, instead of being passed a future from KAsync, the continuation would construct a Promise object internally a return a Future that KAsync would wait for....internally the continuation would own the Promise - it's closer to the common promise-future pattern and solves the lifetime issue, since the Promise is owned by the continuation, rather than by KAsync (which only holds the Future).

Dec 17 2019, 2:39 PM · KASync, Kube
dvratil added a comment to T12315: Crash with latest kasync master.

I can probably solve the life-time of the future, however you are still calling setError twice on it, which should be undefined behavior - or, following what std::future does, would, well, not throw (because Qt), but might as well assert.

Dec 17 2019, 2:36 PM · KASync, Kube
dvratil added a comment to T12315: Crash with latest kasync master.

Hmm, I believe the bug might be in the Sink code. Here specifically, it's ResourceControl::flush():

Dec 17 2019, 2:34 PM · KASync, Kube

Dec 15 2019

cmollekopf added a comment to T12315: Crash with latest kasync master.

tests/notificationtest in sink will produce a similar crash.

Dec 15 2019, 4:23 PM · KASync, Kube

Dec 13 2019

cmollekopf added a comment to T12315: Crash with latest kasync master.

I have rebuilt the flatpak completely and can reproduce the crash. Also, I can reproduce the crash outside of the flatpak again, not sure what I did above.

Dec 13 2019, 1:16 PM · KASync, Kube

Dec 9 2019

cmollekopf added a comment to T12315: Crash with latest kasync master.

Ever since I have rebuilt a with -fsanitize=address I can no longer reproduce outside of the flatpak, so there's a chance that the fault is with flatpaks internal build chaching that somehow results in something that crashes (I can't think of a reasonable scenario, but who knows).
I'll try to completely rebuild the flatpak as well and see if this fixes the issue.

Dec 9 2019, 9:27 AM · KASync, Kube

Dec 6 2019

cmollekopf added a comment to T12315: Crash with latest kasync master.

Nothing very obvious from the address sanitizer so far, but I also haven't managed to run kube with it yet (only sinksh).

Dec 6 2019, 8:17 PM · KASync, Kube
cmollekopf added a comment to T12315: Crash with latest kasync master.

I'll try that. Next week is fine, no hurry.

Dec 6 2019, 12:29 PM · KASync, Kube
dvratil added a comment to T12315: Crash with latest kasync master.

Looks like some memory issue...could you try compiling with -fsanitize=address? I won't get to look into it properly before some time next week, sorry.

Dec 6 2019, 10:54 AM · KASync, Kube

Dec 4 2019

cmollekopf added a comment to T12315: Crash with latest kasync master.

FWIW; I have attempted but failed to reproduce this in a kasync testcase. I can reproduce it by starting latest kube with latest sink and latest kasync, and I can reproduce the crash in both flatpak (which I have now reverted to kasync 0.3.0), and a locally built kube.

Dec 4 2019, 9:25 AM · KASync, Kube

Dec 3 2019

cmollekopf created T12315: Crash with latest kasync master.
Dec 3 2019, 2:36 PM · KASync, Kube

Sep 1 2019

cmollekopf triaged T11483: Improve account status handling as Normal priority.
Sep 1 2019, 7:55 PM · Sink, Kube

Aug 29 2019

cmollekopf closed T10599: A better writing expierence, a subtask of T6384: A better text editor for the composer, as Resolved.
Aug 29 2019, 9:31 AM · Kube

Jun 27 2019

cmollekopf added a comment to T1821: Folder subscriptions.

See the calendar for a model how this could be implemented.

Jun 27 2019, 9:34 AM · Kube
cmollekopf triaged T11150: Background sync, single application support as Normal priority.
Jun 27 2019, 9:34 AM · Kube

Jun 26 2019

tristanlins added a watcher for Kube: tristanlins.
Jun 26 2019, 9:58 AM

Jun 16 2019

cmollekopf closed T8894: Windows: Xapian crashes immediately, a subtask of T1478: Build on windows., as Resolved.
Jun 16 2019, 9:57 AM · Kube
cmollekopf closed T8894: Windows: Xapian crashes immediately as Resolved.
Jun 16 2019, 9:57 AM · Kube
cmollekopf added a comment to T8894: Windows: Xapian crashes immediately.

https://github.com/xapian/xapian/pull/256

Jun 16 2019, 9:56 AM · Kube
cmollekopf triaged T11104: Spellchecking as Normal priority.
Jun 16 2019, 9:39 AM · Kube

Jun 8 2019

bcooksley changed the edit policy for Kube.
Jun 8 2019, 9:04 PM
cmollekopf added a comment to T8894: Windows: Xapian crashes immediately.

I managed to get rid of this crash with a patch to xapian (https://github.com/cmollekopf/xapian-core/commit/6061b69c4b2f6b9d310558df1b285b5125364de8) that I have yet to upstream (don't know if they'd accept it since it seems like a compiler bug).

Jun 8 2019, 11:01 AM · Kube
cmollekopf closed T8897: Windows: QVector<QPoint> crash as Resolved.
Jun 8 2019, 10:59 AM · Kube
cmollekopf closed T8897: Windows: QVector<QPoint> crash, a subtask of T1478: Build on windows., as Resolved.
Jun 8 2019, 10:59 AM · Kube

May 20 2019

cmollekopf closed T8134: Build failure on windows, a subtask of T1478: Build on windows., as Resolved.
May 20 2019, 9:38 AM · Kube

Apr 23 2019

cmollekopf added a comment to T10813: Global setting to disable HTML.

By the way, I had some (not a lot) experience with QML so if I were to be pointed in the right direction, I *might* be able to submit a patch for this.

Apr 23 2019, 7:18 AM · Kube
cmollekopf added a comment to T10813: Global setting to disable HTML.

This would be relatively simple to add, but I wouldn't want to have that as an option in the UI

I think it would be *nice* to have it in the UI, but I understand the reasons you might not want it. The reason it would be nice is that on support calls it's easier to tell the user to toggle an UI option, than to mess with a config file.

On the other hand, config-file-only option means users would be less likely to disable it themselves. So I can live with that!

Apr 23 2019, 7:12 AM · Kube
cmollekopf renamed T10814: Conversation view navigation helper from Tree/threaded e-mail list view to Conversation view navigation helper.
Apr 23 2019, 6:54 AM · Kube
cmollekopf reopened T10814: Conversation view navigation helper as "Open".

Git branch visualizations were indeed a major inspiration =)
Where we'd put it exactly is indeed up for debate, I think it would in either case have to be in a location that remains available as you scroll down the conversation.

Apr 23 2019, 6:48 AM · Kube