icon.library 46.4 test versions

[hexaae]

Unfortunately many Amiga devs didn't ever release sources… SwazInfo sources for example would have been very useful. It's a pity for such a good program… I've seen recently on Aminet some upload by Amiga Program Preservation Society (or something like that) with the noble scope to upload lost sources for great software to be continued in case...

[kolla]

That is true, the problem with most open source on Amiga is that sources have been released in an afterthought, after original author have decided to quit, so there is no transfer of knowledge and understanding of the code.

Anyways, it should be perfectly possible to make something new. From what I understand, patching WBInfo() is trivial, it's really making the GUI and making sure it treats icons correctly that is the big task.

[AMIGASYSTEM]

Originally Posted by hexaae

P.S:
That Batman icon was generated with PPaint.

Why do so much effort when they can create IconDual PNG super compatible in a simple way, i attach the The Batman DualPNG icon made in a few seconds.

-------- Italiano ------

Perchè fare tanta fatica quandosi possono creare delle IconDual PNG super compatible in maniera semplice, allego icona The Batman DualPNG fatta in pochi secondi

[PeterK]

Originally Posted by hexaae

What's your problem with bugs? You take it too bad They do exists, as well as betatester figures to find them (usually appreciated by devs as they do the dirty and annoying part of the work while devs can focus on development).
Important thing is to fix them (at least those harmful, hopefully) when found.
... I'm here to help us all having better software in the end, not to blame anyone, don't get me wrong when I report bugs

Forget it, that was just a short outbreak of emotions, no serious criticism against your bug reports. Feedback is always welcome.

yep, must be a bug of Processicon because I just saved a brush PNG 256 colors from PPaint, and loaded the image through IconEdit. Then saved it as single image icon from IconEdit, and Processicon still reports the same wrong 2nd image data (??), so it's not a bug in pio_icon save format for PPaint and the icon is not buggy/corrupt.

Yes, there seems to be a bug in ProcessIcon, all the data of the non-existing 2. image was wrong.

Nevertheless, it could be possible that the Batman icon structure is also incorrect somewhere, but it would need more time to examine that in details. That's why I felt sooo happy with that bug. I've never seen before that RAWBInfo just deletes a CI image. It could be caused by my library by rejecting some data or by RAWBInfo internally complaining about something. But RAWBInfo did not even throw an Enforcer hit. So what exactly is going wrong here? Usually, the tools written by Stephan Rupprecht are working pretty good, but nobody is perfect. He has coded CopyIcon and RAWBInfo and Dirk Stoecker has written ProcessIcon.

PS. This Batman icon has only 1 image, the second image is a darker copy of the 1. image generated by icon.library. I think it's the best to start with checking my internal darkerPalMapCopy routine for possible bugs now.

Update: darkerPalMapCopy seems to be ok, IconEdit has never problems with it and RAWBInfo also works with other icons with 1 image only and uses darkerPalMapCopy too. But ProcessIcon never uses it and thus it gets an error code back when asking for the number of colors of the non-existing 2. image, but it seems to ignore that error code. I'm not in the mood to dig any deeper in the mud tonight. Btw, with icon.library 45.1 RAWBInfo reports "bad number" for the Batman icon.

[daxb]

Originally Posted by PeterK

Usually, the tools written by Stephan Rupprecht are working pretty good, but nobody is perfect. He has coded CopyIcon, RAWBInfo and ProcessIcon.

If you mean this: http://aminet.net/package/util/wb/ProcessIcon then it is from Dirk Stoecker.

[PeterK]

Originally Posted by daxb

http://aminet.net/package/util/wb/ProcessIcon ... is from Dirk Stoecker.

Yes, that's right. Thanks for correcting my mistake, daxb

Btw, the PNG TrueColor mode also works now, but saving PNG icons still has to be done.

[TjLaZer]

Anyone know why when using one of the hacked Classic WB installs, this icon.library does not work? Only works on normal WB 3.1 or 3.9 installs.

[PeterK]

What do you mean by hacked CWB ?
CWB supports my icon.library since v27. You have to look into the menu for an entry to enable icon.library. I don't have CWB installed anymore for many years already and can't remember what exactly to do. But you can not install newer versions of icon.library like on OS 3.1 or OS 3.9. I think the concept of CWB is a bit old now, not saying outdated.

[TjLaZer]

hacked = the normal Classic WB installs. Sorry. They seem to do some pretty bizzare wizardly behind the scenes and your icon.library does not want to work. I guess I need to try the latest update.

[PeterK]

It also depends on the version of CWB. There is no support before v27. And there are differences between CWB ADVSP, the only one I know, and other compilations of CWB. ADVSP works with Scalos 1.2d and it was very tricky to integrate icon.library into the iconobject system of Scalos. Bloodwych has written very special scripts to enable or disable the icon.library support and you can very easily brake this concept by overwriting some of his files. Then nothing will work anymore. I've no idea whether it's possible to update CWB with newer versions of my library or not, since I didn't try it in the last 5-7 years at least. And I never heard anything from Bloodwych anymore. Is he still active?

[TjLaZer]

ok I see there is a v28 on there and it's working. Got it setup on WinUAE! Now I have to figure out how to move it to my A600. There are no update packs. I will try to mimic his installer script.

[AMIGASYSTEM]

You could write the Hardfile of WinUAE on HD/CF, or mount HD/CF on WinUAE and install the new ClassicWB

[kolla]

All those evil ">NIL:" that means you won't have a clue about whether it fails or not :/

[PeterK]

Update to icon.library 46.4.491:

The new TrueColor version TC020 is finished and also supports PNG icons now. Just one small problem with RAWBInfo that I want to mention is that drag&drop into RAWBInfo creates only ColorIcons, although it really saves TrueColor icons if you don't swap the images. Maybe it needs some API extensions or a v50 icon.library like on AfA where drag&drop works too. Nevertheless, you can still use CopyIcon or the OS 3.9 WBInfo for swapping TrueColor images, no problem. Please report any other issues.

[kolla]

Originally Posted by PeterK

Maybe it needs some API extensions or a v50 icon.library like on AfA where drag&drop works too.

Have you tried to see what happens if you just version your lib v50?

How does icon.library know what format to use? If you replace a planar icon by dropping a png onto wbinfo for example, will it then use OS4 format, or PNG format, for the saved icon? Does it perhaps ask the user? Just curious, haven't had time to play around with it yet

Thanks for all the great work!

[PeterK]

Yes, I've just tested an hour ago with a faked v52 version number, but that trick didn't fool RAWBInfo. Seems I need to analyze its function calls precisely.

The TrueColor images from OS4 and PNG icons are stored as compressed zlib images in the internal OS 3.5 DiskObject extension, invisible for other programs. When a program wants to write the supposed ColorIcon back to disk then the internal data is checked for possible zlib images, whether they are OS4 ARGB or PNG and the corresponding file format is created. RAWBInfo must remove the zlib images by internal copying or something similar. This still needs some investigation. My library has no API functions for accessing TrueColor images, because they are not hold uncompressed in memory like on other systems.

Some benchmark results:

icon.library TC020:    RAM    SSD    AfA:  RAM    SSD     OS 3.9:  RAM    SSD
OS 3.5 CrystalIcons   0,188  1,690        0,620  7,962            4,847  6,759
PNG Kens Icons v4     0,953  2,760        0,931  4,040
OS4 Mason 2010        1,201  2,328        0,958  12,804
OS4 Reworked3         1,535  3,051        1,264  15,127

[PeterK]

The icon.library 46.4.492 with the new TC020 is available at Aminet:
http://aminet.net/package/util/libs/IconLib_46.4

The problems with drag&drop icons into the RAWBInfo window are solved now. RAWBInfo displays and saves the images in TrueColor as it should after writing a tricky and complicated work around for it. Maybe this could also be useful for other programs which are also just copying the chunky image data of the OS 3.5 ColorIcon format from one icon to the other.

Btw, I noticed a very strange effect with the internal Icon Info window of DOpus4. Usually DOpus4 can only handle ColorIcons too, but now with TC020 this changes as soon as you once have started DOpus5. You can even close DOpus5 again, but something magic makes it possible that DOpus4 also displays icons in TrueColor in its Icon Info window after that has happened. It could be very useful to find out what exactly in DOpus5 causes DOpus4 suddenly to change its mind about its capabilities to display icons.

[daxb]

Maybe because of icon.module/icon.library loading by DOpus5? Or using show.module for icons? There is also a UseWBInfo variable if set it use WBInfo() instead of icon.module. Maybe DOpus4 takes over something or a patch is responsible. Gives SnoopDos some info?

[PeterK]

Originally Posted by daxb

There is also a UseWBInfo variable if set it use WBInfo() instead of icon.module.

Where is that "UseWBInfo" ?

I've disabled all DOpus5 modules, and the trick still works as long as I don't disable the filetype.module ... and the register.module, of course. I can also remove all filetype definitions and delete ENV:Dopus/ before I start DOpus4, but it still shows icons in TrueColor. Couldn't see anything interesting in SnoopDos yet.

After starting DOpus5 once with the filetype.module and closing it again I've disabled all DOLAUNCHER patches in Scout, then used "Avail FLUSH" twice, which removes dopus5.library and all the modules from memory before I finally started DOpus4, and the trick still works.

[daxb]

If you have set the variable then it should be in ENVARCOpus/ where all the others are. You may want to use this: http://aminet.net/package/util/dopus/Do5extPrefs16