Oke by me. Commit lands in a few minutes.

I would prefer if someone else ships it on your behalf, my setup is rather broken.
If nobody does it, i will somewhere next weekend.

Ship it :)

Looks good to me. Nice :)

Looks OK to me.
Wait for a second accept though.

It pains me a bit to say this since it looks like you've spend quite a bit of time writing that code.
But please do look at KIO::iconNameForUrl [1] (like also suggested by Kai on reviewboard). Much of the code can likely be replaced by just using that instead.

:)

Fine by me :)

Imho, it looks a lot better! Nice job!
Don't push it just yet though. Wait for the VDG to chime in.

I'm just curious. Why is the day name determined in QML (in the lines you edited, but was there before as well) and on the C++ side?
It smells like a redundancy.

Hmm, i don't know about the performance penalty you get when using KConfig...
It "looks" ok, but that's without knowing the above.

Fancy!
I learned something new, thank you :)

I really doubt the usefulness in supporting this "feature".
It smalls like something one distribution apparently wants, but the vast majority is fine with having the hover effect there. In fact, they might even consider it a bug - i would - if it doesn't change on hover.

In D4491#88362, @anthonyfieroni wrote:

I must investigate why elide does not work, margins are a bit different from others like systray, kicker, etc.
I figure out it, maximumLineCount or height sould be setted, i unsetted height...
maximumLineCount should be 1 or more? Elided should be left if application is RightToLeft ? Also margins to abobt to others ?

So now i'm on the correct revision it seems.

In D3738#87617, @subdiff wrote:

In D3738#87601, @markg wrote:

...

There has already been a commit to master tackling this issue: https://phabricator.kde.org/D4491

Hmm, i don't know if this is the appropriate way in a phabricator workflow. But this does reach exactly those involved in this change which is what i intent.

In D4439#83310, @aacid wrote:

In D4439#83166, @dfaure wrote:

It's not crazy, but

• then it should use QVector instead of QList (Client is a "big" struct, bigger than a pointer)

The problem with QVector is that it doesn't have erase(iterator) built in like QList has.

• I would be worried about copies happening unexpectedly (can this code compile with forbidden copy ctor for Client? I guess not as is due to insertion into the vector.... but maybe std::move can be used there, or simply setting the members directly onto a ref for vector[i]).

Without the copy constructor there's quite a lot of things that don't work. OTOH all the data in Client is basiclaly POD, but i guess at some point it could be "a lot of copying", if you think it's worth it i can investigate some "less Q and more C++11-y stuff" and see if std::move or something works

Hmm, this is exactly the reason why i always go for either smart pointers or stack objects. Both prevent this issue from occurring in the first place.

Looks good to me.

Hi David,

Ahh, now it's gone.

Looks nice and clean to me now :)
Nice job!