icon.library 46.4 test versions

[AMIGASYSTEM]

No Peter it is a standard OS3.9 without any modification, try to install you OS 3.9 and you will get the same result.

Can anyone do some tests to confirm, thanks

[apex]

Normally a def icon is ghosted before you snapshot it.

[PeterK]

Originally Posted by AMIGASYSTEM

No Peter it is a standard OS3.9 without any modification, try to install you OS 3.9 and you will get the same result.

Can anyone do some tests to confirm, thanks

Yes, I can confirm that this happens on OS 3.9, even with the original icon.library 45.1, it appears as a project, because ENVARC:Sys/def_library.info is of the type "project" and WBStartup/DefIcons loads it.

Change the type of ENVARC:Sys/def_library.info into a "Tool" and the problem should be solved.

On my main system I don't have that ENVARC:Sys/def_library.info file, that's why it works.

[AMIGASYSTEM]

I was aware of the "wrong" assignment on def_.library, now try to delete the DefIcons from the WBStartup and you'll see that your icon.library will assign a project icon to the libraries.

[AMIGASYSTEM]

Originally Posted by apex

Normally a def icon is ghosted before you snapshot it.

That's not the problem, read previous post, even if there is a way to see the normal and "not transparent" Def_Icon

[PeterK]

Originally Posted by AMIGASYSTEM

I was aware of the "wrong" assignment on def_.library, now try to delete the DefIcons from the WBStartup and you'll see that your icon.library will assign a project icon to the libraries.

Ok, confirmed. I have to do some more investigations why this happens on OS 3.9 but not on my main system.

[AMIGASYSTEM]

Peter, if it helps you, I found that if a library icon is created by Dopus4, Dopus it will assign the def_library correctly, I know it's obvious, but this confirms that the problem is only on Workbench !

EDIT:

The arcane revealed the culprit seems to be "def_project.info", if you delete/replace this icon the def_library is associated correctly

[AMIGASYSTEM]

In any case I specify that the def_library configured as Project icon cannot be considered an error, in fact I use this setting on AfA One where as "Project" tool I use an Arexx Script that allows to install on the fly the examined library if this is more updated.

[PeterK]

Update to icon.library 46.4.554, 47.-1.554, 51.4.554: (see 1. page)

° On OS 3.2 the writing of deficons won't call UpdateWB, workbench.library is closed after the version check.

° FreeDiskObject() now checks for "DiskMagic" and clears it before the DiskObject structure memory gets freed.

° Fixes in the file type identification for executables by the datatype system. Some appeared as a "project".

[AMIGASYSTEM]

Ok thanks Peter, however, remains that on OS 3.9 must be changed some def_icon, in fact if you run Deficons executables will always be assigned a "project icon", this is because def_toos on OS3.9 is set as a "project icon" and not eseguibil, see screenshot

[PeterK]

No Carlo, as far as I can see def_tool.info is/was always of the type "tool", in OS 3.9, 3.1.4 and 3.2, but all deficons from other icon sets are mostly of the type "project", sometimes even drawer icons. Edit: Ok, on the OS 3.9 CD it's indeed a "project" icon, maybe I've corrected that later.

If you don't want to use the program DefIcons then you can also install the exe.datatype in order to detect executables on AmigaOS. On Aros 68k there is something that detects "exec" instead of "exe".

I still don't understand why all "executables" like libraries, devices, datatypes, etc should get a "tool" icon, because usually they cannot be executed directly as you can do it with a program. But that is a decision of the AmigaOS developers. I'm just trying to do the same as the OS now. Nothing was tested on AfA_OS, which is not the same as AmigaOS.

[AMIGASYSTEM]

You can verify also on CD OS3.9 the def_tool is a project icon, look at the first secreenshot !

exe.datatype has always been present in my systems, exe.datatype can be useful to consult and understand what an executable uses.

As mentioned the def_library as "project" icon can be useful if you use particular arexx scripts, you can see an example in my "def_library" icon on AfA One:

[daxb]

Originally Posted by PeterK

I'm still don't understand why all "executables" like libraries, devices, datatypes, etc should get a "tool" icon, because usually they cannot be executed directly as you can do it with a program.

Why should they get an icon at all? Aren't they senseless? On my OS 3.1 install such files have no icons.

[AMIGASYSTEM]

Originally Posted by daxb

Why should they get an icon at all? Aren't they senseless? On my OS 3.1 install such files have no icons.

The "associated" def_icon icons are very important to associate each type of file to the right tool.

Example a JPG, MP3, ZIP etc... file if it doesn't have an icon associated you can't use it.

On OS 3.1 (primitive system) these file types are seen as "all the same".

[daxb]

We are talking about "libraries, devices, datatypes, etc". Deficons or not.

[PeterK]

Originally Posted by AMIGASYSTEM

In any case I specify that the def_library configured as Project icon cannot be considered an error, in fact I use this setting on AfA One where as "Project" tool I use an Arexx Script that allows to install on the fly the examined library if this is more updated.

Yeah! That's wise, Carlo.
So, why did you want it to appear as a "tool" before? Maybe it's just the symbol which looks more like an executable, but a tool icon is pretty useless.

Now, you got what you were asking for, if the exe.datatype is installed, but DefIcons and def_library.info are not. The exe.datatype will force all executables to appear as a "tool", the same as by DefIcons without the def_library.info. Then you have to change the type manually to "project" again, if you want to start your Arexx script or maybe use Multiview in conjunction with the exe.datatype to get some information about the executable.

Without DefIcons or an exe.datatype the icon type will depend on the E protection-bit of the file.

And with DefIcons and also def_library.info installed you can set the preferred type in the deficon as you need it.

I'm not sure if anything is better now ...

I just remember a song in which they say: "Be careful what you wish for ... you might get it all" ...

[AMIGASYSTEM]

Originally Posted by PeterK

Yeah! That's wise, Carlo.
So, why did you want it to appear as a "tool" before? Maybe it's just the symbol which looks more like an executable, but a tool icon is pretty useless.

It was just to be correct, then I will be the one to decide and not def_icon to decide

Without DefIcons or an exe.datatype the icon type will depend on the E protection-bit of the file.

And with DefIcons and also def_library.info installed you can set the preferred type in the deficon as you need it.

I'm not sure if anything is better now ...

Yes everything is correct then everyone will choose how best to set their def_icons

[AMIGASYSTEM]

Originally Posted by daxb

We are talking about "libraries, devices, datatypes, etc". Deficons or not.

Yes as said it is possible that associating an Arexx script you can have information about the file, moreover from the icon in many cases you can recognize a file even without extension or with a wrong extension, in this old video of mine an example:

[ Show youtube player ]

[PeterK]

The icon.library build #555 has been released on Aminet:

http://aminet.net/package/util/libs/IconLib_46.4

[AMIGASYSTEM]

Hi Peter, I noticed that with your Icon.library on "OS 3.9" in the Toltype Icon "Duakl-PNG" is not shown the icon type "name", see screenshot.

On OS 3.2 instead, as you can see from the scrennshot, the text on the icon is shown even if it's round.


Another oddity on OS 3.9, this happens even with the native icon.library OS39, the text is not shown even to the icons Drawer and Volumes, Icons Glow