View Single Post
Old 20 May 2021, 00:33   #238
PeterK
Registered User
 
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,366
Quote:
Originally Posted by boemann View Post
Deficons is that engine - it is all it does - it provides the type. When icon lib finds a default icon it asks deficons for the type and the loads the corresponding icon from envarc:sys
There is a "GlobalIdentifyHook" for icon.library as defined in the autodocs under IconControlA(). In the past this hook function was called by icon.library whenever it could not find an icon for a file and a tag "ICONGETA_FailIfUnavailable"=FALSE was supplied by the calling task.

On the other side, this hook is used by DefIcons and Eastern, which are trying to identify the file and then return a ready to use DiskObject structure to icon.library. No, - at this point - icon.library has not to load an icon from ENV:sys anymore.

Usually, DefIcons identifies the type of a file and makes another call to icon.library for the corresponding icon in Envarc:sys already before it returns the result to the hook.

Eastern tries to identify pictures only, generates thumbnail images for new empty DiskObjects, and sends both for assembly to icon.library also before it returns the picture preview icons back to the hook.

The new "IdentifyBuffer" and "IdentifyOnly" tags can be forwarded now by icon.library to the hook, no matter whether the file already has an icon or not. Icon.library never returns any strings. The "IdentifyBuffer" for the string is created by the calling task, forwarded to the hook and filled by DefIcons.

But unlike the new DefIcons tool the old Eastern has no support for these tags yet. Eastern must examine the file first to identify pictures and supply preview icons instead of deficons. Thus, it only passes the hook data to DefIcons for other files than pictures, and it won't forward these two new tags otherwise. (Maybe, I will try to write a fix for Eastern ?)

Edit: I didn't read the posts #237 and #238 before starting to write my comment. Yes, I also think that passing the file type identification through icon.library is not the optimal solution, but I'm no OS developer, don't want to criticize or decide that. I'm just trying to support these new features.

I don't own OS 3.2 yet, but I've written a small test program to check this new file type identification:
Attached Files
File Type: zip FileType.zip (1.3 KB, 133 views)

Last edited by PeterK; 20 May 2021 at 01:21.
PeterK is offline  
 
Page generated in 0.04505 seconds with 12 queries