icon.library 46.4 test versions

[Retrofan]

Originally Posted by PeterK

Alright, I'm glad that you could sort it out and it can be fixed.

But don't build your new distro based on AmiKit X or XE, there are still some restrictions for the distribution as explained in my IconLib.guide.

I'm still in the first chapter . Nope, it's just for me, thanks. BTW I've fixed the Execute problem, post above edited.

[AMIGASYSTEM]

Originally Posted by Retrofan

Ajem I have the idea that "Resident Execute Remove" didn't help much in the S-S

Why do you want to disable the new "Execute" which works fine on OS 3.9?

In any case if you have mixed the two systems you will have other problems with the request of the new v47 libraries that OS 3.9 will disable, also you will have to choose which localization fle use, the local folder OS 3.9 is incompatible with OS 3.2 and vice versa.

[Retrofan]

Originally Posted by AMIGASYSTEM

Why do you want to disable the new "Execute" which works fine on OS 3.9?

In any case if you have mixed the two systems you will have other problems with the request of the new v47 libraries that OS 3.9 will disable, also you will have to choose which localization fle use, the local folder OS 3.9 is incompatible with OS 3.2 and vice versa.

You didn't understand. I had that file in the S-S to disable Execute, now I don't so I load it from the rom like it has to be.

OS3.9 won't disable anything; it's files now have been overwritten with the OS3.2 ones. I like to have it to use some options it adds.
I don't get what you say about the Local folder. In any case the preferences have been installed by OS3.2.

[AMIGASYSTEM]

If all OS 3.2 Apps work, especially TxEditor and if "Scout" shows you the Workbench.library v47, Mathieeedoubas 47, Matiedoubtrans 47, and many other v47's ... then you have done a good job.

If you have v45 libraries then OS 3.9 with its Startup has replaced the KickStart 3.2 libraries.

Regarding the local folder, have you tried to run a native OS 3.9 App in a language other than English? e.g. Spanish, French etc...

[Retrofan]

Originally Posted by AMIGASYSTEM

If all OS 3.2 Apps work, especially TxEditor and if "Scout" shows you the Workbench.library v47, Mathieeedoubas 47, Matiedoubtrans 47, and many other v47's ... then you have done a good job.

If you have v45 libraries then OS 3.9 with its Startup has replaced the KickStart 3.2 libraries.

Regarding the local folder, have you tried to run a native OS 3.9 App in a language other than English? e.g. Spanish, French etc...

About TxEditor I keep using EditPad and it works as usual. Editing text from the S-S, yep, it has changed.... It's Ed 47.2
The libraries are all 47's ones:

And about the language, I always install English only, so I don't find any problem by now.

[AMIGASYSTEM]

Originally Posted by Retrofan

About TxEditor I keep using EditPad and it works as usual. Editing text from the S-S, yep, it has changed.... It's Ed 47.2
The libraries are all 47's ones:

"If you installed OS 3.2 on top of OS 3.9" is then "replaced" also the Startup-sequence it is normal that you have all the v47 libraries,.

If you are using the OS 3.9 startup-sequence, you are missing some v47 libraries, you can check this with Scout, see screenshot.

With VersionWB you have only shown the physical version and not the resident version that the system uses.

And about the language, I always install English only, so I don't find any problem by now.

There are many users who like to localize their Amiga in their own language.

[PeterK]

Originally Posted by Retrofan

I've found the problem
It's a program. One that I launch from the WBStartup. It's the last one I could think of, but I'm also sure that the developer (one of the best) will fix it. It's LittleClock by Thomas Rapp. I will tell him.
Edit: The program works perfect with OS3.9 and also with OS3.2. It's my OS3.9+OS3.2 where it hangs the system.

I've also tested LittleClock on WB 3.1.4 and on DOpus 5.83 with some debugging tools like Enforcer and MemTracker running in the background.

LittleClock works like a charm, except that sometimes the background was not refreshed (ie. after switching screens), but after moving it a bit, everything was ok again. I could select as many icons as I wanted, moved them around or copied them into the Ram Disk, but I never had any Enforcer-Hits, Freezes or crashes. I startet DOpus5 and LittleClock manually, not by LoadWB, nor from the WBstartup drawer. I tested LittleClock just with the default settings, nothing else (looks a bit like the old AmigaOS clock).

Are you using the latest version from Thomas Rapp's homepage? Did you check different configurations (tooltype settings) of LittleClock?

The most critical situation could be a wrong moment to start it from WBStartup when DOpus5 is loaded by LoadWB. You could try to change the STARTPRI or TOOLPRI settings in the LittleClock icon. Maybe something like +1, +2, -1 or -2 could solve the problem, in case that there are critical racing conditions.

Maybe, the issues could also be caused by a datatype or an image class, or whatever LittleClock uses for changing its appearance and for loading different style images. I didn't analyze that.

@AMIGASYSTEM
I think what Retrofan did with the "Assign execute REMOVE" was ok (to delete it), because that was a line for OS 3.9 with the intention not to waste memory for a resident Execute any longer after the startup-sequence was done.

[PeterK]

Originally Posted by PeterK

Looking into the Aros 68k sources I've seen that they use ObtainDatatype() in their identify.c code of the icon.library. Maybe I can support that as an alternative to the GlobalIdentifyHook function in one of my next versions?

@AMIGASYSTEM
Hi Carlo, I've made a new Aros 68k test version for you with support for the file identification by datatypes as implemented in the icon.library of Aros. It should also work with DefIcons installed, but the datatypes are checked first, and thus have a higher priority than DefIcons. The the hidden files don't get a real icon like Aros is doing that, they just get a ghosted icon.

Edit: Aros 68k test version removed (don't spread it), because it was experimental. The final solution will be different, giving the GlobalIdentificationHook (DefIcons, Eastern) a higher priority again than the datatypes.

[AMIGASYSTEM]

Great Peter, i did a test on the fly on AROS 68k and the files are recognized even without extension, see screenshot.

Tonight when I come back from the sea I'll do a more thorough check, thanks again!

[AMIGASYSTEM]

Peter on AROS 68k with Descriptors + Datatypes, everything is perfect all files are recognized even without extension.

If you also use the DefIcons this is ignored, if I delete the Deficons Descriptors, Deficons it doesn't recognize any file !

That's okay though, AROS doesn't use Deficons

[Retrofan]

Hi Peter. Yep, it's the latest version. In fact he's so great that he created this program just under my request for something like this, so I was his happy beta tester. (Or was it only with the flip-clock?. I don't remember, but he made both. BTW, the flip-clock doesn't give any problem although it's incredible how it works).
And yep, I've tried everything: starting it later, starting it with WBRun, changing the tools included and now also your suggestions.
I'll wait for him, he will take a look. As I say, it works perfect with all of the normal OS's, but this combination is giving this unexpected problem.

I know that he saw "something", but it wasn't causing any issue as you've seen with Enforcer. He tells that "I know that there was a deadlock issue introduced and fixed during the 3.2 beta test. This issue might be related."


Well, that's an enigma for me, but I'm sure that he will find a solution

[PeterK]

Originally Posted by AMIGASYSTEM

Peter on AROS 68k with Descriptors + Datatypes, everything is perfect all files are recognized even without extension.

Great.

If you also use the DefIcons this is ignored, if I delete the Deficons Descriptors, Deficons it doesn't recognize any file !

Yes, the DefIcons tool and the GlobalIdentificationHook have lower priority, they are not ignored. The hook function is only called when no matching datatype could be found before. If there is a datatype then DefIcons is not called. But what do you mean with deleting the DefIcons descriptors? DefIcons has an ENVARC:deficons.prefs file with the type identification rules.

@Retrofan
Sorry for not checking your module list a little more yet, but AMIGASYSTEM was already waiting and then I also had other things to do. At the first glance, I only saw that you have screennotify.library v1.02 installed and I have made a note some years ago that v1.02 is buggy, but unfortunately without any details about what the issues were. Probably nothing related to your problem. Myself, I'm using v1.0 again.

[Retrofan]

Thanks
Edit: Well, Littleclock fails the same way though.

[AMIGASYSTEM]

Originally Posted by PeterK

But what do you mean with deleting the DefIcons descriptors? DefIcons has an ENVARC:deficons.prefs file with the type identification rules.

I mean the elimination of the Descriptors found in "DEVS/DataTypes" (see screenshot), which then are those that I modified on AROS x86/68k

[PeterK]

Aros 68k test version removed (don't spread it), because it was experimental. The final solution will be different, giving the GlobalIdentificationHook (DefIcons, Eastern) a higher priority again than the datatypes. That's also the way how the Aros 68k icon.library is doing it, but a proper solution is a bit more complicated, if it should give you the best of both worlds. Therefore I have to check whether Eastern or DefIcons returned a project icon only or nothing, which means that they couldn't find something better, and then the datatypes should get a second chance to determine the file type and the associated icon. It gets even more complex when the new file type identification of OS 3.2 is also in use.

[AMIGASYSTEM]

Ok thanks, don't worry I didn't attach anywhere your file, on AROS x86 DefIcons doesn't exist and neither on AROS 68k, to compensate on AROS 68k I used to use Deficons OS3 !

[PeterK]

Update to icon.library 46.4.548, 47.-1.548, 51.4.548 (experimental)

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. 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 icon 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.

[AMIGASYSTEM]

Thanks Peter, perfect file types are recognized with or without extension successfully tested also on AfA One

[PeterK]

Oh really?

I did not even test it on AfA_OS at all ! A nice surprise that it works, Carlo. Thanks for testing!

[AMIGASYSTEM]

On all systems that use AFA OS such as AfAWB, Amikit, AfA One, there is a small problem with the "MixedIcons" and "GlowIcons", practically the icons are distorted with color bars. Only AIAB AfA OS sees them well because it uses "Scalos".