AROS World Exec
Development => AROS Software Development => Topic started by: miker1264 on July 27, 2022, 08:27:20 AM
-
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).
-
Thank you Miker :)
-
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, 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. ;)
-
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).
-
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
-
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.
-
@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.
-
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:
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:
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
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:
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.
-
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
-
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?
-
@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
-
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
-
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.
-
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.
-
No on Amiga OS3 this does not happen, the two icons are different and distinct, and cannot beinterchanged, I will do further testing with all OS3 !
-
That it isn't the same behaviour as on classic AmigaOS is imho not necessarily a bug, just other behavour.
In my opinion it is not correct, an icon should maintain its state always in any position !
-
That it isn't the same behaviour as on classic AmigaOS is imho not necessarily a bug, just other behavour.
In my opinion it is not correct, in the Def icons, I purposely used disk icons, saved as folder, otherwise I had problems, as soon as I remember I write it down
Maybe start another Topic about Icon Types. :)
-
As far as Icon Toolbox the next Icon App is Icon press.
It "presses" two images together to form an icon. It supports Drag-n-drop & uses the same basic layout as IconClone.
It has two display areas, left & right. But the middle buttons have moved to the bottom. It only supports Drag-n-drop. There are only two buttons: "Save ARGB" & "Save Icon".
It uses the basic layout of IconClone but it is more complicated as far as the code behind it. First we can drop either icons or images rather than just icons as before.
It can be divided into two main parts to finish writing it. The fist part is to drop icons or images & display the images. The second part is more difficult. It is about composing & saving icons which requires several new techniques including Datatype Conversion & Neuquant Color Quantizing. There are two main display functions & two main save functions. These are Display_Icon & Display_Image. Save_Icon & Save_Classic_Icon.
-
This is the thread where I will document the Icon Apps included in Icon Toolbox. Again, Icon Toolbox will be a ButtonBar App Launcher for various Icon Applications.
After Icon press & Icon Split I will probably assemble another Icon App called "Icon Make". I try to keep the names simple & easy to remember. Icon Make may not be useful for everyone but Icon Artists who make hundreds of icon images may appreciate it. IconMake may also have a built-in Progressbar. We'll see how that goes.
Icon Make will have a similar GadTools user interface with buttons & text boxes. Given a folder full of pairs of PNG numbered icon images & an IconList text file with base names it will quickly process the paired images to produce PNG Icons. It's as easy as a few steps to setup the process.
Whereas it takes a few minutes to edit the IconList text file & then select the Input Folder & Output folder the rest is very fast. If you were to assemble four hundred icon images to make two hundred PNG Icons by hand it would take several hours. But IconMake can assemble them in less than two minutes. I know it can. I've already done it. :)
When I say I need to "assemble" IconMake that's because the working code already exists. I wrote it a few years ago.
I hope someone finds it useful.
I would use IconMake to assemble all the Colored Drawer Icon Sets that I will produce with another small icon app called "Icon process" which uses BaseImages & Icon Masks to make hundreds of colored icon images. Both apps are part of Icon Batch Processing. Using "Icon Process" I can also specify the color of Glow Border. So far we can select "Gold Glow" or "Blue Glow" or "Green Glow". I have tried other colors but these work best. I can change the color of the glow border using HSL Color Shifting. I discovered that a while ago.
It's appealing to have a Charcoal Grey Iconset with neon blue glow borders. Surprisingly Orange Drawer Icons with neon blue glow borders are also quite nice! With the Colored Iconsets I will put together some colored Themes for window borders & icons. The "Big Cats" background with different color variations is particularly interesting. But you can experiment.
The last small icon app after that will be "Icon Color" which will change the Tint of PNG Icons using HSL Color Shifting.
Of course I would check with the original author for Ken's Icons before posting any new Colored Drawer Icons.
-
Very useful tools that do not exist on any platform :)