does not know how to scale SVG (or QT ?) icon? - (was: Albert icon - too large)

[dreamcat4]

@fossfreedom thank you for participating in previous discussions. Over in the other issue tracker.

This problem was originally discovered with the tray icon for the albert launcher. Which is both a QT app, and an SVG icon. Because the albert Icon does not seem to be special in any way, then we can expect a similar issue might be reproducible with other programs which use a similar Icon formatting.

Perhaps something to set / ocnstrain the icon's displayed size, is already in your code here somewhere? For example I can see this line trys to set the size of a GTKImage, to be 22 pixels:

https://github.com/UbuntuBudgie/budgie-indicator-applet/blob/master/src/applet-main.c#L300

Which is intererting.

But for whatever reason(s), this does not work for the albert SVG icon. Not sure why. I am also not sure if the problem is because of QT or SVG image type.

But the developer of albert launcher (Manuel) also found a different solution for the time being. Which was to set the following environment variable:

QT_SCALE_FACTOR=1 albert

Which works in the meantime. Until the problem can be better understood / fixed.

Manuel also suggested to try the other program "CopyQ". Because it was also a QT program. However I do not know if the "CopyQ" tray icon is SVG too. I have not tried this yet.

======================

My system information:

Display: 1080p (not retina)

Platform :

$ sudo lsb_release  -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic

$ budgie-desktop --version
budgie-desktop 10.4
Copyright © 2014-2017 Budgie Desktop Developers

[dreamcat4]

The related issues in other trackers:

albertlauncher/albert#700

solus-project/budgie-desktop#1539

(It's all same issue).

[fossfreedom]

The icon being presented to the appindicator is not a .svg. if it was then it would be scaled.

Qt is converting the .svg to an image that is scaled twice as large as usual. Hence why you are using a scale factor.

This isn't an appindicator applet issue that can be dealt with here and I can't scale wrongly sized images.

[dreamcat4]

The icon being presented to the appindicator is not a .svg. if it was then it would be scaled.

Sorry I don't understand properly. Because if the icon being passed is not an svg, then it's already converted into a bitmap, right? Well don't you also scale for the bitmapped icon images too? Otherwise how can other PNG icons displayed properly, at the correct size? To also fit inside the height of the appindicator tray?

Qt is converting the .svg to an image that is scaled twice as large as usual. Hence why you are using a scale factor.

OK I went back to examine my earlier screenshot --> https://imgur.com/a/a5vITIM

We can see the icon is not conveniently 2x as large as the other icons. It is much larger. I have now counted the size (approximate). And it is about 180x180 px. More or less.

Sorry I also don't understand why setting the QT scale factor variable works. And indeed - perhaps it is due to some bug in QT. When the scale factor is otherwise not set to a specific value. And then QT is left to it's own devices, and does not know what it should do.

However the problem with saying QT should fix:

Well the QT project has over 23k open bugs. As in: 23,000. So the whole idea / assumption that QT project will be fixing this problem is.... not likely. More like 0, or probably very close to 0.

Another thing I don't understand:

Does this applet know the height of the panel, in pixels? To constrain / draw the sizes of each icon, to fit correctly? Or does it never actually know what the heigh should be. And just leaves it up to Budgie desktop / WM, for the parent panel which this applet is added to / displayed in?

[fossfreedom]

Correct - QT is converting the icon to a bitmap of some-sort.

No - we don't scale bitmaps - we follow the appindicator spec which is simply icons should conform to the 22px sizing. A specification is something programmers are expected to adhere to - it is classed as an error if otherwise.
The fact that QT is buggy is not a reason for me to try and code around another toolkits issues. The QT spec itself says its icons default to 22px in size for panel icons. It clearly isnt. I'm not going myself try and figure out why QT is buggy - I'll leave that to those that have a particular interest here.

The budgie panel doesn't care what is drawn inside it - why should it? It is an error if applets mess up drawing stuff. The appindicator applet is basically a container ... the drawing part is left to the applications themselves. So applications are expected to behave sanely.

[fossfreedom]

Think its worth still playing in this area still - its worth testing if the image being sent has a pixbuf ... and then try to scale the image

Something like this Lafydev/wingpanel-indicator-ayatana@2afef40

How this works with indicators that change its icon I don't know ... but worth trying at some-point anyway.

Code to be fiddled with is here https://github.com/UbuntuBudgie/budgie-indicator-applet/blob/master/src/applet-main.c#L337

As always - pull-requests always welcome

[dreamcat4]

How this works with indicators that change its icon I don't know ... but worth trying at some-point anyway

the "Portmaster" tray utility is a good example of this. They use a go library that calls down to libappindicator. Thing is they change the icon while running to swap it dynamically for different status colors. And pass some pointer to binary image (png or bitmap whatever it is)

So something I don't really like is they should use SVG but instead they went the route of 'really large image'. Expecting it to scale down smaller by somebody else (you guys it would seem here). And then that is harder to find the solution for. Because well... they keep changing the icon all the time!

Here is link to other issue.

safing/portmaster-ui#111 (comment)

I have been all around the internet yesterday and seeing many times different issues around icon sizing. All over linux desktop generally speaking I would say it's the failure of the underlying APIs. If the rules were more stringent then it would not let room or ways for application developers to make mistakes. At least not without noticing :)

The historical evolution of things over many years. Before we had all this more modern software ontop. Really had no idea it was such a mess down there.

Building houses on sand.. and not all of the houses all sits straight. Some are straight. But on others places the floor can be wonky. And tilting at random different angles :)

And no, I have no idea how to fix this :)

[dreamcat4]

Code to be fiddled with is here https://github.com/UbuntuBudgie/budgie-indicator-applet/blob/master/src/applet-main.c#L337

As always - pull-requests always welcome

OK so on this line:

budgie-indicator-applet/src/applet-main.c

Line 339 in 332887b

gtk_image_set_pixel_size(entry->image, current_icon_size);

the code tries to set the icon size blindly... you are correct it does not work for other image types. So then the question is: why are we doing this operation blindly?

Before deciding how to handle the GTKImage object, we should be querying for it's GTKImageType, yes? Is this correct?

https://developer.gnome.org/gtk3/stable/GtkImage.html#GtkImageType

Then based on whether it's Type A, B, or C should choose the appropriate action to take. I think the question what to do for certain more difficult types is an open question. Clearly other DEs works, so what are the other guys doing here? Are they re-creating a new object again? And then making a new copy of the image into a brand new Object?

Sorry but this GUI stuff is not my area of expertise. So I really do not know the answers to these types of questions.

Like also - I really don't know what the Portsmaster developer does when they swap the icons over too. If that triggers a new GUI update event. Or it's something else IDK. But clearly the animated icons, + these swapping of icons are the 2 worst situation to be dealing with

[fossfreedom]

The code is the same on Mate. Its already an image type so no need to check. Setting the pixel value works (mostly) for SVGs - so as long as the image is a valid SVG, it will work.

Checking the .pixbuf property on the image is enough to confirm if its a .png/jpg etc - i.e. if not null then its a pixbuf. Then it can be potentially scaled.

As you say - if the image changes - what happens? Dunno - guessing there is a notify::changed type event or similar to check and if changed then run through another scaling routine.

As to the portsmaster issue of 512px - if its constantly changing - scaling is very inefficient - taking resources/battery etc. So its much better and cleaner if implementers ensure their tray icons are a valid size first.

[dreamcat4]

The code is the same on Mate

Perhaps if know... there is also 1 other DE has same bug as Budgie. If it is Cinammon or MATE i cannot remember which one. Or maybe it's same one IDK. But I cannot find back the issue comment right now. There were so many issues all over the place with these tray bugs

The code is the same on Mate. Its already an image type so no need to check

sorry but i just don't understand this. Because the code I pointed to only ever checks there is an object of type GTKImage. It does not check what is inside the GTKImage object before trying to manipulate it.

[fossfreedom]

Under Gtk you dont need not worry too much. The function in question is a suggested size. Gtk itself doesnt resize via the function if it decides it cant ... usually because it's a pixbuf type image that doesnt autoresize ... you have to manually resize pixbufs

[fossfreedom]

@dreamcat4 I think the above commit resolves this issue. Please do give this a try and let me know how you get on. Cheers

[dreamcat4]

thanks so much! Looking forwards to it

[dreamcat4]

@fossfreedom hey there. just compiled and installed it... works fantastic thank you. Really appreciated, very happy about this. Should be released into official apt sources