Transfer engine plugin icon best practices

Applications
#1

Hello all!

When blowing off the dust from my SMS share nemo transfer engine plugin a couple of users reported that the icon of the share plugin list is smaller on my XA2 (and other higher DPI display equipped Sony devices) than expected:

720Ă—1280 121 KB

I am using an SVG file as icon from what I assumed it should be scaled properly (on my JP1 I had no issues with this approach).
I take a look on the built in transferengine plugins with strings and it looks that they using the the icon from the theme system:

mm@lapos:~/Projektek/jolla/harbour-sms-share-plugin$ strings /tmp/libbluetoothshareplugin.so | grep icon
image://theme/icon-s-bluetooth
image://theme/icon-m-share-bluetooth

I also know about @slava 's approach in his QRShare plugin: it generates a PNG icon during the RPM installation phase to match the medium sized icon on the device.

There is also an approach to generate the theme icons used by attah for e.g.:

Would not be easier to fix this issue on the display side? If using SVG icon is supported (it is) then I think it would be pretty easy to render it in the proper resolution.
Unfortunately I do not know where should I look for the relevant QML file.

4 Likes
#2

Actually I managed to find the responsible QML file: it’s in the /usr/lib/qt5/qml/Sailfish/TransferEngine/ShareMethodItem.qml

Patching was be quite easy:

[root@XperiaXA2 TransferEngine]# diff ShareMethodItem.qml_ ShareMethodItem.qml
--- ShareMethodItem.qml_
+++ ShareMethodItem.qml
@@ -10,6 +10,8 @@
         id: icon
 
         x: Theme.horizontalPageMargin
+       width: Theme.iconSizeMedium
+       height: Theme.iconSizeMedium
         anchors.verticalCenter: parent.verticalCenter
         source: model.accountIcon
     }

I would be glad to submit a PR, but as far as I know there is not any proper way to contribute to these sources. Maybe @Venemo could help with this? :wink:

3 Likes
#3

Currently the convention is that the size comes from the images themselves. As you noted in your first post, we have different icons for each possible size, which get rasterized to the correct actual size based on the screen resolution of the device.

The suggested patch might alleviate the problem in this one particular place, but it wouldn’t be a system-wide fix.

I recommend to follow Slava’s approach instead.

#4

The suggested patch might alleviate the problem in this one particular place, but it wouldn’t be a system-wide fix.

I am thinking only about the transfer engine plugin’s icon here, and I do not know any other location where they appear in the system. Having an SVG file for transfer engine icon and setting it’s dimensions here would simplify the plugin developers life. Or having an SVG file for an icon is considered a bad practice?

I recommend to follow Slava’s approach instead.

My problem with Slava’s approach is that would ship unnecessary binaries to the targets (possibly redundantly in the case if this approach would be widespread between transfer plugins builders) just to resize an SVG file.

#5

I understand this is about the transfer engine icons, but the same case could be made about any icon in the OS. I think the place where this is most visible is the app grid.

I will ask my collegaues about how best to approach this.

2 Likes
#6

And talking about contribution, I now created a topic about it.

As said before, even if the changes proposed by the community are not merged, git should be the primary communication channel for these changes. Otherwise they will just get lost.

3 Likes