icon.library 46.4 test versions

[AMIGASYSTEM]

Originally Posted by PeterK

Edit: Concerning the background, this could also be caused by one of the newer rtg.libraries of P96 v3. I had strange colored backgrounds on AfA_OS with a certain rtg.library version, too.

I had suspected, and now I confirm, restored my old Picasso 96 v2.1b everything is working fine again, now the Glow Icon OS 3.5/3.9 are showing fine and no wallpaper is showing.

Also eliminated some crashes on graphics programs that I did not have before updating the Picasso libraries.

[Torti-the-Smurf]

I have a little question for Peter (or somebody that might know)

How can i get rid of the Transparent that "shines through" the Icon/s ?

(same would happend with the standard Icon.Library)

Is there a way to do get rid of this ?
( and NO , i doesn´t want to get rid of the Copper background )

Anyway, HUGE thanks PETER, this is an essential AMIGA software imho

[PeterK]

It seems that somebody who has created this icon has defined a transparent color and also used it for gray pixels of the image, instead of just for the non-existing transparent background.

EDIT: (sorry my explanation was wrong, I didn't test it, because I was too busy)

You can load this icon with the OS 3.9 IconEdit and then look under the palette of each image. There is a little square which shows the currently transparent color of the palette or a diagonal striped pattern, if no color is actually defined as transparent. In most cases you will find that transparency is enabled for color 0, but not always. Just click into this square to disable transparency (get the striped pattern). You have to repeat the same for the second image.

The other tool which can be used to enable/disable the transparent color is ProcessIcon by Dirk Stoecker, which is also supplied in my IconMixer drawer.

It has two arguments for the transparent colors of both images: ST1 and ST2, which must be set to -1 to get rid of transparency. Not tested:

ProcessIcon <IconName> ST1=-1 ST2=-1

[Torti-the-Smurf]

Great! ; thank you so much for that info AND for the only Icon.Library i would ever use

[AMIGASYSTEM]

Peter what do you think of these new "Folder White" Icons ? (last post)

https://eab.abime.net/showthread.php?t=111421

[PeterK]

Excellent icons, Carlo!

Ok, they don't have the standard yellow orange glow-effect, but your beige brown coloring of the selected icons also looks good and makes it possible to distinguish them clearly from the unselected icons.

Which size do they have? Looks like 64x64, right? Some people may be more interested in 46x46 or 48x48 for their real Amigas.

[AMIGASYSTEM]

The one in the screenshot are 48x47, but I also created 64x62 ones, in this scrennshot there are both sizes

[PeterK]

Oh dear! It seems that I was too blind to realize that some of your icon labels on the screenshot are ending with the suffix "-48". That's caused by my age and my tired eyes, you may know what I mean ...

[AMIGASYSTEM]

Originally Posted by PeterK

Oh dear! It seems that I was too blind to realize that some of your icon labels on the screenshot are ending with the suffix "-48". That's caused by my age and my tired eyes, you may know what I mean ...

It happens to me too 70 years are very close
However, it is not an age problem, even young people suffer from it ... inattention !

[hexaae]

OK, I'm getting old and forgot some fixes and workarounds for our beloved Workbench
Made a new OS39 install and noticed that, even using WBCtrl from Aminet to expand long file names to 100 chars, when I do a Copy (RAMIGA+C) from Workbench the new filename "Copy_of_..." is truncated to 25 chars. I use SFS (SmartFilesystem 1.280 ( 2-Giu-2017)) with 107 chars limit but same happens in ram (I have ram-handler 47.7 ( 8-Gen-2020))
icon.library and workbench.library should be involved I guess...

P.S.
Another good reason to finally upgrade my SYS: to AmigaOS3.2 I'm still procrastinating

[PeterK]

It was you, who once sent me the fixes from Mike for workbench.library and icon.library. One of them was the fix for copying long file names, which was not supported by WB v45.127 of OS 3.9.

So you need a file system with support for long names, WBCTRL MNL=102, a WB v45.131-132 or WB 45.194, and icon.library v45.4, 46.4 - 51.4. That was the reason why my Revision number is always 4, to be compatible to Mike's WB 45.131.

And it still works on OS 3.9 with 51.4.565! No, I didn't introduce a new bug.

[hexaae]

Originally Posted by PeterK

It was you, who once sent me the fixes from Mike for workbench.library and icon.library. One of them was the fix for copying long file names, which was not supported by WB v45.127 of OS 3.9.

So you need a file system with support for long names, WBCTRL MNL=102, a WB v45.131-132 or WB 45.194, and icon.library v45.4, 46.4 - 51.4. That was the reason why my Revision number is always 4, to be compatible to Mike's WB 45.131.

And it still works on OS 3.9 with 51.4.565! No, I didn't introduce a new bug.

Ah! It was that workbench.library 131+ thanks for refreshing my memory

[PeterK]

Btw, OS 3.1.4 has introduced the additional function BumpRevisionLength() for that purpose (copying of long names), which is also included in my library, but not in Mike's v45.4, of course. And the icon.library of 3.1.4+ checks the file system for the supported name length, it won't need WBCTRL or Workbench preferences to set MNL for the copying, but my library still requires this setting, because I don't want to care about file systems.

[Thomas Richter]

But you should. Without taking care of this, you can create a lot of confusion when creating or copying icons to file systems which cannot take the long name correctly. What the Os icon.library does is that it checks after creating a ".info" file whether the file name arrived correctly. You also need to consider this when reading ".info" files, namely that the file you opened is actually an ".info" file, and not a regular file that was erraneously opened by the file system because it truncated parts of ".info" off.

WBCtrl "max file name" is a broken design simply because the Amiga can easily handle multiple file systems with different length limits, and the user can't hardly know what the overall length limit of all file systems is that could be potentially mounted to the system.

[PeterK]

Ok, ok, you are right, and I will be quiet ...
because we've discussed this topic a few times already in all details at A1k.

[PeterK]

Update to icon.library build #566 (no new HAM versions yet):

Fixed a few bugs in the delayed RLE decompression of very large ColorIcons with more than 32 kB image size.

[AMIGASYSTEM]

Thanks Peter for this new version !

If you may be interested it was released "IconClone m68k aros" for icon swapping, it also allows you to go back, also works well with your Icon.library More Apps in the pipeline to manage Icons


http://archives.aros-exec.org/

[PeterK]

Thanks Carlo!

I've tested IconClone, and yes, it works with the Aros 68k icon.library, but it has problems with my library to display OS4 or Aros ARGB icons in the IconClone GUI, although PNG and ColorIcons are appearing correctly. Nevertheless, the image swapping from source to destination and backwards works in all cases.

The question is, how miker tries to retrieve TrueColor images from the icon.library, because my library doesn't support this yet by calling IconControl GetImageData() for ARGB images. It only supports chunky images of ColorIcons, that's why it shows just pixel junk for OS4 and Aros icons. But somehow IconClone gets the PNG images, maybe grabbing them directly out of the PNG icon files and not from icon.library?

[AMIGASYSTEM]

I'm not an expert in this, maybe it would be good if you would talk to miker directly, your presence on Aros-exec I think would be very nice !

[hexaae]

@PeterK
Uhm... Why included "icon.library 46.4.566 (68020)" still has that bug dragging icons we discussed some time ago (thought it was fixed)?


NoDelayedImage2 patch doesn't fix it...

My cfg:
OS3.9
P96 3.3.1 (06.06.22) ©2017-2022 iComp
workbench.library 45.132 ( 8-Set-2012)

EDIT:
Oh, I've just found AROS version fixes it on my non-AROS env