icon.library 46.4 test versions

[TuKo]

That's great ! Thanks !

[gulliver]

Thanks, great solution for an old annoying problem.

[PeterK]

Removed 468, still not working perfectly when swapping images.

[gulliver]

No worries, we are patient, and trust your skills

[hexaae]

Is there a tool like Eastern http://m68k.aminet.net/package/util/wb/eastern available with support for 24+bit palette icons thanks to iconlib46?

[PeterK]

Update to icon.library 46.4.469:

The bugs of 468 should be fixed. The problem was that the filename of the Ram Disk can be an absolute path or just a file relative to the current dir, and the root can be the device RAM: or any volume name like "Ram Disk" or "RamDisk" as I use it to avoid spaces in the path. Not so easy to detect the Ram Disk. Usually RAWBInfo and SwazInfo are using the tool DefIcons to get the default icon. If DefIcons is not installed icon.library loads def_RAM.info now instead of def_Disk.info.

So, the automatical updating of def_RAM.info works now on the Workbench 3.5/3.9 and 68020+ CPUs, even if you have OS 3.0/3.1 installed. No need for DefIcons running. It doesn't work on DOpus5 or 68000 systems. That's why I have removed the 68000 code again.

@hexaae

The 68k build of Eastern assumes an OS4 compatible icon.library when the version number of the library is v51 or higher. In this case truecolor icons will be created.

I would assume that v51 has some additional features compared to v45/46. Didn't analyze yet what Eastern really needs for TrueColor support.

[indigolemon]

Hi Peter, the ram disk icon is working perfectly for me with 469, softlink removed from startup-sequence. Great work as always!

You also made me investigate AmberRAM which is also setup and working well now too

[PeterK]

Thanks, indigolemon

Meanwhile the updating of def_RAM.info also works on WB 3.0/3.1 and partially under DOpus5, too. But I won't make much efforts to fix the limitations under DOpus5. Instead I will try to get it working with the 68000 version on the next days ...

[PeterK]

Update to icon.library 46.4.470:

The automatic copying of the Ram Disk settings from and to Sys/def_RAM.info in ENV: and ENVARC: works now on all Workbench and CPU versions, but under DOpus5 only CopyIcon seems to make use of it.

[PeterK]

Update to icon.library 46.4.471:

The synchronization of the Ram Disk icon and Sys/def_RAM.info in ENV: and ENVARC: works now on all systems, including DOpus5. (With 1 exception: the icon position under DOpus5 on OS 3.1 is not restored after a reboot because RAM:disk.info is not created on system start.)

[Retrofan]

[PeterK]

Sorry again, there was a memory trashing in 470 and 471 (removed).

[indigolemon]

470 works fine for me (no obvious issues), but yes 471 gives me a ramlib error on boot.

[PeterK]

You're right, the memory trashing was introduced in 471.

Murphy is my best friend!

[indigolemon]

Originally Posted by PeterK

You're right, the memory trashing was introduced in 471.

Murphy is my best friend!

Murphy is everyone's friend his laws suck though

[PeterK]

You could call my uploads here "beta versions", but I call them "test versions", because most of the time they are not much betta than before!

Michael from Moskow has send me his feedback again, and I know him as one of my hardest naggers, but most often he has some hidden bugs he just wants me to pay attention to, and this time again he made a direct hit. There was a memory trashing in 471 and only he has reported it (26 downloaders here and 11 more at at A1k.org), although I had no Enforcer or MungWall hits at all. That's the feedback which I need for my buggy code. : If you still don't report any bugs here I will upload the latest trash to Aminet soon. Live with it or complain about your problems before it's too late.

[daxb]

Originally Posted by PeterK

There was a memory trashing in 471 and only he has reported it (26 downloaders here and 11 more at at A1k.org), although I had no Enforcer or MemWall hits at all. That's the feedback which I need for my buggy code.

Usually the people don't have debug tools running in the background even if they know the tools. If you release a test version and post it, copy/paste a text like "Please use tool x, y to test icon.library and report bugs to make it better/stable..." for example. If one or two people do it then you have won already.

[indigolemon]

Hey Peter, I test by installing your library and using it - if there's more you'd like me to try just say, happy to help where I can

[edit] Or I could read your post while awake, I'll ensure I employ MuForce during future testing!

[PeterK]

Sorry, my previous post was just some sort of an outbreak of frustration about my own bugs and also about the fight with all the quirks in DOpus5. I did not even notice the memory trashing myself on a couple of different configurations here with Enforcer and MungWall running in the background. I was just a bit suprised that nobody except Michael and later also indigolemon (ramlib error) has reported any problems. Thanks to both!

I've already sent Michael a new fixed beta version and I'm waiting for his reply now. Not sure if I should upload 472 here or directly to Aminet, because I don't want to bug the users here with yet another test version again.

[gulliver]

Originally Posted by PeterK

I've already sent Michael a new fixed beta version and I'm waiting for his reply now. Not sure if I should upload 472 here or directly to Aminet, because I don't want to bug the users here with yet another test version again.

PeterK, You dont bug us, we feel in constant debt to you, because your work in IconLib is worth a lot for us.

Every Amiga user nowadays, takes advantage of the speed and features your library provides. We are immensely grateful that we have a coder like yourself: years have passed and you are still comitted in squeezing every drop of performance and smashing every bug out of icon.library.

So please carry on, keep doing what you do.

Thanks again for your work.