icon.library 46.4 test versions

[Weaselrama]

Originally Posted by AMIGASYSTEM

If you on the miniature do:
- Menu Icon
- Information
- Save
An icon equal to the miniature of the same size as the Miniature will be created.

Ha! That worked! I love OS 3.9's icon menu in the information panel. It's extremely versatile.

[Weaselrama]

It's pretty wild how AfA's .exe libs affect libs and datatypes version numbers. My picture.datatype which showed 49.6 is now showing 45.17. Too freaking cool...

[PeterK]

HaHa, you didn't look at the LibID string of icon.library in Scout's library list yet ...

[AMIGASYSTEM]

Originally Posted by Weaselrama

It's pretty wild how AfA's .exe libs affect libs and datatypes version numbers. My picture.datatype which showed 49.6 is now showing 45.17. Too freaking cool...

This thumbnail icon technique was used many years ago by Kodak Photo CDs, photos could be seen in different resolutions.

These Kodak Photo CDs on Amiga could be seen only with AimCDFS or other equivalent Device CDs, with WinUAE CD Automount you can't see the photos of these CDs, I attach screeshot (used AimCDFS)

[Weaselrama]

Originally Posted by PeterK

HaHa, you didn't look at the LibID string of icon.library in Scout's library list yet ...

I didn't even think of looking there - rather, I looked in Sys Info. I'm not a coder but just a user. I mean nothing by that, it's just my head usually doesn't think in those terms or at least, not at first. Configuration - certainly, it's how my Amiga setup got to be fast, functional, and good looking but I'd be lying if I said I understood how it all worked. Sometimes in my case, it's by brute force.

[AMIGASYSTEM]

Originally Posted by PeterK

HaHa, you didn't look at the LibID string of icon.library in Scout's library list yet ...

Yes I looked, but there's your icon.library, otherwise Dopus4 wouldn't have worked.

[midwan]

@Peter I think there's still one issue, not sure if you've noticed or not:

When using IconLib TC020 51.4.535, together with DoNoColorMapping and HoldTCBuffer1, and the patched DOpus 5.83 binary that you provided, desktop icons (only!) seem to have a more "trimmed" mask than the previous version. Icons inside windows/listers look normal.

Reverting back to IconLib v51.4.533 and changing nothing else, fixes this.

I'm attaching a screenshot to demonstrate...

[PeterK]

Thanks for reporting this disfigurement, midwan !

Usually, I don't care much about these beauty issues. I think it's caused by one of DOpus5 woes, because it uses dozens of separate tasks for different purposes, and it can be a pain to filter them out.

The icons in a window are loaded by dopus_function and dragged by dopus_lister for example, but the icons on the desktop are loaded by the main process with a name which depends on the program name and can be something like DOpus5, DirOpus, DirectoryOpus or DO whatever you want. But, of course, there are more other task names as dopus_disk(copy) or dopus_info etc, I don't remember all of them.

Ok, I will consider the main process name for using the TCbuffer, too. And then you may come and say: "The icons are still not looking perfect inside of my trashcan or on my Ram Disk" ... or wherever DOpus5 uses another task.

[midwan]

Thanks for considering it.
Just a small, related note:
- If you disable DoNoColorMapping and reboot, the problem also goes away.

But I guess you know that, since you understand more about how this works internally

[PeterK]

Update to icon.library 46.4.536 (Aros, TC020, LD020, FastWB and Dopus 5.83 only):

TCbuffer1 was not enabled for icons directly on the DOpus5 desktop, and thus their soft borders were cut off by the image masking when DOnoColorMapping was activated, which is required for the fast custom dragging routines. - No changes in DOpus 5.83.

http://aminet.net/package/util/libs/IconLib_46.4

[midwan]

That was fast!

Confirmed to work as expected now, thanks!

[PeterK]

Update to icon.library 46.4.537:

This is a fix for a small gentle bug that was hiding in IconControlA(SetWidth/SetHeight) since build 484. It did probably never cause any harm yet by using the non-preserved scratch register D1 with a structure offset of zero for Width, because by coincidence AllocMem() uses D1=0 for clearing the structure too, and thus has always fixed this bug. But some "evil" debugging tools didn't like this trick. These functions were called by Eastern, for example. Unfortunately, Eastern still doesn't work on Aros after fixing this bug, so don't install it there!

[James]

Originally Posted by PeterK

Update to icon.library 46.4.537:

With this update Memicon no longer works with the helvetica font at size 13, it complains about invalid icon size. Setting it to 12 works, but it is a bit tiny.

http://aminet.net/package/util/wb/Memicon

Just tried size 15 and it works.

[PeterK]

Hi James,

my tests with Helvetica 13 and all other sizes didn't cause any errors here. Try FixFonts or send me your other MemIcon tooltype settings.

But, if MemIcon creates an icon which is larger than 256x256 or just wider than 256 pixels that's not supported by (any) icon.library. It would be allowed to use a longer icon label, but when I select the MemIcon for dragging it seems that the icon images are also too wide (not sure about that).

Is your issue reproducible and does it always vanish with the previous versions? I tried Helvetica 13 with 537_TC020 and some debugging tools running, but it works.

[James]

Originally Posted by PeterK

Is your issue reproducible and does it always vanish with the previous versions?

No, I can't get it to fail again now.
When I updated the icon.library (TC020) and rebooted it failed immediately. I changed the font size and it worked, tried to change it back and it failed again. Tried this several times and it always failed with size 13. Switched to verdananabold 16 and it worked, so I left it at that. Now, testing it again, it has worked with every font and size I have tried so far.

[PeterK]

After doing some more investigations I can say that nothing is calling the functions which I changed in 537, neither MemIcon, nor Workbench by order. So, the Helvetica 13 font problem can not depend on my latest update, but maybe on some racing conditions with LoadWB and WBstartup tools.

MemIcon just uses GetDiskObject(), DupDiskObject() and FreeDiskObject() from icon.library before it calls the Workbench functions AddAppIcon() and WorkbenchControlA(), which consequently uses GetIconRectangle() and IconControlA(), but nothing like SetWidth or SetHeight.

I couldn't find any explicit comments about limitations for width and height of AppIcons handled by workbench.library except for the restriction to word size in the diskobject and gadget structures. In the autodocs these images are called "hit box" and it seems that more than 256 pixels for w an h are allowed in contrast to other icons.

[indigolemon]

Hi Peter, just wondering if the latest 537 be 51.4.537 as opposed to 46.4.537.

Doesn't seem to have any adverse affect in use, but wondered why it had changed

[PeterK]

Sorry, but after checking all versions in the latest 537 package I can't see any changes.

In general, my icon.library has the version 46.4.xxx, with the build number as index. But since build number 510 or so I have added support for Eastern to send TrueColor images to my icon.library, and Eastern only does this if the icon.library version is at least 51 and can handle that with IconControlA(SetImageData). My 51.4 versions are able to do just that additional task, but they don't support any other features of an OS4 icon.library.

Therefore the TC020, FastWB, HAM8 and HAM6 versions are v51.4 now and can display the preview thumbnail images of Eastern in TrueColor or HAM, whereas all other 46.4 versions would only display dithered Eastern images with maximal 256 colors.

[indigolemon]

Originally Posted by PeterK

In general, my icon.library has the version 46.4.xxx, with the build number as index. But since build number 510 or so I have added support for Eastern to send TrueColor images to my icon.library, and Eastern only does this if the icon.library version is at least 51 and can handle that with IconControlA(SetImageData). My 51.4 versions are able to do just that additional task, but they don't support any other features of an OS4 icon.library.

Therefore the TC020, FastWB, HAM8 and HAM6 versions are v51.4 now and can display the preview thumbnail images of Eastern in TrueColor or HAM, whereas all other 46.4 versions would only display dithered Eastern images with maximal 256 colors.

Cool - thank you for the explanation

[James]

Originally Posted by PeterK

After doing some more investigations I can say that nothing is calling the functions which I changed in 537, neither MemIcon, nor Workbench by order. So, the Helvetica 13 font problem can not depend on my latest update, but maybe on some racing conditions with LoadWB and WBstartup tools.

The only thing I can think of is that I was experimenting with Dragon (always buggy) before I reset my system. Maybe this was the culprit? Have tried to replicate the problem, but can't...

http://amigazeux.net/dragon/