icon.library 46.4 test versions

[amigasith]

Originally Posted by gulliver

PeterK, You dont bug us, we feel in constant debt to you, because your work in IconLib is worth a lot for us.

This.

[PeterK]

Update to icon.library 46.4.472:

Ok, this is my last try here to publish a working test version with the Ram Disk icon synchronization to Sys/def_RAM.info in ENV: and ENVARC:. If you know how to use Enforcer or the MuTools, let them run in the background. I don't want to upload a buggy version to Aminet. Icon position and window settings should be restored on all systems now, including DOpus5 and AmiKit. And the Ram Disk ghosting is disabled for ever.

[indigolemon]

Originally Posted by PeterK

Update to icon.library 46.4.472:

Ok, this is my last try here to publish a working test version with the Ram Disk icon synchronization to Sys/def_RAM.info in ENV: and ENVARC:. If you know how to use Enforcer or the MuTools, let them run in the background. I don't want to upload a buggy version to Aminet. Icon position and window settings should be restored on all systems now, including DOpus5 and AmiKit. And the Ram Disk ghosting is disabled for ever.

Working from home again tomorrow so will give this a go and feedback, thanks Peter

[Amiga68k]

Hi Peter, not stumbled into any issues with this version yet I do have a question though.

What is the reasoning behind the 'different approach' of using the version string? I notice that the 3 last digits are part of the lib_IdString, but are missing in the lib_Version value. Output from the shell always displays 46.4 in this case. Or will this be bumped to 46.5 or something when you are happy with the result?

Examples:

6.Ram Disk:> version scsi.device full
scsi.device 43.45 (05/13/2008)
6.Ram Disk:> version exec.library full
exec.library 45.20 (01/06/2002)
6.Ram Disk:> version icon.library full
icon.library 46.4
(68020)

[indigolemon]

Originally Posted by Amiga68k

Hi Peter, not stumbled into any issues with this version yet

This echoes my experience - no errors, warnings, alerts etc here. All seems good at this end after running the system for a few hours this morning.

I'm going to read up on MuForce and will see how i get on there

[PeterK]

Originally Posted by Amiga68k

Hi Peter, not stumbled into any issues with this version yet I do have a question though.

What is the reasoning behind the 'different approach' of using the version string? I notice that the 3 last digits are part of the lib_IdString, but are missing in the lib_Version value. Output from the shell always displays 46.4 in this case. Or will this be bumped to 46.5 or something when you are happy with the result?

Thanks for testing the library, Amiga68k!

What you discovered is a limitation of the Version instruction concerning the version output for libraries and devices. Lib_Version is always the word with the value 46 and lib_Revision the word with the value 4 for my library. There is no definition for a lib_Build or similar in the library structure. So a simple call "Version icon.library" would return 46.4. If you add the option FULL then the version command also looks into the lib_IdString for something in brackets and displays it, which is usually the the date string. But Version would not display the complete lib_IdString, because it's safer to take name, version and revision from ln_Name, lib_Version and lib_Revision. Lib_IdString could be everything like "IconLib forever!". Even so, it's possible to get my full lib_IdString with the Version command because I've inserted the string "$VER:" in front of the lib_IdString. Just read the file with "Version Libs:icon.library FILE FULL" and you will get the complete information including the build number.

Update: The "$VER:" string is only required for some other tools, probably not for the Version command.

@indigolemon
Thanks for your feedback!

[Amiga68k]

Originally Posted by PeterK

Thanks for testing the library, Amiga68k!

What you discovered is a limitation of the Version instruction concerning the version output for libraries and devices. Lib_Version is always the word with the value 46 and lib_Revision the word with the value 4 for my library. There is no definition for a lib_Build or similar in the library structure. So a simple call "Version icon.library" would return 46.4. If you all add the option FULL then the version command also looks into the lib_IdString for something in brackets and displays it, which is usually the the date string. But Version would not display the complete lib_IdString, because it's safer to take name, version and revision from lib_Name, lib_Version and lib_Revision. Lib_IdString could be everything like "IconLib forever!". Even so, it's possible to get my full lib_IdString with the Version command because I've inserted the string "$VER:" in front of the lib_IdString. Just read the file with "Version Libs:icon.library FILE FULL" and you will get the complete information including the build number.

Ah, understood, thanks for the lesson in Version Peter! Do I assume correctly that the value of lib_Revision can only contain one digit then? '4.472' is not possible in this case?

Just tested the output of your example and that works quite alright indeed (it is rather picky though, you have to include 'Libs:' otherwise it complains it cannot find the object).

[PeterK]

Originally Posted by Amiga68k

Do I assume correctly that the value of lib_Revision can only contain one digit then? '4.472' is not possible in this case?

... you have to include 'Libs:' otherwise it complains it cannot find the object).

Yes, lib_Version and lib_Revision are integer numbers (words in assembler) but no pointers to text strings like ln_name or lib_IdString.

The option FILE needs a path to find the object. Without this option the Version command retrieves the data through the exec library list (no path) from the library structure in memory and not from the file on your harddisk.

Update: The "$VER:" string is only required for some other tools, probably not for the Version command.

[PeterK]

The icon.library 46.4.473 has been dumped on Aminet this night.

Aminet - util/libs/IconLib_46.4.lha Wait ...

[dannyp1]

The Aminet posting says it it version 46.4.464? Did you just forget to change that at the top of the post?

Maybe I am still looking at the old listing as I looked at your link above. The new version might not be up yet.

[AMIGASYSTEM]

It will probably be available tomorrow!

[PeterK]

Yes, yes, it takes some hours until Aminet will spit it out ..........

Seems that at least six users didn't know that, because they all downloaded the old version from Aminet instead of being a little patient ......

Coming out now ...

[PeterK]

Update to icon.library 46.4.474:

Reworked the color reduction from TrueColor to 256 colors for the OS4 and PNG icons to achieve a better pseudo dithering. It uses a checkerboard pattern now to mix the colors instead of vertical stripes as before. Alternately the brightness of the pixels is pushed up or pulled down by 2. This method is very simple and fast.

[AMIGASYSTEM]

Thanks Peter

[indigolemon]

Cheers Peter, will give it a shot later on

[Amiga1992]

Peter, crazy question here: I know you release the source to this, and I was wondering: is it possible, you think, to somehow use it, to be able to display icon information, in another way? I mean, not in the workbench.

For example: read a directory and for every .info file found, display the icon in an arbitrary way. I'm thinking of a Blitz Basic implementation.

not sure how possible this is, I am a bit talking out of my league here, but I hope you understand what I mean. I just want to know if it would be possible to display icons in other screens (any screen) as if they were any images!

[PeterK]

Originally Posted by Akira

... is it possible ... read a directory and for every .info file found, display the icon in an arbitrary way. I'm thinking of a Blitz Basic implementation.

I just want to know if it would be possible to display icons in other screens (any screen) as if they were any images!

Yes, that's possible. The details are all explained in the autodocs for icon.library v44+.

After once opening icon.library you could read in the icons with the function GetIconTagList(iconname, taglist) where one of your tags should be ICONGETA_Screen followed by a pointer to your screen structure. Icon.library then remaps the icon to your screen's palette by default (can also be disabled). An extended OS 3.5 DiskObject structure is returned.

In case you just need the planar images of this icon you can get them from the DiskObject structure under do_Gadget.GadgetRender and do_Gadget.SelectRender.

But if you prefer to use the 256 color OS 3.5 chunky images (not mapped to the screen) and the RGB palette then you can call IconControlA(DiskObject, taglist) with the tags ICONCTRLA_GetImage1/2, ICONCTRLA_GetPalette1/2, ICONCTRLA_GetImageMask1/2, ICONCTRLA_GetTransparentColor1/2 and other information. This method gives better quality on Hi/TrueColor screens by using cybergraphics.library and Read/WritePixelArray() (ReadPixelArray trashes dataregister 2 if you don't preserve it!).

[Amiga1992]

What I am thinking of is to take the bitmap data and display them on whatever screen I would open with Blitz Basic (not a Workbench.Intuition screen) . How about that?
In the way one would load any amiga iff image, but pinching the data from the icon instead.

[PeterK]

Originally Posted by Akira

take the bitmap data and display them on whatever screen ...

Yes, do_Gadget.GadgetRender and do_Gadget.SelectRender are image structures with a data pointer to the joined image planes. You can simply create a bitmap structure and append the plane pointers (with their offsets) to that bitmap. If you want to use BltMaskBitMapRastport() to make the icon transparent over the background then call IconControlA() before with a tag ICONCTRLA_GetImageMask1/2.

PS. I'm not sure if ImageMask2 would be available without calling GetImage2 first or using my command NoDelayedImage2. (Only WB is affected)

[Amiga1992]

Amazing, thanks so much Peter!!
I gotta experiment with this