[Lazarus] Component icons howto ?

[Ondrej Pokorny]

On 30.03.2022 09:57, Michael Van Canneyt via lazarus wrote:
> On Wed, 30 Mar 2022, Ondrej Pokorny via lazarus wrote:
>> On 29.03.2022 19:45, Michael Van Canneyt via lazarus wrote:
>>> On Tue, 29 Mar 2022, Werner Pamler wrote:
>>>> 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 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.
>>
>> Forget about the DPI/PPI values. What you need is the %-scaling 
>> factor of the original size.
>
> 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'.

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