icon.library 46.4 test versions

[AMIGASYSTEM]

Originally Posted by PeterK

Correct, but you also said this:

That statement was a bit confusing, because the converted icons are not corrupted, they are OS 3.5 ColorIcons. I had to check whether there was something wrong with them.

I was referring to the DualPNG icons, if you look carefully at the icons you will notice that the icons after conversion with IconEdit 3.9 are less qualitative, they have some smudges in some cases more conspicuous, I enclose two exhaustive screenshots

[PeterK]

Originally Posted by PeterK

If you use the 3.9 IconEdit to change the type of an Aros icon to "Disk" then IconEdit will, of course, convert that into a pure OS 3.5 color mapped icon, no ARGB TrueColor image remains.

The 3.9 IconEdit cannot work with TrueColor images, the quality gets lost.

You could try other tools to change the icon type, like Report+ for example, but maybe not on Aros.

[AMIGASYSTEM]

On OS3.9 or AfA One there are no problems and no quality loss if i use Icon Information, Report+ does not exist for AROS.

The initial problem was that the "disk icon" conversion made by Icon Information was not recognized by AROS x86, while the conversion made by IconEditito 3.9 was correct on AROS x86.

Sorry again for bothering you with my chatter!

[PeterK]

Originally Posted by AMIGASYSTEM

... Report+ does not exist for AROS.

The initial problem was that the "disk icon" conversion made by Icon Information was not recognized by AROS x86, while the conversion made by IconEditito 3.9 was correct on AROS x86.

IconEdit 3.9 does not exist on Aros x86 either.

I don't know whether some simple icon type programs are correctly adding a drawer data structure to a "Disk" icon when you convert them from "Tool" or "Project". If that is not done or checked for every "Disk", "Drawer" or "Trashcan" then the icon may get rejected by the OS, because without drawer data it's not a valid structure. Usually icon.library adds that automatically, I just don't know what Aros x86 and Icon Information are doing.

[AMIGASYSTEM]

Unfortunately on AROS x86 there are not many tools to manage the Icons, there is only Processicon and IconPoser

IconPoser generates Dual-PNG Icons like those created on OS3 and therefore with the same problem, no "icon Disk" compatible with AROS x86

Processicon, I must be honest I didn't understand how to use it, on DOS commands sometimes I have difficulties.
Many developers do not write examples and then it becomes problematic for those who do not use a Shell, occorrerebbe una bella GUI

http://archives.aros-exec.org/index.....i386-aros.zip

[PeterK]

It's easy to change the type with ProcessIcon:

ProcessIcon YourIconFile SIT DISK

That works at least on AOS with my icon.library, even for OS4 and PNG TrueColor icons, although ProcessIcon doesn't know these formats and can handle only OS 3.5 ColorIcons. My library is cheating a bit.

But don't expect the Aros icon.library to do the same tricks behind the back of ProcessIcon or any other icon tools. There, it will probably just work with OS 3.5 ColorIcons.

[AMIGASYSTEM]

Originally Posted by PeterK

No, I don't want to create an account and login at amigalife.org. Copy and upload the screenshot if you think that's important.
.

Meanwhile thanks for the help with ProcessIcon, I attach some screenshots of the icons colored by miker.

[utri007]

With OS3.1.4 without a physical rom, lattest icon.library from aminet gives me a "couldn't open workbench library 37.x"

Just copied icon.library_020 to libs and renamed it.

[PeterK]

Originally Posted by utri007

... latest icon.library from aminet gives me a "couldn't open workbench library 37.x"

No, my icon.library would never complain about a missing workbench.library. It can work with WB 3.0/3.1/3.1.4/3.5/3.9, provided that my library was loaded at all.

That message may be the result of a wrong installation of 3.1.4. Please read the FAQ. If you are still using the 3.1 Rom and didn't use the Installer some things may go wrong. In such a case some libraries need to be updated by LoadModule ROMUPDATE and an automatic reboot at the beginning of the startup-sequence. But that also requires that you have copied the workbench.library and the icon.library (and maybe other libs) correctly with the P bit set from the 3.1.4 install disk into Libs:. Of course, you can use my icon.library, too.

I am not an expert for OS 3.1.4 installations on systems with old Roms and can't give you any advice. Again, read the 3.1.4 documentation and the FAQ or ask the developers.

[AMIGASYSTEM]

Confirmed Peter, I did a test and no Workbench.library request, everything works perfectly with OS 3.1.4 with Kickstart 3.1 and your icon.library

[utri007]

OK, I tested this twize, after first failure I just reinstalled OS3.1.4 with Installer and just copied icon.libary_020 to Sys:libs and removed _020 from name. Rebooted and got that error message. Turned system OFF and wait some half minits before reboot and still same.

[PeterK]

Was that a clean OS 3.1.4 installation from scratch or some sort of trying to update an old system, in the worst case writing over an existing ClassicWB system with Scalos 1.2 installed? Never try the latter, this will most likely not result in a properly working system.

Did you check and ensure that the P bit is really set for all modules that are loaded by LoadModule ROMUPDATE like Libs:workbench.library and Libs:icon.library (but there are many other required files installed from the Modules disk corresponding to your hardware).

What happens when you use the OS 3.1.4 icon.library v45.22? If that works it should do the same with my library. It's not my problem in case that 3.1.4 doesn't work for you. Don't modify the 3.1.4 startup-sequence before it ever works successfully.

If you want to install my library use "Copy icon.library_68020 Libs:icon.library CLONE" to make sure that the P bit is preserved, too. LoadModule requires this "pure" bit. Or use LoadModule AUTO as mentioned in the FAQ.

I usually just copy files with DOpus4 and that shows me the protection bits. But a list command can do that too.

Btw, what exactly is your Kickstart Rom version? There are some 3.1 Roms from from Hyperion or Cloanto without workbench.library.

[utri007]

OK, this one was actually simple. Problem was DirWork I used to copy files. I just installed and replaced it with Dir Opus 4. Problem solved. If protection bit is missing I get that error, wich is weird but not a icon.library problem.

[AMIGASYSTEM]

Originally Posted by utri007

OK, Problem was DirWork I used to copy files.

DirWork has no problem to copy protection bits, probably yours is not well configured !

[PeterK]

Originally Posted by utri007

OK, this one was actually simple. Problem was DirWork I used to copy files. I just installed and replaced it with Dir Opus 4. Problem solved. If protection bit is missing I get that error, wich is weird but not a icon.library problem.

Great, I'm glad that it works now.

The "pure" bit is only required for LoadModule ROMUPDATE to decide which Rom modules have to be replaced or installed, a normal installation won't need it, but I should add the option "CLONE" to the copy instruction in my Readme file for this case(No sorry, the option CLONE is not required for copying protection bits, that's for the timestamp and comment only).

[macce2]

Stupid question, but please help me..
What does "pure bit setting" actually mean...?!
I asssume it does refer to file protection flags ..?!?
I thought that "p" is for protection...

[PeterK]

Protection bits is the name for all these flags: HSPARWED, you can change them with the command protect:
Hold, Script, Pure=can be made resident, Archiv, Readable, Writable, Execuable, Deletable.

The P or Pure bit is a flag for files that can be loaded resident by commands like LoadResource, LoadModule, LoadResident and stay in memory. Pure means that their code must be able to allow that more than one task or process can execute these commands or resident modules at the same time without any interactions causing possible conflicts, like buffer access for example.

LoadModule uses this P flag for its option ROMUPDATE to find out which modules it should load resident, like libraries, handlers or devices.

[macce2]

Many thanks, PeterK !
Your help with this thing is of great value to me.
I do admire your work.

I guess I 'll have to study some basic things of AmigaDos again.
The letter "H" of the protection bits is new to me, too. (What is it supposed to hold ?!)

[PeterK]

Sorry, I don't know what the H bit is really good for. I never ever needed it, I just know that it's not a "Hidden" bit as this was claimed by DOpus4.

I think Thomas Richter can explain you the purpose of this meaningless H bit, I've forgotten what he said about it, although I'm sure it was something important.

[Amiga68k]

Originally Posted by macce2

The letter "H" of the protection bits is new to me, too. (What is it supposed to hold ?!)

https://en.wikipedia.org/wiki/AmigaDOS#Protection_bits