Icon Toolbox

[miker1264]

I'm currently working on a series of five or six icon apps collectively known as "Icon Toolbox". (The name was inspired by HDToolbox).

Icon Toolbox is a ButtonBar Menu App Launcher for the individual Icon Tools (Apps). Each of them feature Drag-n-Drop and a similar user interface.

Although each Icon App can be located in another location with it's own icon the App Launcher keeps track of each entry for each button so it can launch the tools from a central location (Icon Toolbox).

[Amiwell]

Thank you Miker

[AMIGASYSTEM]

miker1264, all apps to manage icons are welcome, icons are very important for AROS/Amiga, no other system uses icons in the same way.

[miker1264]

miker1264, all apps to manage icons are welcome, icons are very important for AROS/Amiga, no other system uses icons in the same way.

Thanks.

I have several icon apps planned. Icon clone, Icon press, Icon color, Icon process, Icon info & a few more after that.

Icon Color and Icon Process will be especially interesting. Icon Color will change the Color Theme of a PNG Icon "on-the-fly" by using HSL (Hue, Saturation, Luminance) Values. First the icon is split into two images. The image data of each is held in memory. The HSL values are applied to each pixel. Then the icon is reassembled. The original icon is replaced. Should there be a 'Reverse" button ?

Icon Process is a Batch Process using Colored Base Images, Original Icons, & their corresponding Icon Masks. The Base Images can be produced by Icon Color. They are just plain drawers for example of a certain color theme. Icon Process can very quickly generate about 100 new colored icons with glyphs in less than a minute.

Using a script or another application to quickly replace the iconsets on an AROS installation may also be useful.

Just trying to imagine the possibilities. 

[magorium]

Just trying to imagine the possibilities. 

At the moment i'm dusting off some old code of mine that processes icons (it is like a very raw information tool: determine/display iconformat, tooltypes etc) without using the OS API.

Although i can imagine the possibilities ... at the moment i'm more interested in knowing how (if any) you approached icons that do not play nice and don't exactly follow the rules. E.g. in case you are talking to your icon and it responds with:
- hello user i have a newdrawerdata structure attached... fooled you as it is not there !
- Oh you though that additional data after classic storage was meant to be interpreted as a glowicon: fooled ya again !
- Do you really think that when there is some diskmagic and some fields that act like an icon that i am really an icon ? I just stopped being a classic icon after do_Pad , fooled ya again !
- So you like my sexy newicon outfit ? Which one will you favour ...me or my brother that hides itself in glowicon.
- I don't like storing my tooltypes strings in a proper way, I'll just stop somewhere in the middle. And don't you dare respect my tooltype count either.

Most things can be "caught" but i wondered if you had given these kind of things any thought and if so how your code approaches such things (if any).


At the moment my code does a byte count check before reading the actual data to make sure the bytes are actually present. Also some other sanity checks are in place but sometimes the checks are grasping at straws.


Also, I'm still trying to come up with a decent strategy with regards to newicons as in which one to favour (if any).

[AMIGASYSTEM]

In any case AROS x86 has a strange behavior with some icons types, example, it does not distinguish a "Disk Icon"  and "Drawer Icon" icons

In praxis you can replace or reverse the icon types and the result will not change.

On OS3 for example a drawer icon does not replace the "Disk.info", on AROS (Wanderer) you can do it without changing anything, just renaming icon Drawer in Disk.Info

[miker1264]

In any case AROS x86 has a strange behavior with some icons types, example, it does not distinguish a "Disk Icon"  and "Drawer Icon" icons

In praxis you can replace or reverse the icon types and the result will not change.

On OS3 for example a drawer icon does not replace the "Disk.info", on AROS (Wanderer) you can do it without changing anything, just renaming icon Drawer in Disk.Info

The way that icon attributes are stored in Classic Icons differs from the method used for DualPNG icons.

For Classic Icons it is all stored in the icon itself. For PNG it is stored as "attributes" in an 'icOn' chunk.

[miker1264]

@magorium

I do have code like that as well. It checks the entire icon looking for offsets & verifying structures. There are several types of icons both Classic & PNG which have sub-types.

In the DiskObject for a Classic Icon there are special boolean values which are either 1 or 0. For example firstimage, secondimage, drawerdata, defaulttool, tooltypes. If these are 1 the data is present. If 0 it is not.

If marked as 1 the data must be present or it is not a valid icon. I will post my Check_IFFOffset & Check_IFFType for examples.

[magorium]

In the DiskObject for a Classic Icon there are special boolean values which are either 1 or 0. For example firstimage, secondimage, drawerdata, defaulttool, tooltypes. If these are 1 the data is present. If 0 it is not.

If marked as 1 the data must be present or it is not a valid icon.

Yeah, i use those as well. Have to otherwise the icon processing wouldn't be very informative :-)

A typical log for my tool outputs:

Code: [Select]

stats:
processed 8260 files in 9.82 seconds

invalid :    1
valid   : 8259
--------------- +
total   = 8260

Unknown Format :    0
OS v1.x Format :  556
OS v2.x Format :  735
OS v3.5 Format : 3506
NewIcon Format : 3040
PNG Format     :  422

Undefined icons :    0
Disk icons      :   13
Tool icons      :  400
Drawer icons    : 3572
Project icons   : 4268
Other           :    6

Additionaly the tool can output some processing information like for example a typical powericon that looks like:

Code: [Select]

opened stream for /media/ramdisk/testicons/power/AlpyreIcons1.info
reading png icon
attempting to load PNG icon file
PNG icon loaded from stream
chunk[0].name = tEXt
chunk[1].name = icOn
trying to copy icOn chunk to memory
tag = $80001009
Stacksize: 30000
tag = $8000100F
OS4: icon type (WBDISK..WBKICK): 2
tag = $80001003
Drawer X Position: 206
tag = $80001004
Drawer Y Position: 133
tag = $80001005
Drawer Width: 274
tag = $80001006
Drawer Height: 178
tag = $8000100D
OS4: ULONG: drawer view X offset: 0
tag = $8000100E
OS4: ULONG: drawer view Y offset: 0
tag = $80001007
Drawer View/Type Flags: 4177526783
tag = $80001107
written from AFA to store magellan settings: 16777216
tag = $8000100C
OS4 uses this (whatfor seems unknown): 0
done reading png icon
closed stream
I still need to figure out some things there (and some tag value swapping is stil wrong as well, as i only added that for those tags that have documentation i can rely on).

here some errors:

A classic icon structure

Code: [Select]

opened stream for /media/ramdisk/testicons/MagicWB2-16/FreshIconsv121/Default_Set2/Icons/def_kick.info
reading classic icon
attempting to load WorkBench v1.x icon file
sizeof(self) = 78 sizeof(TStructDiskObject) = 78
Trying to read struct DrawerData from offset $0000004E
SizeOf OldDrawerData = 56
Trying to read struct Image (1) from offset $00000086
skipping 1216 bytes plane-data
Trying to read struct Image (2) from offset $0000055A
skipping 1216 bytes plane-data
Trying to read struct DefaultTool from offset $00000A2E
Default tool = ""
Trying to read struct ToolTypes from offset $00000A33
expecting 0 tooltype entries
done reading 1.0 icon
detected data after classic AMIGA icon structures, most probably a OS 3.5 icon
ERROR: carbidge after 1.0 icon structure found
closed stream

A newicon structure:

Code: [Select]

opened stream for /media/ramdisk/testicons/glowicons/CfouGlowIconCollection/i-m/Jst_leanderq.info
reading classic icon
attempting to load WorkBench v1.x icon file
sizeof(self) = 78 sizeof(TStructDiskObject) = 78
Trying to read struct Image (1) from offset $0000004E
skipping 720 bytes plane-data
Trying to read struct Image (2) from offset $00000332
skipping 720 bytes plane-data
Trying to read struct DefaultTool from offset $00000616
Default tool = "jST"
Trying to read struct ToolTypes from offset $0000061E
expecting 80 tooltype entries
ToolType string[1] = "(HDLOAD)"
ToolType string[2] = "(NOFAST)"
ToolType string[3] = "(DELAY)"
ToolType string[4] = "NOCACHES"
ToolType string[5] = "(NTSC)"
ToolType string[6] = "(LOWMEM)"
ToolType string[7] = " "
ToolType string[8] = "*** DON'T EDIT THE FOLLOWING LINES!! ***"
ToolType string[9] = "IM1=B}}!8.+..[9l...TA(dS15FQ)lSJ.j.B.(SB,.C9(BB(.(`#8..Jh`+..KJS,.5I+[..hdDG..(.Jnν.l."
ToolType string[10] = "IM1=......."ID..2j@.2b(A$2..*E$0bIE@2b(<.0bIA2."H<.nZ)EE2a.@.nb(E40h.j'<.nZ(E4.j'<..Y.A$.j).0i.<.na.E$..H<.na.A40jIA0.2a.<.na.E"
ToolType string[11] = "IM1=A$2.H<.nZ(A4.jIE4`.$.Y.<ġY.A#.jI@.nY.A$2jIE0.h.$.b(@ġY.@.nb)E$.Y.<.0bIA4`.$.jH@.nY.@.nb(E$.a.<.nb)E42h.$..)@.nY.@.nb(E4.Y"
ToolType string[12] = "IM1==$.Y.A$2j(E0.j@.$.Y.<..Y.A$.j'<ġa.<.0jIA$`."@.$.Y.<..Y.A$.jH<.nZ(@ġb)E40h.0Y.<.0Y.A$.jI@.nY.A$.Z(E4.b.0Y.<ġa.A$.jJE#nY.="
ToolType string[13] = "IM1=A$.Y.A4.b).0Z'<.0a.A40jJE#nY.=$2j'A$.jHA0.0Z'<.0a.A4.bIID.Y.<ġbI@.2jIE$2.Z(<..Z'A$nZ)EE0Y.<.nb(E4.bIE4.bI.b(<..Z(=$.Y.E54j"
ToolType string[14] = "IM1=@.nY.=$0jHA4.jiA$..(A$.Z'=$0bI@.2jmE#nY.<.0j)E$2jII4.bI.)A$.Z'=$0b)I40bJUdnY.<.nbIE4.jIE52jHA0.)A$.Y.<.2b(EE2b)Hb(i.=#nZ)E$"
ToolType string[15] = "IM1=E4.jiE54.*E$`.j(E4.b'A$.b)IE2bI0afi.A#nZ)E$.j)I4....j.IDnZ'=$.j(E.(BHDaf0g=$0Y.E40jIA5....jJID.Z)<.2jIA54@.E4f0A<.2j'.$.b.E"
ERROR: an error ocurred reading tooltypes, exiting loop
done reading 1.0 icon
closed stream

But... you process the actual image data as well, my tool does not do that (it was not intended to do so) and just ignores those parts.

[AMIGASYSTEM]

The way that icon attributes are stored in Classic Icons differs from the method used for DualPNG icons.

For Classic Icons it is all stored in the icon itself. For PNG it is stored as "attributes" in an 'icOn' chunk.

miker what ciatate also happens with native AROS Icons, see screenshot, just renamed the folder "Rexxc.info" to "Disk.info", once copied to the Disk Root the icon automatically turns into "Icon Disk", all this should not happen

[miker1264]

The way that icon attributes are stored in Classic Icons differs from the method used for DualPNG icons.

For Classic Icons it is all stored in the icon itself. For PNG it is stored as "attributes" in an 'icOn' chunk.

miker what ciatate also happens with native AROS Icons, see screenshot, just renamed the folder "Rexxc.info" to "Disk.info", once copied to the Disk Root the icon automatically turns into "Icon Disk", all this should not happen

Not sure why that happens. Is it AROS 68k? Does the same thing happen on x86 & x86-64?

[miker1264]

@magorium

Get_IFFOffset & Check_IFFType don't load images. Those two functions only check the icon attributes & the offsets associated with the OS35.5 IFF Data.

The offset for the beginning of IFF Data is sent to Display_Icon to display images. But if the offset is 0 or otherwise not valid nothing will display.

It reminds me of a command line tool I was going to write called "Icon info" to do basically what you described - reading through the icon data while checking the file.

It shouldn't be confused with "Icon Information" such as with Magellan. But I also wanted to extract the "Icon Information" code from Magellan to make a standalone application just for the fun of it.

But there is only so much time in the day & I already have several projects to work on. They never seem to be done.

This is the source code for Icon Clone. Inside you will find the two functions to read classic icons.


In addition I used these for reference:
// http://krashan.ppa.pl/articles/amigaicons/
// http://www.evillabs.net/index.php/Amiga_Icon_Formats

[AMIGASYSTEM]

Not sure why that happens. Is it AROS 68k? Does the same thing happen on x86 & x86-64?

This happens on both AROS x86 and AROS 68k, the reason in my opinion is a bug on Wanderer

[magorium]

It reminds me of a command line tool I was going to write called "Icon info" to do basically what you described - reading through the icon data while checking the file.

My tool started out as a test to 're-create' LFORMAT parameters. e.g. Initially the tool was used to extract detailed information from an icon which could then be used in a LFORMAT parameter so that for example you could list dimensions of all icons (recursive search) just as the LFORMAT parameter does for the list command.

The tool never matured into something publishable though, as it is pretty specific. I just wanted to have something that i could use outside AROS, eg without depending on OS API.

It shouldn't be confused with "Icon Information" such as with Magellan. But I also wanted to extract the "Icon Information" code from Magellan to make a standalone application just for the fun of it.

Nah, I understood you there  There are enough icon tools out there to make you nauseous.

But there is only so much time in the day & I already have several projects to work on. They never seem to be done.

Likewise. I'll see if I can dust off some more  of my old code.

This is the source code for Icon Clone. Inside you will find the two functions to read classic icons.

Very much appreciated. Thank you.

In addition I used these for reference:

hmz.... the krashan link does not seem to work for me. Is it that i just stumbled on the fact that his server is down, or i need an account to be able to view it or that the link is invalid ?

fwiw I use more of krashan's work but can't remember having seen something about icons.

The evillabs wiki is also a good start. Additionally i use the AROS, AMIGAOS4 and MORPHOS SDK's as well as the original powericons information in http://aminet.net/package/util/wb/PowerIconsSrc. There is also a newicon archive but that does not seem to contain much (for us programmers) relevant information other then some very basic information.

[magorium]

Not sure why that happens. Is it AROS 68k? Does the same thing happen on x86 & x86-64?

This happens on both AROS x86 and AROS 68k, the reason in my opinion is a bug on Wanderer

Hmz... i think i disagree that it is a bug of wanderer.


I mean... what do you actually expect to happen when you store a icon to the root of a device and name it disk.info ? The original icon perhaps might not be an actual device icon but i can fully understand that in such case the workbench (replacement) automatically designates it as such.


That it isn't the same behaviour as on classic AmigaOS is imho not necessarily a bug, just other behavour.