icon.library 46.4 test versions

[mfilos]

Ofc it does. PowerIcons has usage ONLY on RTG systems as AfAOS does.

[Bamiga2002]

Originally Posted by tolkien

Damn it! I have used 280 version and now it works perfectly. I guess I had samething wrong in that moment.
Thanks so much for all and keep the good work.

Maybe you had zlib.library in LIBS-drawer, confusing things. Whic leads me to a question: does it interfere with the new icon.library to have zlib.library installed normally in LIBS-drawer or does one have to rename it?

[daxb]

Answer yourself. If you rename zlib.library it won`t used by programs (not only icon.library use it). I guess new icon.library just don`t use zlib.library.

[PeterK]

There is no need to remove zlib.library from the LIBS: directory. It can still be used from other apps but won't be loaded by the icon.library since 46.4.280 anymore. There are no conflicts possible with the embedded zlib function.

[JohnFante]

I have replaced AFA with Powericons and have a problem. I am not sure if this is related to the icons.library.

Before I installed PowerIcons I had the problem that one of my icons on my desktop did not stay in the same place, where I have snapped it to, after a reboot.

With PowerIcons a lot of my icons dosn't stay in the right place.



They are ment to be placed on two rows. Glow icons in one row and PNG in another.

In OS4.1 Classic they stay in the right place

Any suggestions to a fix.

[PeterK]

Please upload some of these icons that don't want to appear at the correct (snapped) position and tell me approximately where they should come up (x, y offset of the screen or window or post an OS4 screenshot). Did you get the requester asking you if you would like to convert PNG icons into the OS 3.5 format ?

Is there any difference when you don't use the PowerIcons program but only my icon.library ?
Are these icons really PNG icons or are they OS4 ARGB icons ?

[JohnFante]

Originally Posted by PeterK

Please upload some of these icons that don't want to appear at the correct (snapped) position and tell me approximately where they should come up (x, y offset of the screen or window or post an OS4 screenshot). Did you get the requester asking you if you would like to convert PNG icons into the OS 3.5 format ?

Is there any difference when you don't use the PowerIcons program but only my icon.library ?
Are these icons really PNG icons or are they OS4 ARGB icons ?

The OS4.1 and the Work icons are standard 4.1 Classic icons. I thought they were PNG but apparently not

When I sorted and snapped the icons - using PowerIcons - along the left side of the screen (standard sorting of the icons) they stay put except for the RAM icon. When I use AFA or nothing the RAM icons is placed in the top left corner as it should. Not perfectly alligned but almost. Maybe it was just me messing around to much with snapping the icons in 3.9 and 4.1.

You can see the result of PowerIcons here:

[PeterK]

The RAM icon is one of the default icons which is loaded from ENV:sys/def_RAM.info. So, just move your RAM icon to the position where you like it, fix it with snapshot and then open a shell and execute:

Copy RAM:disk.info ENVARC:sys/def_RAM.info

In case you won't use DefIcons, but you do , then you would need a line in your startup-sequene:
Copy >NIL: ENVARC:Sys/Def_RAM.info RAM:disk.info

[JohnFante]

Originally Posted by PeterK

The RAM icon is one of the default icons which is loaded from ENV:sys/def_RAM.info. So, just move your RAM icon to the position where you like it, fix it with snapshot and then open a shell and execute:

Copy RAM:disk.info ENVARC:sys/def_RAM.info

In case you won't use DefIcons, but you do , then you would need a line in your startup-sequene:
Copy >NIL: ENVARC:Sys/Def_RAM.info RAM:disk.info

Thank you :-)

After a couple of tries it did the trick :-)

[PeterK]

Update to icon.library 46.4.281 (see 1. post)

Icon.library has made another hop on the way to a better zlib decompression: the size is now down to 30000 bytes again, although there is still a lot of code to optimize.

Unfortunately, I just noticed that the two latest versions 46.4.280/281 don't work with my IconDemoADF. There seems to be a memory problem as far as I could see in the source code up to now.

[mfilos]

Awesome as always Peter my friend!
Works really well

[tolkien]

Thanks. Will test tomorrow.

[PeterK]

Update to icon.library 46.4.282

46.4.280 and 281 are buggy, don't use them, they are trashing chipmem. Fixed now.

[mfilos]

Cheers for the fast update mate.
I thought that the chip trashing was my idea @ first but after your post everything settled
Just tried opening bunch of PNG icons and everything's fine with the Chip

[PeterK]

Originally Posted by mfilos

I thought that the chip trashing was my idea @ first but ...

Hi mfilos,
I always appreciate all your tests and your feedback and comments. Thanks a lot! But... please don't hesitate to tell me about any issues that could be caused by hidden bugs. Nobody reported this problem, and not even the Enforcer complained about it, everything seemed to work just fine...until I tested it with my IconDemoADF environment. And that crashed badly with heavy gfx corruptions. This thread is really there for reporting bugs, too, not only making compliments. If all looks stable then I will do another Aminet release. Thanks again.

Just a little idea…

PeterK's new icon.library is really something. It seems to work flawlessly on all my Amigas in ECS, AGA and RTG. And it is fast. Thank you for this great piece of programming!

But there is one little feature that I think would make it even better. I would really like to see an option for rendering the icons in grayscale, instead of color.

Let me explain why: Full color icons are all good and well in 16 or 24-bits RTG screen modes. But on ECA and AGA (especially if you want to keep the Workbench responsive), things are not as good. A good alternative could be to render the icons in grayscale as it would not need so many pens. As it is now the icons look somewhat ugly on OCS/ECS/AGA. This is because the color-mapping most of the time will be bad on a 4 or 5-bit Workbench (16/32 colors). But with grayscale, you only need 8 to 16 shades of gray (not 50 ) to make a good representation by locking pens with tools like “FullPalette”. As things are now you can always lock all colors to shades of gray (I have done that on my A3000), but then the whole Workbench will have to be in gray (or the icons will use some of the colors which is not gray). And it would be nice to have a few colorful pens available to the rest of the system. With more than 16 colors (AGA) even the mouse pointer has to be set to gray in this case.

For me, and I think for many of us, the Workbench has historically been about low-color. To get the right "old Amiga feeling" this would be really cool.

What do you think of such an option, PeterK? Wouldn't that also make the icon rendering even faster, as you can discard color information in some cases?

[daxb]

A 16 color WB with 8 gray scales could be look good. The first 4 system colors have alread something like black and white + 8 gray scaled + 4 other user colors (e.g. mwb). But what about other programs that use for example gfx buttons. They might don`t look good? I guess it is a general problem with low color and a fixed palette.

[PeterK]

@ClarkKent71
Well, of course it's possible to make grayscale icons available with an option. I've just tried that in two minutes with a small modification to the code, so you can tell me if this is what you are looking for or not. I cannot change the planar images or icons to grayscale because they don't have a palette. And I cannot avoid that the colormapping will sometimes take one of the "true" colors from the screens palette if that color is closer to the requested gray value than any of the screens gray shades.

Updated attachment at the next post.

[mfilos]

This is what it looks like with 46.4.283 (Greyscale)




and this is the default normal 46.4.282




Both screenshots from my A600 @ 8 colors (MWB palette)

[PeterK]

@ClarkKent71
Just made an update to the grayscale calculation. It's now equal-weighted for the three color components RGB, 33% for each of them. Red was overweighted before, because I didn't want to use an extra DIVU instruction. Maybe, I will find a better solution later and a way to make gray an option.

@mfilos
My dear friend, please use the thumbnail previews for the attached images. Thanks.