| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
We'd rather do something via the model index instead of requering an
additional role, but this works for the time being.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
What remains to be done is:
* proper delegates
* removal of recipeients
* at some point d&d of recipients
* Perhaps something that encapsulates the whole list and the model in a
nicer way
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Otherwise we get the following error message:
framework/src/libframeworkplugin.so: undefined reference to `bool QTest::qCompare<int, unsigned int>(int const&, unsigned int const&, char const*, char const*, char const*, int)'
clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)
CCMAIL: Christian Mollekopf <chrigi_1@fastmail.fm>
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Still a bit obnoxious and doesn't really convey a whole lot of
information. Consider it a stub for now
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Seems largely useless now.
The only thing this was planned to be used for is to find the sender of
temporary nodes (which are not linked in the mimetree I suppose),
but that was apparently not yet implemented. Anyways, I think we can
solve this over the parttree.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
While in a much more managable state it's still not pretty.
However, further refactoring can now gradually happen as we need to do
further work on it.
Things that should happen eventually:
* Simplify the logic that creates the messageparts (we don't need the whole formatter plugin complexity)
* Get rid of the nodehelper (let the parts hold the necessary data)
* Get rid of partmetadata (let the part handleit)
|
| |
|
|
|
|
| |
We'll need proper icons though.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Kube.View is a sort of split-view that always only shows a fixed number
of splits (and doesn't support manual resizing).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
...and indicate in the conversation view if a mail has been sent or is a
draft.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To do this we:
* Expose from the model wether or not the model is threaded
* Set the relevant properties from the model on the controller (so we
can switch between aggregate and non-aggregate versions)
* Keep the controller in the view it belongs to.
While this works it highlights a couple of issues:
* Controllers are view specific and should be kept within the view.
* The actions we execute in the controller are closely related to the
model. The model is essentially what the user sees, and therefore what
he operatees on.
* Sink should perhaps expose aggregates better. We have to pass around
the values from the model because the model dispatches between
aggregate and non-aggregate property depending on the threaded state.
Similary the controller operates on the thread or not depending on the
threaded state. Perhaps it would be more useful if sink actually
returned the aggregate somehow, with the regular properties. That way
the controller could use the regular properties from the entity it
gets (which would simply either be the aggregate or non-aggregate
depending on the executed query). If the aggregate already contains
all matched ids, then we would also not have to execute an additional
query to get the thread again, the modification would simply be
applied to all ids originally returned.
|