@jensreuterberg thinks the current buttons are obvious enough. I am undecided. No need to change anything atm.

The current solution seems sufficient. closing for now.

This has now been improved with resources defaulting to no status instead of offline. That way we can reserve offline for resources that actually can't connected to the server which allows the aggregation to ignore those resources.

So that would mean that if your email provider doesn't allow sending with other FROM addresses with the same transport then we just deem that setup broken, and otherwise everything works as it should.

One drawback of setting up different accounts when you really want to use multiple mail-accounts through one is that the sent mail ends up in the accounts sent folder, which means it will also only show up there in the conversation.

I introduced a Kube.Scrollbar component. We need to style it anyways if we want a consistent look.

Most old people I know tend to scroll by clicking on scrollbars and dragging them. They don't know about scroll wheels nor scroll gestures.

Solved for now using a recursive filtering using a krecursivefilterproxymodel

Subscribed folders in an unsubscribed parent are currently hidden. We could either solve this at at the QAbstractItemModel level, implementing recursive filtering on top (This feature will only be available directly in QSortFilterProxyModel from qt 5.10 on), or we could implement it in sink (this is non trivial due to the way we recursively query for trees).

Non-subscribed folders are now hidden.

I have now replaced the use of ListView with a custom Flickable based solution that seems to work much better.
Paired with the messageparsing now running in a separate thread this results in almost decent behavior (it's still a bit slow)

The scrollbars currently overlay the content, so not hiding them will require further changes. Personally I don't think it's worth it.

I can not reproduce it anymore

Works for me.

I can't reproduce this, is this still valid? If it is, please post a backtrace.

FWIW, mailinglists are a case where just chaning the reply-to address likely doesn't suffice (the email will be bounced for subscribers only lists I think).

I prototyped a solution consisting of:

• SelectableItem: can be "attached" to a layout containing labels
• SelectableLabel; a label that can be copied

Initial Kube.PasswordField is in.

I'm not quite sure yet how to implement this technically, and it might depend a lot on how it is visualized. If we want to paint a border or overlay we will need a visual item in qml, otherwise we might not necessarily need that.

So we would make all copyable elements focusable/selectable and popup a menu that would contain "copy" + possibly other options?
That could work as well.

An idea for email addresses in the mailview:
click on address -> get "popup" with options:
copy to clipboard / add to addressbook / write email to

In T6518#104141, @mbohlender wrote:

depending on how the logview turns out, we might want a single "copy this error message" button

depending on how the logview turns out, we might want a single "copy this error message" button

In T6518#104138, @cmollekopf wrote:

I have pushed an experimental SelectableLabel that I used in the LogView only. It simply sports an IconButton that copies the text of the label.
With a couple of labels that's perhaps not ideal (but might still be good enough for now).

Alternatives could be:

• One button that copies all fields together

physical address is a case where this would make sense.

I have pushed an experimental SelectableLabel that I used in the LogView only. It simply sports an IconButton that copies the text of the label.
With a couple of labels that's perhaps not ideal (but might still be good enough for now).

Christian, [27.07.17 14:40]
So, to conclude: We'll have multiple identities per account consiting of:

• email address
• name
• signature
• gpg-key in the future

This is largely resolved by now I think. I don't have webengine 5.9 available yet, so the webview still keeps stealing the focus, but keyboard navigation and focus highlighting is quite usable by now.

In T6556#102545, @mbohlender wrote:

In T6556#102540, @cmollekopf wrote:

what about Flow Layouts?

If we need keyboard navigation at least regular flow layout won't cut it, that's why I switched to the grid layout for the peopleview.
We could of course implement it, but I'll avoid that as long as possible (that doesn't mean we cant use them at all, in small flow layouts
you can just tab through the individual items, it just means the flow layout doesn't really matter for focus).

We "need" a flow layot for email attachmetns in the mail viewer.

In T6556#102540, @cmollekopf wrote:

what about Flow Layouts?

If we need keyboard navigation at least regular flow layout won't cut it, that's why I switched to the grid layout for the peopleview.
We could of course implement it, but I'll avoid that as long as possible (that doesn't mean we cant use them at all, in small flow layouts
you can just tab through the individual items, it just means the flow layout doesn't really matter for focus).

In T6556#102543, @cmollekopf wrote:

I thought about that but I'm not sure if it is a good idea or generally applicable. It would mean that you have to switch sufficiently fast (A delay of at least 1s would be necessary, perhaps longer?), and i.e. in the case of wanting to get to your latest mail (or if the list is empty, any mail), you would always have that extra delay that is somehow not explained to the user... Perhaps worth an experiment, but I'd like to go with explicit selecting for now.

I thought about that but I'm not sure if it is a good idea or generally applicable. It would mean that you have to switch sufficiently fast (A delay of at least 1s would be necessary, perhaps longer?), and i.e. in the case of wanting to get to your latest mail (or if the list is empty, any mail), you would always have that extra delay that is somehow not explained to the user... Perhaps worth an experiment, but I'd like to go with explicit selecting for now.

we could trigger the sync with a delay

In T6556#102528, @mbohlender wrote:

I wonder I we can get away with keyboadfocus = selected element

In T6556#102522, @mbohlender wrote:

The following indicators are available to visualize selection:
Highlight: A blue overlay over the item.

We could be color agnostic here.

I wonder I we can get away with keyboadfocus = selected element

The following indicators are available to visualize selection:
Highlight: A blue overlay over the item.

We could be color agnostic here.

Glow: A blue glow around the borders.

glow might be the wrong word. currently it is just a colored frame and I'd like to keep it that way.

Underlined text
It is important that a selected element can still show focus, otherwise the focus during keyboard navigation simply disappears if it moves to the selected element.

Next steps are:

• Either let the KDE translation process happen or follow this: https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Systems#Handling_i18n_outside_KDE.27s_repositories
• https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Systems#Qt5-only:_Code_using_Qt_translation_system

We also have a Messages.sh file by now.

I'm no longer witnessing this problem, but it might be because the scrollbar is hidden by default.

Fedora 27, due on 2017-10-24 is going to be qt 5.9. Everything before is qt 5.7 I think. Note that at least qtwebengine 5.9 is already available on fedora 25 for security patches (I don't know if all other features are available).

I think the natural alternative for touch would be long press, which selects the element and pops up a little context menu with the copy option.

on hover does not work with touch

The example can be found here:
https://gitorious.org/qt-components/qt-components?p=qt-components:qt-components.git;a=blob_plain;f=src/meego/Label.qml;hb=HEAD