icon.library 46.4 test versions

[hexaae]

Originally Posted by PeterK

Come on, you should know why I'm always using 46.4 for Ver.Rev. Please remember the experimental check in Mike's WB 45.130/131, which did only test whether the revision of icon.library is 4 for his support of long filenames. Ok, I've fixed that in WB 45.132, but who knows , maybe some people are still using 45.130/131. You can always get the full string with "Version Libs:icon.library FILE FULL". or with Scout. And I'm using a build number by design to avoid wasting of too many revision numbers and to use "46.4" as a trade mark.
.

Well, current version in icon.libraray is: "$VER:icon.library 46.4.488 (68020)" which is not exactly standard Should be "$VER: icon.library 46.xxxx <date> <comment>" (e.g. "$VER: icon.library 46.488 (18.07.2018) 46.4 (68020)"). Nothing "important" but I like following standards.
From shell the result will be (localized):

[8.Workbench:] version icon.library
icon.library 46.488
[8.Workbench:] version FILE FULL LIBS:icon.library
icon.library 46.488 (18-July-2018)
46.4 (68020)

and contain all needed info respecting standard. I know... I'm a picky guy… but why not following standards?

[kolla]

Yes, the lack of date is what kinda breaks my routines with this library.
I think "$VER:icon.library 46.4 (18.07.2018) build 488 (68020)" is more like it, but hey... details

[hexaae]

Yep, just details of no real importance (Remember there should be a space after "$VER:" )
Keeping "$VER: icon.library 46.4 (18.07.2018) build 488 (68020)" would be a problem since versioning of next 46.4 build 489+ would be "the same version" for WB (46.4), see comment above about ver.rev (where rev = integer progressive number).
Maybe PeterK can use: "$VER: icon.library 46.488 (18.07.2018) build 46.4.488 (68020)" to make everybody happy:

[8.Workbench:] version icon.library
icon.library 46.488
[8.Workbench:] version FILE FULL LIBS:icon.library
icon.library 46.488 (18-July-2018)
build 46.4.488 (68020)

[kolla]

Yes, but that is kinda the point here - this library is 46.4, it is not supposed to progress beyond that, it is supposed to one day end up in a 46.4 final - we are using _test versions_

[hexaae]

Originally Posted by kolla

this library is 46.4, it is not supposed to progress beyond that

Ah OK then. Makes sense in this case "$VER: icon.library 46.4 (18.07.2018) build 488 (68020)"

[daxb]

Originally Posted by hexaae

Me too… I don't ask anything too complex (like SwazInfo was), but at least decent with drag'n'drop on the tootlype area to copy tooltypes and on icon image to copy the icon, plus double-click to un/comment the single tooltype… and gadgtools based please (with mouswheel working)!

Workbench is/was ever very limited. If you want some more functional then there are alternatives. I'm using DOpus5 as WB replacement what gives me nearly everything and if something is missing you can expand it to your needs. I don't know Scalos but it could be similar functional. And my experiences is that on Amiga your life is much easier, if you don't use icons or ignore them as much as possible. Sorry for offtopic.

[hexaae]

Yep, AmigaOS SetFunction() was one of its killer features! This made the OS incredibly "moddable" and expandable.

[PeterK]

That's all just wasted time(strings) and bytes. I don't care about time and standards. V45.1 is the standard for icons, but I do not even care much about icons, similar to daxb, I prefer to use DOpus (but 4.17).

Perhaps someone should start writing a new version command, since OS 3.1.4.1.5.9.2.6... is coming soon.

[daxb]

Try this: http://aminet.net/package/util/cli/DoVer Works fine here.

[PeterK]

I know, I use Version and DoVer together for a button in DOpus4.

[daxb]

Seems you have stolen my config.

[hexaae]

Originally Posted by PeterK

That's all just wasted time(strings) and bytes. I don't care about time and standards. V45.1 is the standard for icons, but I do not even care much about icons, similar to daxb, I prefer to use DOpus (but 4.17).

Perhaps someone should start writing a new version command, since OS 3.1.4.1.5.9.2.6... is coming soon.

That's sad to read Standards make things working as expected for everyone and with every program, not following them without a strong reason is bad.

[gulliver]

Originally Posted by PeterK

That's all just wasted time(strings) and bytes. I don't care about time and standards. V45.1 is the standard for icons, but I do not even care much about icons, similar to daxb, I prefer to use DOpus (but 4.17).

Perhaps someone should start writing a new version command, since OS 3.1.4.1.5.9.2.6... is coming soon.

I also prefer DOpus 4.17.

And about the version command, it has been bugfixed and reworked a tiny bit.

[AMIGASYSTEM]

Originally Posted by PeterK

I know, I use Version and DoVer together for a button in DOpus4.

For a button in DOpus4.17pre20 i use command Dover v1.90 (1.91 ?), VersionWB v2.16 and ViewDiz v2.2 (ViewDiz in some cases it is not accurate). VersionWB and ViewDiz they have a GUI

[kolla]

I just have a script snippet that downloads from the first page on this thread and compares with what is already installed and asks me to update if newer.

[PeterK]

Update to icon.library 46.4.489:

Better support for very large icons. There were some minor problems with displaying and converting 256x256 icons. The library did always compress icons which is the better choice in most cases, but if an image is already 64 kB in size and it can not be compressed by RLE, the "compressed" image with the additional RLE bytes gets bigger than the original, although only 64 kB are allowed and displayable. The other problem were some broken ARGB icons with wrong image size information. My previous work around was not optimal for large OS 3.5 icons.

If you know any icons that are still not displayed or converted, please upload them here.

[hexaae]

I've found a bug dragging hidden icons (because window container wasn't displaying all of them) with mixed Coloricon + NewIcons:



Repro steps:

• put many ColorIcons + NewIcons into a drawer
• shrink that drawer and show only a pair of icons, not the whole contents
• RAMIGA+S (Select All) to select all drawer contents now...
• drag all icons somewhere

As you can see NIs are showing the minimal dot icon instead of the real NI images, as expected, while dragging.
Changing SYS:Prefs/Workbench settings (use fast/chip for icon images) won't help.
Non-reproducible using icon.library 45.5 (i.e. all dragged visible/hidden icons will be shown as ColorIcons + NewIcons using their full image)

[PeterK]

Nothing new. That's a known problem with Workbench using two different methods for dragging icons inside and "outside" of a window.

You can get rid of it by using my option "NoDelayedImage2", but that costs more time for icon drawing.

I've tried a lot of things to make a work around for my delayed images, but couldn't find a way to patch the dragging of the outsiders. However, nothing gets damaged, it's just not looking very nice.

[hexaae]

Ah, ok then. Thanks!

[PeterK]

Update to icon.library 46.4.490:

A new test candidate: TC020, which supports TrueColor for the OS4 ARGB icons. It can display in TrueColor with alpha channel and save in OS4 format now, but PNG is not supported yet. PNG may come later, since it's a bit more difficult to integrate. The other versions like 68020 have no new features. The icon scaling is not supported in TrueColor quality, because that would need a zlib compression routine.

Due to a bug in AfA_OS the new created OS4 icons may not be displayed by AfA's icon_lib.exe. AfA tries to read the ARGB image size from the DiskObject Gadget structure instead of taking the width-1 and height-1 values from the FORM chunk. AfA also makes ARGB icons unreadable for OS4 when the Gadget size is different to the ARGB image size. I don't want to make a work around for AfA in this case, because that would need a wrong gadget size.