icon.library 46.4 test versions

[PeterK]

Yes, that's a feature of my library:
Whenever it finds a "default tool" entry in PNG icons then it changes the type from tool to project.

Btw, I have to rework the 46.4.410 update again, since I found another FBlit config which works with 46.4.409 only concerning icon ghosting and dragging.

[daxb]

Originally Posted by trixster

I've added icon.library into DEVS:Modules and added icon.library into my BlizKick line in startup-sequence. It know reads:

You can try to write the absolute path to icon.library and/or remove QUIET to see possible error output.

editing this tio C:Setpatch QUIET DISABLEROMMODULES "" just returns an error on boot up.

Thats because setpatch 43.6 hasn`t such an option. SetPatch that comes with OS3.5/9 have more options. Just enter "setpatch ?" in a shell to see them.

[trixster]

Thanks for the replies folks. I got this running correctly with BlizKick. Peter, I ran your adf test disk and everything displays exactly like your demo picture shows. Thanks.

I'll see about updating SetPatch. Can I use the latest versions for OS3.5/3.9 with my 3.1?

What is the latest version of SetPatch? The one on Aminet is v43.6

[PeterK]

Don't replace your installed SetPatch with v44.38 if everything is already working now. Because if you do that then SetPatch would load the icon.library resident again and it makes no sense to load it twice (first with BlizKick or LoadModule or LoadResident). Think twice but don't load it twice

[trixster]

Thanks, I'll stick with what I have!

[PeterK]

Update to icon.library 46.4.412:

I've reworked the changes of 410 and 411 again.

There is a new instruction "InvertGhostingMask" for the startup-sequence now to fix the disappearing of ghosted deficons while dragging them on the Workbench. This was necessary because not only FBlit is responsible for changes of the WB's dragging mask. Even tools like AddBuffers or VisualPrefs can cause this.

The new tooltype "NoGhost" to disable the ghosting for particular deficons is checked only for the first four characters now and is not case sensitive. It should work on all WB 3.5+ screenmodes and even with a 68000 CPU.

[mfilos]

Awesome features Peter. Thanks a lot!

[Leandro Jardim]

Hi, PeterK, will you turn commands like ShadowIconText into AmigaOS environment variables when IconLib be ready?
While commands like InvertGhostingMask are nice, the unknown variables that change the icon dragging mask are so many that I would think you should remove all these hacks and keep only IconGhostingOff.
About the IconLib requesters, I would keep them with minimal text possible like Workbench 3.0/3.1 requesters are. But they are only suggestions, IconLib is not mine!

[PeterK]

1.) No, I won't create ENV variables, since they would have to be read in and send as commands to the IconControl() function anyway. This would need something like IPrefs for the icon.library.

2.) My icon.library is "ready" or finished. 46.4.409 was the final version, but bugfixes and service releases are still possible.

3.) You are not forced to make use of InvertGhostingMask.

4.) The text for the requester has already been reduced significantly since 411. What should I remove from the requester?

[nzo]

Hello PeterK! I'm using MagicWB with 8 colors on Blizzard 1230. I like the magic-style I want to see the NewIcons-icons too that most WHD game icons use. I don't care about the other (OS4, etc.) icons with this config. What is the correct minimal(!) way to make this happen - probably with your icon.library?

[Michael]

Hmm... You will need WB with around 32 colours minimum then to make it work, better 64c.
Then you can lock the first 8c for MagicWB and have the reset for the colourful icons.
You might be able to get away with 16c, but that's too limited for the MWB/NI combination.
FBlit will help on speed an chip mem use, see Peters Icon Demo disk, it has all you need apart from the tool to lock MWB colours (FullPalette will do nicely)

[daxb]

I`m using a 16 color fixed palette. MWB colors + some others and the result is good for me. Of course it depends on your taste but I guess that with 32 colors the most icons should look good enough. For original look some more colors are needed. As Michael pointed out, FullPalette is the best way to manage colors. Notice: MWB colors are the first 4 pens and the last 4 pens of a palette.

[Michael]

If we are referring to MagicWB 2.0+ it's the first 8 colours, same for MUI.
The split at start 4c + 4c at end was MagicWB 1.x and 8bit icons, current proper MagicWB icons are 3bit only.

[daxb]

Hmm... don`t know. Here it was always the first and last 4 colors. With 8 color palette it is of course the first 8 colors.

[Michael]

8-bit icons usually downscale with WB depth, that's why MagicWB 1.x used the first and the last colours, since they were remapped correctly at all depth. But that has changed when the MagicWB deamon was invented to lock the 4-7 (5-8) colours and allowed to make 3-bit smaller file size icons that also used less ram and were much faster to render, then you got the tool to convert them from 'funny' coloured ones.
This method also freed the last 4 colours for custom workbench setting, like hilights, glyphs, text cursor.

[PeterK]

Hi nemazoty,

sorry for the late reply, but I hope the suggestions from Michael and daxb and my IconDemoADF image from the first post of this thread could help you for a start.

[kolla]

Hey PeterK, I have a request that may seem a little odd, I just wrote about it on Amiga.org, so I can repeat it here.

Once upon a time, I had drawers that were projects, their icons were of type project with an associated default tool. THIS WAS PRETTY DARN NEAT!

For example - I could turn a drawer full of pictures into a project, give it an appropriate icon and set a picture viewer as default tool, on opening that icon, the image viewer would launch and show slideshow of all the pics in the drawer.

More useful example - I had a rexx script that would take a drawer as argument, and build a GUI based on resources found in that drawer, very much like how !Application works on RISCOS (I was inspired by RISCOS on this), or OS X (every Program in /Applications is really a directory).

Any chance we (or really "I", since I am the only one I know who ever abused this awesome feature) can have this functionality back?

[PeterK]

It still seems to work if you first rename the directory, use a project icon and set up the default tool, save it and ...
(then change its type to drawer and save again. Change the type back to project, save it and ...)
... finally restore the directory name to the same as the icon name.

Did you try that already?

As long as a directory exists which has the same name as a project or tool icon they will be converted into drawer icons automatically.

Changing the type to drawer and saving is only done for creating the drawer data entry for the icon, but maybe not required.

[kolla]

Originally Posted by PeterK

As long as a directory exists which has the same name as a project or tool icon they will be converted into drawer icons automatically.

This is not how it works in OS3.1. I just tested this by booting with Workbench3.1 floppy and clean 3.1 kickstart:

* I booted from Workbench3.1 in DF0: and Extras3.1 in DF1:
* I copy WBStartup from Workbench3.1 to RAM Disk by pulling it over
* I rename WBStartup in RAM Disk to "Project"
* I open IconEdit from Extras3.1:Tools, I open RAM:Project.info
* I go to "Type" menu and set it to "Project", I save the icon and exit IconEdit
* I double click the Project icon in RAM Disk
- Screen flashes and the screen bar says "The icon(s) have no default tool"
* I click "Project", and open Information, sets "Default Tool:" to "Multiview".
* Again I double click the Project icon in RAM Disk
- Multiview opens and shows content of drawer "RAM Disk:Project" - as I expected.

[kolla]

Originally Posted by PeterK

It still seems to work if you first rename the directory, use a project icon and set up the default tool, save it and ...
(then change its type to drawer and save again. Change the type back to project, save it and ...)
... finally restore the directory name to the same as the icon name.

Did you try that already?

Now I did - and you are right, this work-around works!