icon.library 46.4 test versions

[PeterK]

Carlo, I think that this is the new file type identification of the OS 3.2 DefIcons program v47, which did not exist before in OS 3.9 or 3.1.4. Edit: It could also be a new feature of RAWBInfo v47, which may use DefIcons v47 now for the file type identification.

Are there any differences between my icon.library and the v45 versions on 3.9 or 3.1.4? I will check that soon again ...

OS 3.2 is something else than 3.9 and it has new features in DefIcons v47, but they should be supported by my library.

The old RAWBInfo (and the new one too) cannot read the type from PNG icon files directly (they cannot handle that format), but RAWBInfo v47 may get the type string from DefIcons v47 now.

[PeterK]

There's a small problem with the DOpus5 iconclock.module in #555, because it calls DupDiskObject() with a self-made icon structure without a valid "DiskMagic" signature ($E310) as the first word and thus fails with an error "wrong object".

Or, in other words, the first mouse was killed by the new trap!

If you really need this DOpus5 iconclock use build #554 again until the next update comes.

Update: Another user has reported a problem with Dirwork, where the app-icon is not created anymore. That's probably for the same reason: a wrong DiskObject structure as icon argument when calling icon.library functions like DupDiskObject(), which is used by most app-icons.

I wanted to make the icon.library safer with these checks for invalid data to prevent crashes, but it seems that some programs didn't build correct structures for their fake icons. Atm, you can go back to Build #554 if you have such a program, but please report all affected programs here!

NewMeter also doesn't start, because DupDiskObject() is rejected without a valid signature.

[PeterK]

Update to icon.library build #556:

Some programs are creating self-made icon structures, omitting the "DiskMagic" signature in the first word of the DiskObject and hence failed in the new checks for valid icon data in build #555. DupDiskObject() now adds the missing signature to the duplicated structure. This also prevents similar failures in other functions. (see 1. post)

[PeterK]

On request of a user (Johan S.) I've built another special version (HB020) of my icon.library as an alternative to TC020. Instead of generating a glow effect for TrueColor icons with only one image it creates a half-bright effect for the selected icons.

I've tried twice to send Johan this new version per email, but it seems that my emails are blocked again by these BraiN Damaged people of the German BND. This has happened with a bug report too, which I sent twice to the author of AGWViewer, I get no reply for emails to foreign countries.

[PeterK]

The last days I was analyzing a problem on WB 3.1 concerning wrong images for only some dragged TrueColor icons, where just a black rectangle appeared while they were moved around. I could find the reason and a fix already and an update may follow soon ...

But during my tests I suddenly noticed a very nice feature of the old workbench.library v40, which seems not to exist in newer WBs anymore. As yet, I didn't expect this being possible with P96, but on WB 3.1 I can drag some TrueColor icons in perfect quality and with a working Alpha Channel and soft borders around instead of getting poor looking planar images as on newer WBs v44+. I thought that this could only be achieved with CGX4, but it also works with P96 on WB 3.1 as long as the images have a width of a multiple of 16 pixels. For all other icons it didn't work.

Edit: It's not a feature of the old WB v40, but this TrueColor icon dragging was suddenly possible for some icons since I changed my gfx-patch recently, and the newer workbench.libraries are using the DrawIconState() function instead of this gfx-patch to call the direct drawing routines on RTG screens. After modifying the DrawIconState() function and some other code for WB v44+, I can get the same TrueColor icon dragging there, too. The restriction of the icon width to full words comes from the VSprite features that are required for the dragging. If I simply disable my image size checks in the gfx-patch then it works with any icon width in TrueColor and with Alpha Channel fading, but there are still some bad side-effects when I drag icons over and outside of screen borders, which need more investigations to be fixed. The next icon.library versions may get a much nicer RTG icon dragging and my FastWB version will probably become obsolete, because the colormapping and blitting of planar images is not required anymore on Hi/TrueColor screens. But the correct implementation could take a little longer.

[AMIGASYSTEM]

Peter a good news for AROS 68k, discussing on aros-exec and after some tests I discovered why the native Aros icon.library was not showing correctly the Dual-PNG icons, now it seems to work very well, you can read the discussion here:

https://ae.amigalife.org/index.php?topic=798.195


The good miker has also created some high quality graphics conversion tools as well as improving Multiview.

https://ae.amigalife.org/index.php?board=9.0

[PeterK]

Thanks Carlo, that sounds good!

I will download and check out the latest Aros 68k as soon as I have some more time, because atm I'm still busy with solving the remaining problems of the upcoming test version with my "Tricky Drag°n" (TM) in TrueColor on Workbench and P96. It's working already quite nicely, but it heavily depends on the code of my gfx-patch to catch the VSprite blitter calls and redirect them to the graphics card. It may come out soon now, but nothing will change for Aros 68k or DOpus5 in the first test version.

[AMIGASYSTEM]

AROS 68k the icon.library is in the ROM, the one in Libs is not used, maybe they forgot to delete it.

The only problem that I found with the native AROS 68k icon's library is that now does not work IconCopy and IconCopier "only with DualPNG icons" also Dopus4 does not show more colors to the icons, with your icon.library everything worked fine.

The only tool to swap icons that now works with the icon.library AROS 68k is CopyIcon44 (Aminet), the only problem is that it doesn't show the dragged icons on the GUI

[PeterK]

Update to icon.library 51.4.557_TC020:

"Tricky Drag°n" allows icon dragging in true RGB colors and with soft alpha channel fading at the borders with P96 on Workbench 3.0-3.9 for OS4 and PNG icons, and RGB for palette based ColorIcons and NewIcons. I'm not sure whether this new gfx-patch hack still works on P96 3.x?

CGX4 is not supported anymore since build #545 or #549. There are no changes made for DOpus5 or Aros 68k yet.

[hexaae]

I have P96 3.x and WB3.9 and dragging is working but now always solid...
Do you have a multi-format icon pack to test?

[AMIGASYSTEM]

hexaae what do you mean by solid ? do you mean the drag and drop shown in my screenshot, i was ok with icon.library versions too.

----- Italiano -----

hexaae che intendi per solido ? intendi il trascinamento mostrato nel mio screenshot, a me andava bene anche con le versioni di icon.library.

[PeterK]

Originally Posted by hexaae

I have P96 3.x and WB3.9 and dragging is working but now always solid...
Do you have a multi-format icon pack to test?

Thanks a lot for confirming that it works with P96 3.x, because I've only 2.x for tests.

Yes, it's correct that the dragged icon images are opaque now (except for the borders with alpha channel). Even under the mouse pointer they are not half-transparent anymore, at least on TrueColor screens. I could make all dragged icons partially transparent like on AfA_OS, but that would need a lot of slow multiplications (4 for every visible pixel, not only for the borders) and it would have no effect on the appearance of the planar sprite images, which are still used at the screen borders.

You can see that the icon images are changing from TrueColor to color mapped sprite mode as soon as you drag them onto or over the screen edges. It's already very difficult to handle this correctly with all the different system configurations and dragging routines (WB v40 or v44+, with/without P96, RTG or native, CGX4, DOpus5 ..., and all the different icon formats). The biggest problem is that I'm delaying the decoding of the 2. images and the creation of the masks until the icons get selected. So this all has to be done in the graphics patch when I catch the sprite data from the blitter calls and redirect it to the RTG functions. - Maybe CGX4 may work again when I disable the Super-Gels, but I didn't test that yet.

No, I don't have any mixed icon set for tests. I've a large collection of different icon sets from various sources, which are listed in my IconLib.guide.

[hexaae]

Originally Posted by AMIGASYSTEM

hexaae what do you mean by solid ? do you mean the drag and drop shown in my screenshot, i was ok with icon.library versions too.

----- Italiano -----

hexaae che intendi per solido ? intendi il trascinamento mostrato nel mio screenshot, a me andava bene anche con le versioni di icon.library.

Yep I meant opaque 100%...

@PeterK
Ok

[PeterK]

Originally Posted by AMIGASYSTEM

Peter a good news for AROS 68k, discussing on aros-exec and after some tests I discovered why the native Aros icon.library was not showing correctly the Dual-PNG icons, now it seems to work very well, you can read the discussion here:

https://ae.amigalife.org/index.php?topic=798.195

Ok, you said that the PNG icon problem was caused by the png.datatype v42.1. The old datatype v42.0 should work better, but where can I still get it or older Aros 68k compilations?

[AMIGASYSTEM]

Peter that png.datatypes v42.0 (06 March 2019) was part of a 2019 AROS 68k Nightly Build, on the Web now are unobtainable the old Nightly Builds

As I mentioned on aros-exec the "png.datatypes v42.0" is installed on an old version of mine (1.1) of AROS One 68k, if you need only the png.datatypes v42.0 I can attach it here

[PeterK]

Yes, if you could upload the older png.datatype v42.0 here or to the zone, then I could test it. I've already removed all older releases from my HDD. Thx!

[AMIGASYSTEM]

Here is the png.datatype v42.0

[PeterK]

Thanks, Carlo!

The PNG icons are now displayed correctly, but the icon dragging is still strange, using some wrong masks.

Btw, I'm fighting with the CGX4 dragging routines atm and couldn't find a good solution yet.

[AMIGASYSTEM]

Yes, with png.datatype v42.0 you can see DualPNG icons fine, but programs like CopyIcon and IconCopier no longer work on DualPNG icons, no image change and icons without colors.

Only CopyIcon44 is able to swap images on DualPNG icons, but it doesn't show any icons when you drag icons.

Even on Dopus4 if you do an IconInfo the DualPNG icons are shown without colors.

Also the programs to change the type (IconType) on DualPNG icons do not work.


P.S. I deleted the link of the png.datatype v42.0 I don't want someone install it on OS3, this datatypes is for aros 68k and doesn't work on OS3

[PeterK]

Old programs which have been written for planar icons or ColorIcons can't handle newer icon formats, so icon.library must convert the images for them and sometimes it also has to do a lot of cheating or patching in order to let them work with TrueColor icons.

But why do you want to use the original Aros 68k icon.library again? What are you missing in my library or what is not working as desired? Or do you plan to sell your distros for more than 10 € in the future?