| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
One problem with the current setting is that j/k is used for scrolling
in the conversation view, but for moving to the next mail in the
maillist view. To normalize this we could be using j/k for moving to the
next conversation instead, and n/p to go to the next/previous mail,
which is also what gmail does.
|
| |
|
|
|
|
|
| |
If nothing else it works as an example how we have to differentiate
between shortcuts and keyboard navigation (one is global to some extent,
the other is only when having focus), and shows that we'll need some
place to consolidate that configuration.
|
| |
|
|
| |
...via syntax highligher or search api.
|
| | |
|
| |
|
|
| |
Marking individual messages as read didn't really feel all that useful.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously mouse interaction was blocked by the mouse area in the
delegate. An additional problem was after that, that the listview lost
focus when the textview got focus which was fixed by introducing a
focus scope and aquiring the currentItem status via activeFocus.
The downside is that the focus stealing of the webengineview now becomes
apparent again, but that can be fixed in qt 5.9.
Otherwise this seems to work as expected now.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The listview deals badly with non uniformly sized items.
We use the buffer hack to ensure all items are loaded so it works at
all, and setting the current index resulted in unpredictable scrolling.
With this new approach we manage everything ourselves in a Flickable,
and just always load all delegates (which we also did before, but with a
hack). As an optimization it should be possible to avoid loading some
delegates until they become visible.
Note that ConversationView is thightly coupled to ConversationListView
due to dependencies on some properties in the delegate. This could be
handled more elegantly with attached properties.
In any case, this seems to work much, much better.
|
| |
|
|
|
| |
This seems to fix that html mails get positioned at the end instead of
the beginning.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Removed the manual currentIndex handling again as we seem to be able to
use the regular stuff now.
Additionally the listview is now resized if we don't have enough mails,
so the first mail is shown on top.
We can also move from mail to mail using keyboard navigation.
The mail highlight also serves as focus indicator for the conversation
view in general, and as such is cleared when loosing focus.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
order
|
| |
|
|
|
|
|
| |
It's still not very usable, but we'll have to find a solution that is
applicable everywhere and perhaps it is just a hardware problem.
Increasing the deceleration just makes scrolling very slow, so that's no
solution either.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
...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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
