icon.library 46.4 test versions

[PeterK]

Carlo, that sounds like the old AfA_OS problem with the different image sizes.

Edit: With my option "FakeIconSizeForAfA" I didn't have these corrupted Glow images.

2. Edit: Confirmed! AfA_OS damages the planar images as usual. The first MWB image has a trashed line at the top, the second image is completely garbage! That's AfA, sorry Carlo.

[AMIGASYSTEM]

Strange that with AfA OS + Scalos (AIAB) the icons look good !

"FakeIconSizeForAfA" doesn't seem to work, anyway it is not a problem, AfA OS uses the DualPNG that are the most qualitative and more beautiful Amiga icons

I confirm that icon.library.46.4.548_Aros works fine on AROS One !

[PeterK]

"FakeIconSizeForAfA" can only fix the (True)ColorIcon images, not the planar images. And that works.

But, of course, you can not use the IconMixer for PNG icons, because PNG can't store the planar icon images.

You have to convert your icons with "ConvertPNGtoOS4" before trying to add MWB or old images. "Reduce8PlanesTo3" is also recommended.

[AMIGASYSTEM]

Thanks for the info Peter, normally on AfA One and AROS One i create and use only DualPNG icons.

[Retrofan]

Originally Posted by PeterK

... What is the shell-seg version for example?

BTW, I've sent you an email. I hope that you keep having the one I have.

Edit: Resident libraries with Scout:

[Retrofan]

Peter, I've heard that OS3.2 has some problems with AfAOS, so for example AmiKit can't use it. What's the problem about exactly, do you have an idea?. Excuse me because it surely won't be related to icons, but.... you know much more.
Also, I don't know what do you think, but what I would like to have is a new OS3.9 without Boingbags, just an updated and new OS 3.10 working version.

Edit: Please search for my email.

[AMIGASYSTEM]

Sorry Peter if i annoy you with my reports !

On AROS 68k with icon.library 46.4.548 when I open a window or a folder I get an error, see screnshot.

The problem is more frequent if you open a window or a folder when the system has not finished loading Wanderer.

With the experimental icon.library v46.4.547 the problem does not exist, at the moment everything works perfectly without ever receiving that error.

[AMIGASYSTEM]

Originally Posted by Retrofan

Peter, I've heard that OS3.2 has some problems with AfAOS, so for example AmiKit can't use it. What's the problem about exactly, do you have an idea?. Excuse me because it surely won't be related to icons, but.... you know much more.

Edit: Please search for my email.

AfA OS will never work with OS 3.2, the AfA_OS_Loader command is not supported by some v47 libraries including the intuition.library.

[indigolemon]

Originally Posted by AMIGASYSTEM

AfA OS will never work with OS 3.2, the AfA_OS_Loader command is not supported by some v47 libraries including the intuition.library.

Or more accurately, the hacks that AFA needs to carry out no longer work due to the changes and improvements made in the newer libraries. The only reasonable fix would be for AFA to be updated to work with the newer libraries.

@PeterK - testing 46.4.548 under 3.2, no issues so far (using Eastern which is also working well with it).

[AMIGASYSTEM]

Originally Posted by indigolemon

The only reasonable fix would be for AFA to be updated to work with the newer libraries.

This is unlikely to happen, but I think you can also do the opposite.

In my opinion it's not sure if it's AfA OS fault since AfA OS installs perfectly on OS3.1, OS3.1.4, OS3.5, OS3.9, OS 3.9 BB4 and Amithlon

[PeterK]

Originally Posted by Retrofan

Peter, I've heard that OS3.2 has some problems with AfAOS, so for example AmiKit can't use it. What's the problem about exactly, do you have an idea?. Excuse me because it surely won't be related to icons, but.... you know much more.
Also, I don't know what do you think, but what I would like to have is a new OS3.9 without Boingbags, just an updated and new OS 3.10 working version.Edit: Please search for my email.

Hi Retrofan, thanks for your email, I've already sent a reply, but still didn't analyze your LittleClock problem, which is a bit difficult without having the same system.

Concerning OS 3.2, AfA_OS and Amikit I first have to say that I don't use any of them, except that I can switch my OS 3.9 + 3.1.4 system into an AfA_OS mode for test purposes, but not because I would like to do that. AfA_OS may offer some nice GUI enhancements (eye candy, which I never needed), but it also comes with a huge bunch of deep system patches and replacements (MoreLibSpace, AfA_OS_LIBS), which are integrated in a very special way into the AmigaOS, IMHO not really system friendly. That can easily cause conflicts when the OS gets updated, but I don't want to blame AfA_OS, nor OS 3.2, as long as I don't know exactly where these conflicts originate from. I have no idea what happens when you try to install AfA on 3.2 or update the OS on top of AfA? AmiKit is even more patched and not my favorite system either, as you may know (I have no installation anymore since 2016). No, an OS 3.10 as an update to 3.9 will never come, but you can get Windows 11 soon.

[PeterK]

Originally Posted by AMIGASYSTEM

Sorry Peter if i annoy you with my reports !

On AROS 68k with icon.library 46.4.548 when I open a window or a folder I get an error, see screnshot.

The problem is more frequent if you open a window or a folder when the system has not finished loading Wanderer.

With the experimental icon.library v46.4.547 the problem does not exist, at the moment everything works perfectly without ever receiving that error.

Carlo, I'm never sure whether my icon.library or Aros is causing these crashes as long as I can't reproduce them with some debugging tools running. My Aros 68k is not up to date, but I didn't have these problems. From time to time I still have Enforcer hits from the Aros library and device loader, some serious bugs in the Aros ROM code. I noticed these bugs already when I played with Apollo OS last year and sent reports to Pedro Cotter, who has contact to the Aros developers.

How do you open a window as long as the system has not finished loading Wanderer? I would need a download link for your Aros 68k system to have a chance to reproduce that bug.

Btw, I noticed that Eastern tries to find the "Workbench" task and thus it stopped working on Wanderer. I've patched Eastern in oder to look for "WANDERER:Wanderer" now and then it starts working at least. But it only shows some preview frames for the pictures and displays no thumbnail images, does nothing anymore. The strange thing is, that on OS 3.9 it runs in the context of the Workbench task, but on Aros it opens the pictures as "Eastern_task". There is something different with the implementation of the hook, the datatypes.library or the picture.datatype. Trying to replace the datatypes.library or the picture.datatype lets the system hang at boot time or it complains about wrong versions.

[PeterK]

Originally Posted by indigolemon

Or more accurately, the hacks that AFA needs to carry out no longer work due to the changes and improvements made in the newer libraries. The only reasonable fix would be for AFA to be updated to work with the newer libraries.

Yes, that's right, but there's little hope that Bernd Roesch will still do that.

@PeterK - testing 46.4.548 under 3.2, no issues so far (using Eastern which is also working well with it).

Thanks for the feedback. On OS 3.2 with the new DefIcons v47 the datatypes will probably rarely be used to identify file types. I just wanted to make this possibility available in all versions, although Aros 68k should benefit most, and it's critical to hear that there are still issues. That needs more investigations.

[PeterK]

Update to 548 removed, ReleaseDatatype() used a wrong argument!

Thanks for the bug-report, Carlo !

I've made a fix, please test that, too.

Also included is my modified Eastern for Wanderer (it will not work on Workbench), but it still doesn't work on Wanderer as it should. The tooltype "PROGRESSIVE=NO" is rejected with the error: "Wrong number of arguments", but on AmigaOS I really need that to avoid some strange behavior of Eastern. I also tried to change some settings in ENVARC:datatypes/picture.prefs, but without success.

Eastern could at least display one small picture successfully (the CBM logo), maybe it has problems to scale larger pictures with the picture.datatype of Aros 68k ?! Enforcer showed some hits for Eastern too, which I could try to analyze next.

[AMIGASYSTEM]

Peter 46.4.549 seems to work fine, at the moment I haven't found any problem, only the lack of replacement of the RAM Icon, this is not a problem.

Eastern also shows me only the gray boxes, if you click Multiview it shows correctly the image, see screenshot, without Eastern the def_icon is assigned according to the image format.

[PeterK]

Ok, maybe I've damaged something in the Ram Disk synchronization, too? I will check that later.
Edit: No Carlo, I still get the icon from ENV:Sys/def_Ram.info, can save the position and the window data. But my library reads from ENV:, not from ENVARC: like Aros! Or what is your problem with the Ram Disk icon?

Btw, I've renamed the modified "Eastern" for the Wanderer task into "Western" now to avoid confusions. And that Western seems to be able to display preview icons on Wanderer as long as the pictures are palette based with 256 colors. It still cannot display TrueColor pictures and won't scale the preview images, but just cut them off at the maximal size. That needs more investigation about what the differences and limitations of the Aros 68k picture.datatype are compared to OS 3.9 or newer.

You have to update the window contents after the gray boxes appeared there! And the first picture with a "wrong format" (TrueColor) stops the loading of Western.

[AMIGASYSTEM]

To me 8Bit images are displayed even without renaming "Eastern".
I also tested a version of picture.datatypes created by miker, the result is the same.

Regarding the RAM Icon problem, testing a "Nightly Build" I thought that the new library read from ENVARC, then as on AROS One I inserted the command "Assign Add ENV: ENVARC:" in the User-startup and the RAM icon was restored.

[PeterK]

Update to icon.library 46.4.549, 47.-1.549, 51.4.549 (bugfix for 548 and small improvement, delete 548!)

Added the ability to identify files by the datatypes system as a 2. chance to determine the names of default icons in case that DefIcons or Eastern didn't do that or supplied only a standard Project icon. The datatypes will try to load an icon corresponding to the (internal) datatype name, for example something like ENV:Sys/def_JFIF.info (use SnoopDos), or in case that this icon doesn't exist, they also try it with the GroupID name again, or finally they load the project icon. There are 9 groups: System, Animation, Document, Instrument, Movie, Music, Picture, Sound and Text. So, in my example, the jfif.datatype would also try to load ENV:Sys/def_picture.info. On WB 3.0/3.1 this new feature won't work for the Workbench task, because that never calls GetIconTagList() with a file name. But a few other tools like SwazInfo may benefit.

There are 2 script based IconMixers included (using ProcessIcon) which can combine (True)ColorIcons with the planar images of MWB or old icons. The mixed icons will contain both image sets. One script keeps the MWBIcon settings, the other one retains the GlowIcon tooltypes. My option "Reduce8PlanesTo3" might be useful for getting correct looking MWB images and without wasting space. PNG icons have to be converted with "ConvertPNGtoOS4" before adding planar images to them. Disable the options "DropPlanarImages" or "DropPlanar" in tools like RAWBInfo or CopyIcon. The mixed icons get damaged by AfA_OS, don't use these scripts there.

[PeterK]

Update to icon.library 46.4.550, 47.-1.550, 51.4.550

On DOpus5 and WB 3.0/3.1 with native screen modes the OS4 and PNG icons are now also a lot faster, similar to the former speed improvement for WB v44+ and Aros Wanderer in my Aminet release. Again, this concerns the TrueColor library versions only, not the 68020 and 68000 version. But you can use TC020 or FastWB instead of the 68020 version without having a graphics card installed.

Btw, I've noticed that on systems with native screen modes and FBlit running it can happen that a program suddenly calls Picasso96API.library, although there is no P96 monitor installed, and if the other P96 files are on the system, it may load the cybergraphics.library, emulation.library and rtg.library too and installs several patches over the graphics.library functions, which may disable my icon.library patches and can cause conflicts with FBlit. My library detects this now and installs its own patches "once" again, because DOpus5 and WB 3.0/3.1 need them. This works, but the remaining P96 conflicts with FBlit at least seem to cause more flicker when you drag icons around. Ok, usually nobody has P96 files on the disk when he uses FBlit, so this will rarely happen.

Update: Sorry, I've forgotten to check and care for one special case: On WB 3.0/3.1 HAM screens the OS4 and PNG icons have correct looking HAM images, but the dragging of these icons shows just two lines of black pixels, because that image data has not been updated just in time yet. No such problem on WB v44+ or DOpus5. Will be fixed in the next version.

[hexaae]

@PeterK
I've found an issue in general with Workbench 3.1+ when using Copy menu function to create Copy_1_name, Copy_2_name etc.. if you have just .info file and no associated file.
The Workbench (+AsyncWB) gets confused and says it cannot overwrite Copy_of_name when you use Copy more than once on an icon/info file only.

Since you're the author of this wonderful icon.library + also patched in the past workbench.library 45.132 (OS3.9) I thought was the right place to report it