icon.library 46.4 test versions

[PeterK]

No thanks

What exactly do you need to be translated (don't say the requester), which word is too difficult to understand it and to check its meaning ?

The thingy is done now, finished

[HanSolo]

Difficult ? No, but I have entire system translated to my native language, it 's just look like something is not right. Nevermind, thanks for your work.

[daxb]

I found only one text (see below) that seems to be requester text. Just load the icon lib into a hexeditor and change it to your needs. Then check if it works and nothing is broken.

PNG Icon Snapshot==>  %s

Snapshot will convert
your PNG icon into the
standard OS 3.5 format!

Do you want to do that?
Yes, this icon|Yes, always|No

[PeterK]

If you want to change the text (but not the order and the %s placeholders), you can simply take any hex-editor and modify (translate or shorten) the strings starting at offset $584E. The button text starts at $58DE and ends at $591A, all in one string with "|" signs working as separators. Of course, every string has to be terminated with a $00 character finally.

@daxb
Are you still using that old and outdated icon.library ?

[daxb]

The text I found comes from an old (last year) icon.library version. It was the last one I tested (speed measure). And no, I still "use" icon.library 40.1.

[Michael]

40.1 ? Nostalgia ?

Also the source is provided, it's easier to edit the strings in it and assemble it getting the proper version for your language if you need to, also in normal use you should not see the requester anyway.

[Michael]

Final 46.4.409 full version on AmiNET!

[zharn]

Nice Work

[Leandro Jardim]

Hi, I am not sure if this is really a bug in the IconLib version on Aminet, when I use FBlit and enable drawing icons in Fast RAM with Workbench Preferences tool, any DefIcon temporary icon I drag with the mouse disappears while moving the mouse pointer.

I use "C:WBCtrl IMT=FAST" in startup-sequence, and for the icons, I enable only the option in FBlitGUI for "QBSBlitPatch". Everything else, is set to the defaults.

Do you have any clue whats wrong with it? Do not worry to ask.

[PeterK]

So, you are using WB 3.9 without a gfx-card, just AGA, right ??

You don't need "C:WBCtrl IMT=FAST", setting Workbench preferences to "Other Memory" is enough.

If you enable QBSBlitPatch, which is correct for WB 3.5+, then you also have to disable AddBobPatch and RemIBobPatch. And make sure that the task "Workbench" is in your include list.

Or simply try out my FBlit.cfg file for WB 3.5+ from my icon.library archive.

Do not worry to ask.

May I ask you for some feedback ?

[PeterK]

Update to icon.library 46.4.410:

This is a fix for FBlit when dragging ghosted DefIcons on WB 3.5+. It inverts the mask for the 50 % transparency to avoid that FBlit's dragging mask makes the icons invisible.

[Leandro Jardim]

Thanks PeterK, it works flawlessly.

[matthey]

Hi Peter,

I have a few suggestions and ideas.

1) Is it possible to recognize a "NoGhost" tooltype for default icons which would keep just that icon from ever being ghosted? It could be useful for testing as well as avoiding special handling of the ram disk icon during boot. If it is too difficult then never mind.

2) It should be a little faster to longword align longword data in the icon.library structure. The library structure is not longword aligned so there could be a small benefit to adding a word of padding after it. For example:

; $00 $22 struct library <- Warning: size is not a longword multiple!
; $22 $2 word padding <- we are longword aligned after this
; $24 $4 segmentlist
; $28 $4 execbase
...

Perhaps this would save a cycle from 68030 DCache longword reads? I believe the 68040/68060 would avoid the DCache read penalty unless a cache line is crossed. Write penalties are larger in all cases but they are less important for the commonly used xxxBase offsets. I doubt any difference in speed would be noticeable but it it a good idea to align data to their natural sizes, even on the forgiving 68k. The "padding" could be used for miscellaneous flags of course. I see now that you are not using symbols for the offsets in the icon.library structure so this might not be too easy.
Edit: The SignalSemaphore structure size is not a longword multiple either.

3) How about changing the English requester text from this:

PNG Icon Snapshot==>  %s

Snapshot will convert
your PNG icon into the
standard OS 3.5 format!

Do you want to do that?
Yes, this icon|Yes, always|No

to this:

PNG Icon Snapshot==>  %s

Should snapshot convert
your PNG icon into the
standard OS 3.5 format?

Yes, this icon|Yes, always|No

It looks better to me and saves a few bytes. Both are easy to understand IMO. You could capitalize the "snapshot" if you think it needs emphasis although I think lower case "looks" better.

[Retrofan]

I just would delete that request saying it will convert the icons. You know it will always do as long as you snapshot them in a drawer, like we all make from time to time.

[James]

Originally Posted by matthey

3) How about changing the English requester text from this:

PNG Icon Snapshot==>  %s

Snapshot will convert
your PNG icon into the
standard OS 3.5 format!

Do you want to do that?
Yes, this icon|Yes, always|No

to this:

PNG Icon Snapshot==>  %s

Should snapshot convert
your PNG icon into the
standard OS 3.5 format?

Yes, this icon|Yes, always|No

It looks better to me and saves a few bytes. Both are easy to understand IMO. You could capitalize the "snapshot" if you think it needs emphasis although I think lower case "looks" better.

Sorry, but IMHO the first reads:

A snapshot WILL convert your icon, do you want to continue?

The second reads:

Would you like snapshot to also convert you icon?

I would still expect the snapshot to work when replying no in this case.
If the message is changed I would prefer to see something like this:

Snapshot will convert
PNG icons to a lower
quality OS 3.5 format!

Continue?
Yes, this icon|Yes, always|No

Originally Posted by Retrofan

I just would delete that request saying it will convert the icons. You know it will always do as long as you snapshot them in a drawer, like we all make from time to time.

Not warning people they are about to reduce the quality of their icons would be very bad form IMHO...

[Retrofan]

But people want to snapshot their icons, and to retain the quality they only could do using AfAOS. That's my thought.

[Arnie]

I just updated the icon.library to 46.4.410 and this happened? Any Ideas what's gone wrong.

Running on WinUAE A1200/030 OS3.1

EDIT: 68000 version works O.K but colours are washed out.

EDIT2: Just remembered I used the one from the ADF first, that one works, it's the 020 versions that cause that effect.

iconlib 020

iconlib2 from adf

[matthey]

Originally Posted by James

Sorry, but IMHO the first reads:

A snapshot WILL convert your icon, do you want to continue?

The second reads:

Would you like snapshot to also convert you icon?

I would still expect the snapshot to work when replying no in this case.

I see the difference now. Snapshot does not work (it is cancelled) if "No" is selected in the requester. This also explains why there is not a "Never" option. I did not understand how the requester works but I believe you are correct. Maybe the original was not as clear as I thought.

Originally Posted by James

If the message is changed I would prefer to see something like this:

Snapshot will convert
PNG icons to a lower
quality OS 3.5 format!

Continue?
Yes, this icon|Yes, always|No

It looks good to me although I would remove the "will" and change the "convert" to "converts". I do prefer the "Continue?" over "Do you want to do that?"

PNG Icon Snapshot==> %s

Snapshot converts PNG
icons to a lower quality
OS 3.5 format!

Continue?
Yes, this icon|Yes, always|No

Originally Posted by James

Not warning people they are about to reduce the quality of their icons would be very bad form IMHO...

Perhaps. Many attributes of the icon change, some good and some bad (size, speed, quality). I have been impressed with the lack of quality loss in the few conversions that I have done. I consider "a lower quality" as optional depending on what other people think, especially Peter .

[Retrofan]

Well, I am "colorblind" (I've got daltonism), but I only notice a line in the borders and a couple of pixels. But as I say you can't snapshot those icons with the icon.library mantaining the format, so why do you want that annoying message?

This is a screenshot with the same drawers in both formats:

[James]

Originally Posted by matthey

It looks good to me although I would remove the "will" and change the "convert" to "converts". I do prefer the "Continue?" over "Do you want to do that?"

Yes, even better.

Originally Posted by matthey

Perhaps. Many attributes of the icon change, some good and some bad (size, speed, quality). I have been impressed with the lack of quality loss in the few conversions that I have done. I consider "a lower quality" as optional depending on what other people think, especially Peter .

Yes, "a lower quality" probably sounds way too negative, maybe it could be replaced with "8 bit", or as you say, dropped altogether... PeterK's opinion is the only one that really counts in this matter.

Originally Posted by Retrofan

But as I say you can't snapshot those icons with the icon.library mantaining the format, so why do you want that annoying message?

On most systems that will only ever use PeterK's icon.library it is usually desirable to convert all icons because of the size and speed improvements Matthey mentioned, and the fact that they will never be displayed at full quality anyway. I have done this on my A1500, and I can understand why you see the message as a nuisance. But once they are converted you should never see the message again, and there are times when the message can be important in preventing unwanted conversions. I use AfA on WinUAE, but I sometimes have to fall back to using icon.library due to a few incompatibilities, and there has been at least one occasion where I forgot about the snapshot conversion and was saved from converting several icons by that message.