icon.library 46.4 test versions

[Michael]

Default, do you mean before snapshooting ? (Ok) Or always ? (Not the best option imho)

[PeterK]

The DOpus5 lister toolbar appears only for PNG disk icons by default (AmiKit needs that).

Of course, you can always change the drawer flags and viewmodes as you like them and then snapshot the lister which will automatically convert the PNG icon into the OS 3.5 format and save your settings.

[Michael]

This raises another long awaiting question...
Currently the lib converts all icons to 3.5 format on snapshot, apart from plain ones. Right ?
Can we have a setting to prevent conversion ? (at least I am interested in OS4 icons, so that I don't have to worry that I mess them up when snapshoting them under OS3)
But I guess it might be useful for other formats too.

[PeterK]

A simple icon snapshot won't convert an OS4 icon into the OS 3.5 format, because the OS4 icons have a standard DoslObject structure where the icon position can be updated without overwriting the rest. Only disk and drawer icons are converted when their windows are changed with snapshot.

[Retrofan]

Originally Posted by PeterK

Only disk and drawer icons are converted when their windows are changed with snapshot.

But also after a request to change them if you wish.

[PeterK]

No, there is no safety check (requester) yet like you get it when you snapshot PNG icons. I'm thinking about creating a general TrueColor safety check atm, but I don't promise anything now. Let me see if it's possible without consuming any extra code. Maybe, I don't know ...

[Tumo007]

Originally Posted by PeterK

http://aminet.net/package/util/mouse/FreeWheel

Thanks! I don't know how I've missed to see that on Aminet.

I greatly appreciate your work on the icon.library. PeterK seal of quality

[PeterK]

Update to icon.library 46.4.400:

You will always see a requester now when PNG or OS4 TrueColor icons need to be converted into the OS 3.5 format.

[Michael]

So then... Snapshoting an OS4 icon or copying it by dragging in DO forces a conversion.
If you cancel the conversion, the icon is not copied by D&D! And an error is displayed.

Works a bit better under WB, that allows a simple snapshot, but not D&D copying.
(even move from one folder to the other on ram: disk gives a requester)

[PeterK]

Workbench and DOpus5 have a totally different behaviour (DOpus5 is really a pain)

But anyway, I prefer to convert all TrueColor icons to the OS 3.5 format.

[Michael]

I know, but can we avoid the DO error message if we press cancel ?
Locale support for the requester ?

[PeterK]

No, I have to return an error code like "object of wrong type" to the caller to abort the complete action (like copying a drawer with all contents) and not only skipping the writing of the drawer icon. The second requester is caused by DOpus5 directly.

And no again, localization is not planned.

[Michael]

In my test I drag several tool icons from one folder to the other.

We get a requester, so we hit abort for each icon.

Now, under WB this operation completes fine and icons are copied as is. 1:1
Under DO this operation fails, and nothing is copied.

If we press convert, DO and WB behave the same and copy the icons (with conversion) and exe files associated with them.

[Michael]

Some more interesting comparison results on same 060 hardware and 16bit CGX.

ScalOS 41.8! (I believe some things it does through the icon lib, some by itself)

CrystalPack - 5.98 s
KensPack - 19.30 s (native pngicon loader - shows only 1st image and tints for selected)
KensPack - 17.96 s (disabled pngicon loader - both images are loaded)

AmigaOS 4.1 on same hardware Classic 603e/180

CrystalPack - 2.30 s (either there was some improvement there, or the ppc pulls it out very well, still slower then 060!)
KensPack - 6.58 s - (with png module 53.1)

[PeterK]

Update to icon.library 46.4.401:

A bugfix for a MuForce hit in the direct drawing code of the 68020 version.

And a replacement for the inflate routine of the 68000 version. The new code that has been written and released by Keir Fraser is 2.7 kB shorter and consumes 35 kB less memory. Many thanks to Kaffer !! Well done

[PeterK]

Update to icon.library 46.4.402:

It's now possible to disable the delayed colormapping of the 2. icon image with the command NoDelayedImage2. This may be required for a few gfx-cards, like the Voodoo 4 with Mediator, to avoid graphics corruption while dragging icons.

[Michael]

@PeterK
Have done some more tests with D&D of icons in different conditions.
WB and Scalos accept (Abort requester) and copy the tool and it's icon without changes from one dir to the other (different device) or move tool & icon if it's on the same device.

With DO it's a bit different, we can do the same if we drag tool & icon in list mode, but not in icon mode. When ever we do a D&D with icon we get a requester for conversion of OS4/PNG icon and (Abort conversion) fails to copy or move anything.

Tried different icon copy modes in DO prefs. But no luck.
Are you sure there is no work around this ? Why can't we pass a pointer to the original image and copy it byte byte without modifying it if we pressed (Abort)

@Anyone
Cache icon images in DO. Fiddled around with it, any idea how it works? I could not notice any difference in speed with it enabled or disabled.

[PeterK]

Originally Posted by Michael

Whenever we do a D&D with icon we get a requester for conversion of OS4/PNG icon and (Abort conversion) fails to copy or move anything. ... Tried different icon copy modes in DO prefs. But no luck. Are you sure there is no work around this ?

Instead of using Drag&Drop you have to use Copy&Paste. That makes a 1:1 copy!

Cache icon images in DO. Fiddled around with it, any idea how it works? I could not notice any difference in speed with it enabled or disabled.

The cache is for deficons only. With the cache enabled it should load a large number of the same deficon faster.

[Michael]

Copy&Paste, the AmiKit setup style I guess. I hate this function and never got to using it (just like windows), it's just not what we are used to, and it's not like WB.
It is ok for coping something, but when you move something on one disk from folder to folder, this will not work as easy, unless there is Cut&Paste mode.
Dragging files in lister mode, or lister to icon works fine too = 1:1 copy.
Guess we will have to leave with it until someone comes with a bright idea.

[Retrofan]

I've been trying Icon.library 402 with DOpus. If you make a Clean Up to change the icons position and you want to snapshot them it will ask if you want to convert them, but if you don't want to convert them it won't save the new position, as the only options are "Yes, this icon", "Yes, always" and "No, abort".