Tooltypes update on NewIcons

[walkero]

In one of the applications I am working on, I deal with tooltypes and NewIcons. Unfortunately, if I get it right, the NewIcons save the image information at the same place where the do_tooltypes of the files is installed.


So, what I did was to get the new tooltypes the user provides and after that add the rest of the old tooltypes, and then write them in the icon using PutDiskObject().


The new tooltypes are written in the file but the image is lost. If I check the icon info from Workbench I see the image information as text like

*** DON'T EDIT THE FOLLOWING LINES!! ***
IM1=B?!WÑ_±Ô@0($£I4Ï_?¶2iCI¥»l·S;M§Œ®¿ÈJ5*e:mF¬ŸÇÌ9l·B1(b1(diD£FÄY®L§K7KŠŸJŠJ¿W2iD£T:-&#!b;-fµ2)!œÇ[M6kF#!`M6kP($")$b=nžSºÅËo
IM1=ožÄÉdB0ÃY<§+%biD£OÈÌÏŽQ©µR9(¥J5d³Q9\¯OI¥»YÍÏ_c²Á¹T:.°OšŽÂɲ0hD>/'`Ö
IM1="$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(0@a"$(

My question is if there is a specific way the NewIcons' tooltypes should be saved, so to keep the image data? Is there an easier way to deal with tooltypes, like clear all the old, add new and don't care about the image data, if there are any?


Thank you guys for your help and time.

[thomas]

I think there must be an empty line before that DON'T EDIT... line.

And the whole thing must be at the end of the tooltype array.

And of course you have to keep it all intact. IIRC all those IM1= and IM2= lines have the same length. So your quote here looks somehow damaged.

[walkero]

Thank you Thomas for your response

I think there must be an empty line before that DON'T EDIT... line.

Maybe I missed adding that. So this is crucial for the image to be shown, right? If that's the case, do you know why is it before the "*** DON'T EDIT...." line?
Is there a possibility that the image will break if there are extra lines after the image text?

And of course you have to keep it all intact. IIRC all those IM1= and IM2= lines have the same length. So your quote here looks somehow damaged.

I am not sure what kind of info the NewIcons store, but if I understand it right, the width of those lines might be wrong because some hex codes might not be able to be presented as text.

What I am doing is getting the new tooltypes into the tooltype array and then adding the newicon tooltypes from the "*** DON'T EDIT...." line until the end of the data. My what I need to do is to make sure the line before the "*** DON'T EDIT...." line is there and if it work with it.

Do you believe there should be a better way to do things like that in the OS3 NDK? I mean, WB already know about the different icons, and the way to manipulate them should be already implemented, right? Having a way to save new tooltypes in a more secure way I believe would be necessary, especially in situations where the user is free to change all the tooltypes as he likes. So, would it make sense for the PutDiskObject() make sure the NewIcons are not deleted, and when you get the ToolTypes from such an icon, you should take only those, and not the image data.

I understand that the NewIcons are something like a hack, but it would be nice in my opinion to have methods that make sure these data are not overwritten. Just an idea.

[Steffest]

I happen to have written a newIcon decoder just this week.
There's not really a cast-in-stone spec but my take:

The Empty line before "*** DON'T EDIT THE FOLLOWING LINES!! ***" seems to be always there, but not really needed in all cases. At least according to the AROS source it's OK to leave out, but to be on the safe side I would just leave it in. (ref: https://github.com/aros-development-.../diskobjNIio.c )

The IM1= and IM2= lines are not always of the same length.
The first line contains the size, transparency and the palette, the other lines are Image data.
So the first line will probably differ in size, the last line as well.
The other lines will always be 127 chars before decoding.

To answer your question: If you want to keep the NewIcon, then yes: just copying the tooltypes (including the empty line) should keep the icon intact
(But as Thomas mentions: something in your example looks off, so you may want to double check your saved tooltypes are binary exact from the original)

The more sane approach IMHO would be to convert the icon to ColorIcon/GlowIcon format though ...

[PeterK]

If you use icon.library v44+ it will automatically cut off the NewIcon tooltypes from the array and stores them internally. So, in IconInformation, SwazInfo, RAWBInfo etc. you won't see these NewIcon tooltypes anymore on OS 3.5+. Saving usually creates OS 3.5 icons.

GetIconTagList() returns a DiskObject structure with a pointer to the do_tooltypes array, but without the NewIcon tooltype strings.

You should better use PutIconTagList() when you want to write your DiskObject structure with the new do_tooltypes array back to disk. There are some tags (see autodocs) to control the creation of NewIcon or OS 3.5 images:

	ICONPUTA_DropChunkyIconImage (BOOL) -- This tag can be used to
	    keep the chunky icon image data from getting written
	    to disk.

	    This tag defaults to FALSE.

	ICONPUTA_DropNewIconToolTypes (BOOL) -- This tag controls whether
	    any NewIcon tool types will be omitted when writing the
	    icon to disk. TRUE will omit the data.

	    This tag defaults to FALSE.

If you want to keep the NewIcon images then the icon.library will restore the image tooltypes automatically at the end of the array. No need to do it yourself. But I must admit that I never tried to write any program doing things like that.

[walkero]

Thank you all for your replies.
I don't have any remorse to drop the NewIcon tootypes, if that simplifies things and the image stays intact. Do you think though that this should be a user decision? I mean, should there be a way that the user approves it?

I believe most of the users won't even know what a newIcon does, or what would be the difference, but from an ethical point, should the user been asked?

[PeterK]

On WB v44+ nobody will need the NewIcon images anymore.

But users of WB/Kickstart 3.0/3.1, who still have only the old icon.library v39/40 and the NewIcons patch installed on their systems, may prefer to keep these tooltypes.

[walkero]

@PeterK
I implemented the PutIconTagList() with dropping the NewIconTooltypes which works great, keeping the image and making the info file much smaller, more than half in size. But as mentioned it doesn't work in 3.1. So I guess I should implement two solutions, and use one or the other based on the system version.

[walkero]

I was working on this today and I'd like your opinion. Since the usage of PutIconTagList() is working so well with icon.library v44+, I am thinking to make it a requirement for the application I am working on. I tested WB3.1 with the icon.library v46.4 from aminet and works fine as well.

My question is, do you see any negative points in doing so? Any reason why I shouldn't follow this way of doing things?

Thank you so much for your opinions.

[PeterK]

Good question, because I don't know what "your application" is (did I overlook something?).

Ok, I could pass away one day (... I hope real soon ...) and you won't get any bugfixes or updates after that, since sending them from hell could be difficult

[walkero]

since sending them from hell could be difficult

You never know. Only Amiga.....

These changes I am doing are on iGame, which is a WHDLoad front-end. I am working on a new update with a few needed fixes, and one of them is the update of games' tooltypes, and those might have a NewIcon.

[PeterK]

Excuse me for my ignorance, not knowing anything about iGame, but that's because I never play any games, nor would I install WHDLoad or game launchers on my system.

Ok, now I've at least an idea about what your application is doing. I can't see any serious problems by using my icon.library on WB 3.0/3.1 provided that it is installed correctly as explained in the IconLib.guide.

So, you might check the version of the running icon.library and if you still find an old v39/40 instead of v44+ then ask the user to remove it from the list of resident modules by adding some instructions to his startup-sequence before SetPatch like:

 If EXISTS Libs:icon.library
    RemLib >NIL: icon.library
 EndIf

[walkero]

@PeterK
No, there is no problem using your icon.library. On the contrary, I tested on many systems and I promoted it on the streams I did in the past, and people can find it on YouTube.

Yesterday I tested it with an AmigaOS 3.1 installation and it worked great.

For me, for simplifying my work and fixing all the problems dealing with icons, I would prefer everyone to have that installed, but unfortunately, that is not the case. So, what I wonder and am discussing here is if a program, like iGame, should request the users to update their library or not. My question is more of a "good practice" point.