In D28208#634593, @davidre wrote:

Do you know if IconThemePath is specified somewhere?

Initial commit:
https://github.com/KDE/kde-workspace/commit/4c553dbf39f4189290387bba35589200ca051084
Someone mentioned this property here:
https://lists.freedesktop.org/archives/xdg/2015-December/013620.html
https://mail.kde.org/pipermail/plasma-devel/2015-December/047019.html
But he tried to create new specification. What we need is to update existing one to reflect all the changes...

Some of the icons are not rendering now, for example:
Discord - iconName: chrome_app_indicator2_83406baa15c6e4f2766a6e3714fbee20
Skype1 - iconName: chrome_app_indicator2_01cdeaaa54803d9c9c158a5cdcb1fbfb
I'm pretty sure I saw a workaround for that somewhere, but I can't recall where...

Found it! You need to handle IconThemePath, which can be difficult... :/

Two problems:

In D28180#632058, @ngraham wrote:

This works, but I wonder if there's a conceptually cleaner way to do it. Not that I know of one, so I'll wait for a Plasma person to comment.

Yes, this code looks smelly, but I don't have better idea now.

In D28183#632057, @davidedmundson wrote:

That won't work as is because I would need to re-run

const KFileItem fileItem = lister->findByUrl(destUrl);

I knew there had to be a catch, it would be too easy...

Rebase

Rebase

Simplify JS

In D28185#631972, @apol wrote:

I'm not convinced this is all that better.

Without this effectiveStatus never changes. Right now it works by happy coincidence - Item is simple destroyed and created in a different, as a side effect new value of effectiveStatus is used.
This change tries to fix my mistake introduced in D26992. I used QML Loader incorrectly... :(
Anyway, I changed it a little bin, please check now.

Bind model as well

In D28183#631966, @davidedmundson wrote:

The failure was always on this line:

QCOMPARE(fileItem.targetUrl(), QUrl::fromLocalFile(destFilePath));

In theory QTRY_VERIFY should wait up to 5 seconds until condition is met. qWait(250) shouldn't change much...

In D28107#630144, @davidre wrote:

It seems it is possible to do this (removing stuff from the data engine) after all. I will try to work on this in the next time

In D28109#629974, @ngraham wrote:

This looks like a sensible refactor to me, and it solves the issue that I was having with icon size changing based on the expanded popup visibility. I can't detect any regressions in sizing with horizontal or vertical panels of various sizes. However please wait to land this until somebody else possessing greater familiarity with this codebase such as @broulik, @mart, or @davidedmundson reviews it too.

Yep, icons in SNI are a mess...
Icons are processed in StatusNotifierItemSource, including overlay - that's were this should be fixed. From you comment I see it won't be easy...
This is a workaround, it works, but makes the code even more messy.

Oh you're right. It was not wokring for me on 5.18 so I changed this and it worked. But matter of fact it worked on master all allong :)

5.18 is not using this data model, in 5.18 it is used only in configuration page. In 5.19 this model is everywhere.

The qml checks the value against the enum but updateItemData inserts the string.

In D27958#627658, @ngraham wrote:

After a few days of living with it, I've found that this patch causes the following issue with semi-random tray items getting smaller when a pop-up is opened:

Could you investigate?

In D27958#625431, @broulik wrote:

Not sure if it is just me but the vertical alignment looks slightly off

Or maybe that's the random different sizes

Fix for narrow panel in D27958

I don't like how icon size and item size (container = icon + padding) are calculated and used... Firstly best icons size is calculated, but then padding are added. This combined size is used as item size (container size):

• SNI icons are rounded to nearest icon size (implicitly, because PlasmaCore.IconItem is used)
• Plasmoids are scaled to the size of the container, I don't know exactly how it work, probably because default compact representation is just an icon.

By happy coincident it is (?) working correctly for all sizes.

In D27466#624574, @broulik wrote:

I believe that D26992, moves the icons down.

It looks like with that patch the icon sizes differ between plasmoids and SNIs

In D27466#624447, @broulik wrote:

This causes layouting issues in narrow panels:

The icons are also too far apart

Should System Tray icons be larger then?

In D27466#620470, @gvgeo wrote:

IMO this is the wrong way to do these changes.

1. I don't see "itemSize" to be used anywhere else(didn't check) than "tasksRow" where we already add a smallSpacing. It would be best to increase the size in one place.
2. For tablets already allow to use bigger size icons. There is no need to artificially increase the size this way, if they need bigger size can increase the panel height.
3. Can expose plasmoid.configuration.iconSize to the user. Otherwise can be removed.

In D26992#614426, @ngraham wrote:

UI looks good except for one thing: the changes to show a highlight effect on hover in the popup are unrelated and should be done in a separate patch (preferably in coordination with VDG folks since we're moving towards the idea of using this in other places too).

Second (and last) change extracted from this one is in master. Rebased, ready for review.

Review fixes

There is already a margin added around icons, "units.smallSpacing / 2" if I remember correctly.
IMO it is OK without additional spacing (maybe because I'm used to it?). Anyway, VDG should decide what is the best and what is consistent with other elements of Plasma.

OK, I will wait for second review from @davidedmundson, @broulik or @mart.

Rebase, only D27088 left

Rebase

Updated the code. This time I was not event able to reproduce race condition. Is something like this OK?

It is hard to reproduce, but with enough tries you should get empty items in "hidden" area of system tray. I used this script:

for i in `seq 1 100`; do
        echo $i
        telegram-desktop &
        sleep 2
        killall telegram-desktop
done

Extracted from D26992 to make review easier

... and second one: D27088. It contains model refactoring and sorting.

First revision: D27085. In contains some random improvements

Unrelated changes extracted from D26992 to make review easier

I will split it into smaller changes, this one is too big for a review. I'll keep it here as a backup.

Rebase2

Rebase

I definitely need to split D26992 into smaller chunks :) I had it fixed, but obviously D26992 can't be merged for 5.18.

This change is very big. I can try to split in into two (maybe more) if that's required. If yes, should I connect revisions somehow? Create task, add parent/child revision?