24 January 2023, 23:38 | #1 |
Registered User
Join Date: May 2012
Location: Dublin/Ireland
Posts: 358
|
Tooltypes update on NewIcons
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 Code:
*** 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. |
25 January 2023, 09:15 | #2 |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 7,005
|
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. |
25 January 2023, 15:31 | #3 | ||
Registered User
Join Date: May 2012
Location: Dublin/Ireland
Posts: 358
|
Thank you Thomas for your response
Quote:
Is there a possibility that the image will break if there are extra lines after the image text? Quote:
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. |
||
25 January 2023, 17:41 | #4 |
Registered User
Join Date: Jan 2017
Location: Antwerp / Belgium
Posts: 189
|
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 ... |
25 January 2023, 18:53 | #5 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,378
|
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: Code:
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. Last edited by PeterK; 25 January 2023 at 18:58. |
25 January 2023, 19:00 | #6 |
Registered User
Join Date: May 2012
Location: Dublin/Ireland
Posts: 358
|
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? |
25 January 2023, 19:17 | #7 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,378
|
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. |
25 January 2023, 20:11 | #8 |
Registered User
Join Date: May 2012
Location: Dublin/Ireland
Posts: 358
|
@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. |
08 February 2023, 23:34 | #9 |
Registered User
Join Date: May 2012
Location: Dublin/Ireland
Posts: 358
|
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. |
08 February 2023, 23:54 | #10 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,378
|
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 |
09 February 2023, 00:56 | #11 | |
Registered User
Join Date: May 2012
Location: Dublin/Ireland
Posts: 358
|
Quote:
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. |
|
09 February 2023, 14:38 | #12 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,378
|
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: Code:
If EXISTS Libs:icon.library RemLib >NIL: icon.library EndIf |
09 February 2023, 17:29 | #13 |
Registered User
Join Date: May 2012
Location: Dublin/Ireland
Posts: 358
|
@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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
help with WHDLoad and Tooltypes | klx300r | support.Apps | 14 | 06 April 2021 18:34 |
Icon tooltypes and stuff | oRBIT | Coders. General | 22 | 23 May 2010 21:27 |
WHDLoad Tooltypes | Aljrob | project.WHDLoad | 10 | 31 March 2007 15:49 |
Assigning tooltypes to files? | Gnorman | project.ClassicWB | 2 | 06 March 2006 20:42 |
Tool to add tooltypes | MarlboroMan | request.Apps | 1 | 18 May 2005 06:29 |
|
|