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
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
