| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
i.e. "Unable to assign [undefined] to Sink::ApplicationDomain::Folder::Ptr"
Because qml does not know how to assign a default-constructed value we
have to use conditional bindings. The !! operator checks for
availability of the property which then triggers the binding.
I assume an alternative viable approach would be to expose all
controller properties as QVariants only, in which case an assignment
from null would work (it doesn't for Folder::Ptr).
|
| |
|
|
|
|
|
| |
That way I also don't try to edit outdated invisible components to fix
bugs...
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Summary:
Under certain circumstances, removing the last (or only) remaining account
causes kube to crash.
Steps to reproduce:
1. clear all sink config folders
2. start kube, add a generic IMAP account
3. close kube, reopen kube
4. open accounts list, select "edit"
5. Select "Delete" -> kube crashes
Reviewers: #kube, cmollekopf, aacid
Reviewed By: #kube, cmollekopf
Subscribers: aacid, cmollekopf
Differential Revision: https://phabricator.kde.org/D4517
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Under certain circumstances, removing the last (or only) remaining account
causes kube to crash.
Steps to reproduce:
1. clear all sink config folders
2. start kube, add a generic IMAP account
3. close kube, reopen kube
4. open accounts list, select "edit"
5. Select "Delete" -> kube crashes
Reviewers: #kube, cmollekopf, aacid
Reviewed By: #kube, cmollekopf
Subscribers: aacid, cmollekopf
Differential Revision: https://phabricator.kde.org/D4517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Initialiser lists don't work for member references in gcc 4.8, see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
(This issue is apparently fixed in gcc 4.9, but at least my distro
still ships 4.8 by default.)
This syntax was originally introduced in:
ba7128b30850594c7efb258d1794e377eede364a
Reviewers: #kube, cmollekopf, aacid
Reviewed By: #kube, cmollekopf
Subscribers: aacid
Differential Revision: https://phabricator.kde.org/D4516
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The current settings plugin could potentially be replaced by a proper
controller, but what we have works so that's low priority.
|
|
|
|
|
|
|
|
|
|
| |
The account plugin supplies the configuration UI, the application
supplies the scaffolding. That way we ensure the application doens't
contain any account specific code and account configurations are free to
offer specialized UI's that work best for them.
We're not currently using a standardized controller, but if we did those
controllers would have to live with the plugin, not the framework or the
components.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The binding would occasionally result in temporary changes resulting in
a lot of queries for the conversationview during a sync.
currentItem works a lot better that way is also a generally cleaner
solution.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Summary: s/Krigami/Kirigami/
Reviewers: #kube
Differential Revision: https://phabricator.kde.org/D4450
|
|/
|
|
|
|
|
|
| |
Summary: s/Krigami/Kirigami/
Reviewers: #kube
Differential Revision: https://phabricator.kde.org/D4450
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
That way we can try to only fetch the content for messages that are
actually shown.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
successful drag&drop move
|
|
|
|
| |
The upstream version on of messagelib is too old it seems.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have to trigger the drop explicitly in onReleased.
Interestingly if we use "Drag.dragType: Drag.Automatic" then we don't
need to explicitly call drop() and the drag and drop behaviour works as
expected, but we end up no longer dragging the actual item from the
listview, which is what we wanted to do (although we'll have to deal
with the item reappering in the list only to then vanish from the actual
move).
It seems Drag.Automatic triggers a new style of drag that is now
recommended but entirely undocumented, and we're doing some old-style/
backwardscompatible drag...
|
| |
|
| |
|