summaryrefslogtreecommitdiffstats
path: root/framework/qml/MailListView.qml
Commit message (Collapse)AuthorAge
* change wrapMode to WordWrapMichael Bohlender2017-06-29
|
* do not hardcode fontPointsizeMichael Bohlender2017-06-29
|
* hide date on hover so the buttons can shineMichael Bohlender2017-04-26
|
* Made the maillistview a focus scopeChristian Mollekopf2017-04-26
| | | | and automatically select an index an aquiring focus
* introduce icon button, use it in maillistviewMichael Bohlender2017-04-26
|
* Keyboard focus for toolbar and folder listChristian Mollekopf2017-04-25
|
* Show mail delegate buttons on hoverChristian Mollekopf2017-04-24
| | | | Currently hides the date, so that will need fixing.
* Ported more actions to the fabricChristian Mollekopf2017-04-24
|
* Use the fabric to wire up searchChristian Mollekopf2017-04-24
|
* Added the Fabric as an in application message busChristian Mollekopf2017-04-24
|
* remove toolbar and move enable the buttons in the mailListDelegateMichael Bohlender2017-04-21
|
* add dummy button to maillist delegateMichael Bohlender2017-04-21
|
* Fixed enabling of actionsChristian Mollekopf2017-04-20
|
* use kube.label in maillistview and center nothing-here messageMichael Bohlender2017-04-19
|
* remove filter bar, allow filter through the global searchMichael Bohlender2017-04-17
|
* Don't thread drafts and sentChristian Mollekopf2017-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Only show relevant toolbuttons in the maillist viewChristian Mollekopf2017-04-13
|
* A single framework pluginChristian Mollekopf2017-04-05
|
* One framework plugin to rule them allChristian Mollekopf2017-04-04