Hi,

2 questions :

1. What is the current procedure for registering a component ?

I see there are 3 icons for every standard component: mycomponent, mycomponent_150 and mycomponent_200

How does the IDE pick which image it needs ?

As a corollary: what's with the strange names ?
Why not use the size of the icon in the name, that would be a lot clearer IMHO?

I looked in the WIKI but could not find any relevant info.

2. I would like to create icons for some new dataset descendents. The icons for the well-known datasets all have a text on it. Where can I find the icon without a text on it ?

Michael.

Michael Van Canneyt wrote

?? I see there are 3 icons for every standard component: ?? mycomponent, mycomponent_150 and mycomponent_200 ?? How does the IDE pick which image it needs ?

The basic image name must match the component name (including the "T"). The image without an appendix is used for standard resolution (96 ppi, 100%), the image with appendix "_150" is used for 144 ppi (150%), and the image with appendix "_200" is used for 192 ppi (200%)

?? As a corollary: what's with the strange names ? ?? Why not use the size of the icon in the name, that would be a lot clearer IMHO?

That's the way it was decided. One advantage is that when images are needed for other purposes, but at different sizes (e.g. the icons in the message window which are much smaller) the scaling procedure can still be the same

?? I looked in the WIKI but could not find any relevant info.

https://wiki.lazarus.freepascal.org/How_To_Write_Lazarus_Component#Step_3%3A_Create_icons_for_the_package

There is also a short chapter in the Lazarus Handbook vol 2, page 717.

2. I would like to create icons for some new dataset descendents. ?? The icons for the well-known datasets all have a text on it. ?? Where can I find the icon without a text on it ?

Roland Hahn, who designed most of the new icons, recommends to paint the images in svg format (using InkScape for example). For there you can export the required images in any size as png. He does create three differently sized svg images for fine-tuning, but in my own work I usually draw only one size, e.g 36x36.

You can find the svg source files from which all (well - most) of our images are created on CCR (folder "image_sources"). The TDbf database icons, for example, are located in
(ccr)/image_sources/lazarus/components/tdbf etc (like in the IDE folder). From there you can delete or edit the text overlays.

So you must always register the three images.

Not sure I follow the logic ?

Hehe, the history shows you sneaked in the different sizes today. I checked only last week, so I was pretty sure the info was outdated ;-)

Many thanks !

There is also a short chapter in the Lazarus Handbook vol 2, page 717.

I must be getting old. I edited this book myself :-(

OK, I will look at the SVG files. It didn't occur to me I can remove the text. Or possibly simply change it to what I need.

Thank you very much !

Michael.

Michael Van Canneyt wrote

So you must always register the three images.

You are not forced to. But when you provide only the standard size and run the IDE at 200% the IDE will upscale the 24x24 image to double size, and the icon will become blurry - just as it was in the days before Ondrej implemented all these scaling functions. (BTW: a long time before Delphi which seems to support High-Dpi only now in the recent release).

I don't know the actual procedure names ATM, but imagine that when the message window needs a "warning" icon (which is - say - 12x12 at 96ppi) then the scaling procedure at 192ppi only needs to look for "warning_200.png". If the exact image size would have been included in the file name instead ("warning_24x24.png"), it would have to know the size of the base image at 96ppi in order to select the right image. A little simplification.

I had written this part of the wiki already in 2018, so it definitely was not outdated. I just noticed that it was missing some basic requirements (like component name = image name) and decided to rewrite the paragraph.

OK, I will look at the SVG files. It didn't occur to me I can remove the text. Or possibly simply change it to what I need.

I am attaching the three "database" png images extracted from the TDbf svgs without the text, in case you have problems with InkScape (which definitely will not win the prize of the most user-friendly software). -------------- next part --------------
A non-text attachment was scrubbed...
Name: database-icon.png
Type: image/png
Size: 876 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220329/ab95210d/attachment.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: database-icon_150.png
Type: image/png
Size: 1595 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220329/ab95210d/attachment-0001.png> -------------- next part --------------
A non-text attachment was scrubbed...
Name: database-icon_200.png
Type: image/png
Size: 1464 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220329/ab95210d/attachment-0002.png>

OK, thank you.

I fail to see the link between 192 and 200. This requires people to know that 96dpi and 144 dpi and 192 dpi are 100, 150 and 200 % of a standard size.

For me - and I've been in IT for quite some time now - this is far from obvious that this should result in 24x24, 36x36 and 48x48 icon sizes.

In short: I think this is a horribly contorted scheme.

All other systems I came across simply use icon dimensions in the name. Far simpler and hence preferable in my opinion.

the 3 sizes were not mentioned when last I looked ?

Well, I managed to get something working with Inkscape. I already committed TJSONDataset.
(for which, strangely enough, there was already an image)

Thank you for all explanations.

Michael.

Forget about the DPI/PPI values. What you need is the %-scaling factor of the original size.

For me - and I've been in IT for quite some time now - this is far from obvious that this should result in 24x24, 36x36 and 48x48 icon sizes.

What?

100% => 24px - that is the usual and recommended size for component palette icons at 100% scaling - e.g. Delphi uses the same size for the component icons. Take it as a starting point.
150% => 24px * 150 / 100 = 36px
200% => 24px * 200 / 100 = 48px

That should be obvious for everybody who knows basic math :)

In short: I think this is a horribly contorted scheme. All other systems I came across simply use icon dimensions in the name. Far simpler and hence preferable in my opinion.

I don't think so. Let me explain:

1.) One reason is legacy&compatibility. Before the High-DPI stuff, all the IDE icons did not have the size in the name. Having the icon size in px in the name would require a bigger rewrite of Lazarus code than it was necessary for the scaling-postfixes and without any gain (see [2] below).

There are various places where icons with different sizes are used: tool bars (16px), code editor (11px), component palette (24px). All these icons did not have the size in the name originally.

2.) The second reason and the main advantage is that Lazarus doesn't [need to] know what size of the icon is supplied at a specific scaling (even at 100%). The icon sizes are not strictly defined.

The file naming convention is: the original variants (at 100%) do not have a postfix, the scaled variants have a postfix with the scaling factor in % based on the original icon => you open Lazarus on a screen with 150% scaling, Lazarus automatically picks up the icons with "_150" postfix. If not found, it scales the original ones automatically. Easy.

Having the size in the file name means that every function that requests an icon would have to know the resulting px-size it looks for. That is not wanted due to:

2.a) Rounding problems: do you round 11*150%=16.5 to 16px or 17px? You would have to consider the same rounding both in the Lazarus code and in the graphics editor. Currently only the graphics editor decides about the best size of the scaled icon and Lazarus can cope with the undefined icon size.

2.b) unwanted fixed icon size: there can be icons at 100% with 16px and at 200% with 30px, if the graphics designer decided so. Lazarus will take the 30px icons without any issues.

Or, if somebody now decides that the 11px code editor icons need a redesign and the new icons will have a base size of 12px instead of 11px, there is no need to change anything in the code. Lazarus will cope with the new size of the icons unless the new size is a complete nonsense.

Ondrej

Why do you think I know this is a scaling factor ?

I didn't have a clue until Werner explained.

Sorry, you can argue all you like, but if I see a list of icon files xyz_24x24.png then I know *exactly* what to create, just from the filenames. No need to do math, open file whatnot.

With your method, I need to open the file (unless I know standard size is 24), check the size, and then possibly multiply (if I know that the suffix is the scaling factor in %).

As it was, I actually opened 3 files to see what the needed sizes were.

By contrast, if I need to create icons for a Linux app I check e.g:

ls /usr/share/icons/gnome/

128x128/ 16x16/ 22x22/ 24x24/ 256x256/ 32x32/ 48x48/ 512x512/ 64x64/ 8x8/ icon-theme.cache index.theme scalable/

and I know exactly what to create, just from the names.

If you think that your method is easier, we have very different concepts of what is 'easy'.

Clearly, I would not be asking these questions if it was so obvious.

Michael.

Den 30.03.2022 09:57, skreiv Michael Van Canneyt via lazarus:

I would guess that naming the files 'xyz_24x24.png' (base size 24px), 'xyz_24x24_150.png' (150% 36px) and 'xyz_24x24_200.png' (200% 48px) could be a reasonable naming solution?

As I said: 150, 200 do not strike me as scalings in percent.

That the CPU needs to do an extra couple of cycles (convert scaling to pixel) to make things easier on humans - that's why mankind invented it.

Forgive me, but I will discontinue the discussion.

I think I made it clear what I think is (in my view) absurd and have no wish to antagonize anyone by continuing to argue for something which should be obvious and plain.

Michael.

Well, the difference is the point-of-view and not the concept. My point-of-view is the Lazarus IDE developer. Yours is the user. Mine is easier from the Lazarus development POV, yours is from the user's POV.

Clearly, I would not be asking these questions if it was so obvious.

Once you get to know what the postfixes mean, I think it is obvious. I agree that it is not obvious per se and having the size in the file name is more obvious and easier for the user. Having said that, both methods would have to be documented, so after reading the docs both methods should be equally clear and easy.

When I worked at the high-DPI Lazarus IDE, I picked up the more obvious and easier way for the Lazarus IDE development.

I mainly didn't want to bother with these questions about legacy icons: what do you do with the icons "abc.png" (11x11px) and "def.png" (16x16px) - do you rename them[?], what do you do with 3rd party IDE extensions and packages that supply such icons and Lazarus doesn't have control over them etc etc? With the "_150" and "_200" I did not have to solve these issues. With yours I did have to solve them indeed.

I am not saying your concept is wrong, I just try to explain the reasoning about the concept with scaling postfixes.

Of course all the issues above exist just due to the fact that the IDE uses different icon sizes and to keep things simple I decided to have the same naming convention for both IDE icons and component icons.

---

I am not against extending the component icon loading to handle a different file name convention. As Delphi uses the same concept that you prefer https://blogs.embarcadero.com/new-in-10-2-2-component-icons/ , if the Lazarus code should be extended then definitely to support the Delphi way:

RCDATA TLabel32_PNG "tlabel32.png"

The resource name is the component class name plus the px-value postfix (16, 24, 32, ...) and "_PNG" in case of a png file.

Yes, I am absolutely OK with it as an alternative naming convention for the component palette because we probably do not want to give up the current naming convention due to the effort needed for renaming all the files and due to legacy compatibility. But if others agree and somebody is willing to take the maintenance effort, we could also deprecate the current naming convention and remove it in the 2nd-to-come stable version.

Lazarus had the High-DPI support before Delphi so there was no chance for us to know what Delphi would eventually choose, so having the Delphi-convention as an alternative was inevitable anyway.

---

I am not sure about the IDE icons, though - due to the issues regarding different icon sizes. But if you have a solution for these issues, you can definitely implement it as well.

Ondrej

Arne Hanssen wrote

I would guess that naming the files 'xyz_24x24.png' (base size 24px), 'xyz_24x24_150.png' (150% 36px) and 'xyz_24x24_200.png' (200% 48px) could be a reasonable naming solution?

On the contrary: it is the bad from both naming solutions :)

You need to know both the scaling factor and the size.

Ondrej

Not convinced that this offers a significant advantage. The component writer has to consider so many differences to Delphi anyway, so I would not care about a different icon naming convention. I am against deprecating the old naming scheme because we would have to rename thousands of icons (and their svg source files).

Rather than that, I think the effort should be put into support of svg images.

I don't think anybody took this personal - definitely not myself. But I still don't know what you intended with the discussion. The naming convention has been like this for 5 years - I introduced it in this commit
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/2135d3058f078e3df8b957c4fa4e52e1fa1ae83b

We now tried to explain the reasoning behind it - I honestly did not care that much about the naming convention back then: I just took what was the simplest way from my POV - simplest to extend the existing code and the existing directory and file structure. I concentrated much more on the scaling system behind it as it was quite a monster of a change. I do admit that I did not think about the icon creators on the other side at all - so I missed what you see is "obvious and plain". Sorry for that but what should I do with it now?

If somebody (including you) had raised the discussion about the (not obvious) naming back then before hundreds of icons were added, it would have been a much easier change than today. But there was no such discussion (no alternative was either suggested or rejected), so we ended up with the solution that I picked up. There were no bad intentions from my side, I just decided somehow and nobody has complained about it for 5 years. That's all about it.

I now cannot do a lot about a 5-year-old decision. Yes, it may have been wrong, but I am not going to rename all the files added in the meantime by myself...

Yes, we can still extend the code to support Delphi's naming convention. But as Werner stated before, we won't rename current icons ourselves. If you want to take the effort because you think it is worth it and Werner is not against, go for it. I personally don't think it is worth it.

In the end it's just about file names, the result is the same: the user sees pixel-perfect icons and the IDE scales nicely. A different naming convention won't improve that.

Ondrej