icon.library 46.4 test versions

[PeterK]

Originally Posted by Kernel

I forgot to mention I'm using this with 3.1.4 but I suspect since you support it, it won't make much of a difference.

Yes, 3.1.4 is ok, but using the IconEdit of 3.1.4 makes no sense, that's an old version from 3.1 and can handle only old and MWB icons.

I'll have to try this then... but I'm a bit confused how the RestoreTrueColor would work... if the ConvertTrueColor turns them into true OS 3.5 GlowIcons in 256 colors how does the Restore reverse this?

No, you can't restore the converted icons, just the TrueColor mode can be switched on again.

Hmmm... I did not have the JIT enabled but I went in and tried it but they are still slow. I must have something else off if you are getting what seems to be an instant display of the full color PNG's.

Strange, usually the Jit makes everything about 15 times faster. But you're using P96 and 15/16/24/32 bit UAE screenmodes and not PAL or NTSC, right?

Update: Please also enable "Fastest possible" CPU emulation speed, move the CPU Idle slider to the leftmost position and disable "Cycle exact" under Chipset. (the quickstart A1200 emulation is just as slow as a real A1200)

[Kernel]

Seems that it was the cycle exact setting because it's instant now. However, Birdie doesn't appear to work with that setting. Time to search for that solution unless you have any ideas on that one?

[PeterK]

No sorry, but I don't use Birdie.

[Kernel]

Originally Posted by PeterK

No sorry, but I don't use Birdie.

No worries, found a fix already. Added a Wait 3 just before running it to allow the system to catch up first.

I don't think I need the conversions now unless I use these on a real Amiga... so we shall see if that happens. Need more space in the house to set them up...

Thanks for the help!

[Michael]

For Birdie to work, intuition has to open the screen first, on fast machines (on good real ones too) the loading process in S-S can be quicker then iPrefs inits the screen in RTG mode. Doing a wait is ok, but easier just to move it at the end of S-S so it starts when something is already displayed like dopus loading window.

[AMIGASYSTEM]

With Birdie Prefs you do not need to put the Birdie command with the image path in the Startup-sequence, you can run birdie prefs from the user-startup:

Run >NIL: Birdie ? <ENV:Birdie.Prefs

[Kernel]

Originally Posted by AMIGASYSTEM

With Birdie Prefs you do not need to put the Birdie command with the image path in the Startup-sequence, you can run birdie prefs from the user-startup:

Run >NIL: Birdie ? <ENV:Birdie.Prefs

Hm I'll have to check it out never knew that existed... and thanks for the tip on the startup Michael!

Another question this time on default icons. Does anyone know what def_*.info icons are supported within the core OS 3.1.4 by default (and previous OS versions)? I am going to make an assumption (probably wrong...) that it is icon.library that implements this feature and it's the same in the PeterK version as it is in the core OS library? School me if I am wrong... or right... either way school me!

From what I can tell, only def_disk, def_drawer, def_tool, and def_trashcan are supported and to use anything else you either need to use DefIcons or some other tool.

Thanks

[PeterK]

Your assumptions are not bad, there are the standard deficon types defined as 1=disk, 2=drawer, 3=tool, 4=project, 5=trashcan, 6=device, 7=kick, 8=app. You can call icon.library with GetDefDiskObject(def_type) or GetIconTagList() with the tag "ICONGETA_GetDefaultType" = 1-7.

Another possibility is to call GetIconTagList() with the tag "ICONGETA_GetDefaultName" and a name like "DF0", "DF1", "HD0", "CD0" ... to get the icon ENV:def_DF0.info ... etc

Or you can install the DefIcons commodity of OS 3.9 in WBStartup, copy deficons.prefs into ENVARC: and optional install Prefs/DefIcons. DefIcons uses a hook in icon.library for resolving icon requests by its filetype definitions. Another program that uses this hook is Eastern for its thumbnail preview icons that it generates on the fly from pictures.

[Kernel]

Originally Posted by PeterK

Your assumptions are not bad, there are the standard deficon types defined as 1=disk, 2=drawer, 3=tool, 4=project, 5=trashcan, 6=device, 7=kick, 8=app. You can call icon.library with GetDefDiskObject(def_type) or GetIconTagList() with the tag "ICONGETA_GetDefaultType" = 1-7.

Another possibility is to call GetIconTagList() with the tag "ICONGETA_GetDefaultName" and a name like "DF0", "DF1", "HD0", "CD0" ... to get the icon ENV:def_DF0.info ... etc

Or you can install the DefIcons commodity of OS 3.9 in WBStartup, copy deficons.prefs into ENVARC: and optional install Prefs/DefIcons. DefIcons uses a hook in icon.library for resolving icon requests by its filetype definitions. Another program that uses this hook is Eastern for its thumbnail preview icons that it generates on the fly from pictures.

OK, so basically what I'm trying to do is figure out what def_* files I should have in envarc:sys to support the base OS capabilities for default icons. Additionally, knowing what your library supports in addition to these (sans DefIcons or another utility) is also a good thing. I like information

Based on my testing, I've been able to see the def_tool, def_disk, def_trashcan, and def_drawer in action, but how would I go about getting a def_project, def_device, def_kick, and def_app icon to show up? Are these based on filename, file flags, or something within them (like how DefIcons works)?

I ask these questions because I want to learn and haven't found much details on this... not to be a pain and when installing OS 3.1.4, there are no def_* files installed into envarc:sys but there are a bunch of Glowicons included that are in envarc:sys and only the 4 I mentioned above seem to work out of the box.

[Michael]

def_project is usually anything not executable
def_kick is tricky, it requires a special floppy disk
def_device is for any mounted device
def_app is not available in classic library

[PeterK]

Project icons can have an additional "DefaultTool" defined, which should be used to open these files like documents, music, videos, pictures or whatever. So "DefaultTool" could be Multiview, a picture viewer, audio player or anything that can handle the data file.

There is no def_app AFAIK. App icons are usually used for iconifying programs. Some programs are loading their own app icons or in other cases the program icon is used.

You can also define deficons for names of disk devices which have no real icon like def_DF0, def_DF1, def_CD0 to avoid that they all get the standard def_disk icon.

[Kernel]

Originally Posted by PeterK

Project icons can have an additional "DefaultTool" defined, which should be used to open these files like documents, music, videos, pictures or whatever. So "DefaultTool" could be Multiview, a picture viewer, audio player or anything that can handle the data file.

There is no def_app AFAIK. App icons are usually used for iconifying programs. Some programs are loading their own app icons or in other cases the program icon is used.

You can also define deficons for names of disk devices which have no real icon like def_DF0, def_DF1, def_CD0 to avoid that they all get the standard def_disk icon.

I have not been able to get the def_project.info to display for anything. I've tried creating a text file in RAM and choosing Show All but it just uses the Tool icon. I've thrown .dat files that I know aren't executable in there as well.. but everything uses the def_tool file. And how would I trick the system into displaying def_device just so I can see it in action?

Also, Peter - just to be clear - you are saying that your library supports the def_DF0 and the like as built-in functionality without the need for DefIcons or another utility correct?

[PeterK]

As long as the executable flag is set for your data file you will always see the def_tool icon. Clear the E-flag and add "Sys:utilities/Multiview" as DefaultTool to def_project.info.

And yes, icon.library displays def_DF0.info for floppies without an icon in DF0:, no need for DefIcons.

Don't ask me who or what loads def_device, but icon.library supports requests to load a deficon of that type.

[Kernel]

Originally Posted by PeterK

As long as the executable flag is set for your data file you will always see the def_tool icon. Clear the E-flag and add "Sys:utilities/Multiview" as DefaultTool to def_project.info.

And yes, icon.library displays def_DF0.info for floppies without an icon in DF0:, no need for DefIcons.

Don't ask me who or what loads def_device, but icon.library supports requests to load a deficon of that type.

I've found that the issue lies with AutoUpdateWB actually. When I have Show All turned on and create a file, the def_tool icon is automatically appearing regardless of the executable flag. When I close and reopen the window, def_project is then used for the non-executable files.

[PeterK]

Interesting "feature" of AutoUpdateWB, confirmed , but I didn't know that yet.

[Kernel]

Originally Posted by PeterK

Interesting "feature" of AutoUpdateWB, confirmed , but I didn't know that yet.

What?! How could you have missed that?!

In all seriousness though, this is the type of thing I mentioned above... when I stumble upon something weird I basically beat it to pulp until I figure out why... fun to do

[PeterK]

Update to icon.libary 46.4.509:

Cleaned up and streamlined the gfx-patch a bit. Renamed "RestoreTrueColor" into "PreserveTrueColor".


Added IconDemoHAM6 and IconDemoHAM8 ADF images.

All IconDemos need Kickstart 3.0 or better 3.1, but are not made for 3.1.4, because the workbench.library is missing and the WB 3.1.4+ also requires a different FBlit.cfg and DefIcons.

[Kernel]

Originally Posted by PeterK

Update to icon.libary 46.4.509:

Cleaned up and streamlined the gfx-patch a bit. Renamed "RestoreTrueColor" into "PreserveTrueColor".


Added IconDemoHAM6 and IconDemoHAM8 ADF images.

All IconDemos need Kickstart 3.0 or better 3.1, but are not made for 3.1.4, because the workbench.library is missing and the WB 3.1.4+ also requires a different FBlit.cfg and DefIcons.

How do you mean it requires a different DefIcons - you mean the one from 3.5 or the DefIcons44 rather than standard DefIcons from the NewIcons package?

Oh... and the version description and readme included on Aminet still references .506 rather than .509

[PeterK]

Originally Posted by Kernel

How do you mean it requires a different DefIcons - you mean the one from 3.5 or the DefIcons44 rather than standard DefIcons from the NewIcons package?

Exactly! The DefIcons from the NewIcons package works with 3.0/3.1 only and the DefIcons v44+ is just for workbench.library v44+ (3.1.4/3.5/3.9). Of course, WB v44 also needs no "DontShowIBorder" tool or similar.

Oh... and the version description and readme included on Aminet still references .506 rather than .509

All updates uploaded here are test versions and no full releases like on Aminet. The descriptions of all updates can be found on the 1. page here until a new full version appears. The build numbers on Aminet are not consecutive, gaps are normal.

[kolla]

@PeterK

I'm a little confused, as far as I am aware, I have not at all the OS 3.1.4 icon.library on my system, neither in kickstart nor any libs path. Is this "normal"?? Notice how version pics upbuild date from... somewhere.

(Icon.library vs. icon.library - casing)