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

Mon, Jan 13

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

Fri, Dec 20

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

Thanks that did the trick.

Fri, Dec 20, 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

Apr 22 2019

wozniak 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 22 2019, 10:27 PM · Kube
wozniak added a comment to T10814: Conversation view navigation helper.

Regarding the mock-up, I feel it's a bit unnatural to add the thread visualisation widget in the e-mail message view. It would work better in the mail list view. Perhaps a git branch visualisation would work better here somehow? Like here:
https://git.occrp.org/libre/property-map/network/master

Apr 22 2019, 10:24 PM · Kube
wozniak 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

Apr 22 2019, 10:17 PM · 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. Would a configuration-file option work and is there a concrete deployment planned that actually requires such an option?

Apr 22 2019, 8:38 PM · Kube
cmollekopf closed T10814: Conversation view navigation helper as Wontfix.

While it is indeed not currently possible to make any sense of the thread structure in the conversation view (given it's just a flat timeline), I'm afraid having a tree view for mails is not among the goals for now. I contemplated having an extra visualization for the tree structure to complement the conversation view at some point, but have no concrete plans to pursue that further at the moment. M31 is an example mockup of such a solution. Something like in that mockup could be a nice addition if you'd like to work on it, but I'll close this ticket for now as the tree-view in the maillist (the center column), is not going to happen.

Apr 22 2019, 8:36 PM · Kube

Apr 18 2019

wozniak created T10814: Conversation view navigation helper.
Apr 18 2019, 9:51 PM · Kube
wozniak created T10813: Global setting to disable HTML.
Apr 18 2019, 9:48 PM · Kube

Apr 2 2019

cmollekopf planned changes to D10895: Add sanitizer support in CMake.
Apr 2 2019, 6:56 AM · Kube
cmollekopf commandeered D10895: Add sanitizer support in CMake.
Apr 2 2019, 6:55 AM · Kube

Mar 13 2019

cmollekopf added a comment to T10599: A better writing expierence.

I like the general direction. It gives a very clean first impression.

Some issues:

  1. affordance There is no indication that is is possible to write something under the subject line. I am afraid some users will try to fit their whole email in the subject field. Then again, once the press "Enter" it should all become clear. Some placeholder text for the body could solve this issue.
Mar 13 2019, 12:03 PM · Kube (0.8)
mbohlender added a comment to T10599: A better writing expierence.

I like the general direction. It gives a very clean first impression.

Mar 13 2019, 10:47 AM · Kube (0.8)

Mar 11 2019

cmollekopf updated the task description for T10599: A better writing expierence.
Mar 11 2019, 9:25 AM · Kube (0.8)
cmollekopf triaged T10599: A better writing expierence as Normal priority.
Mar 11 2019, 9:24 AM · Kube (0.8)