icon.library 46.4 test versions

[AMIGASYSTEM]

Originally Posted by PeterK

Added the new "Alpha" version for Aros 68k to support icon dragging with transparency in Wanderer by using the alpha channel. This setting has to be enabled in the Wanderer preferences. Add "RemLib >NIL: icon.library" and IconsToFastMem to your startup-sequence (see Readme).

- "Alpha" version for Aros 68k does not use def_icons (see icon ram on screenshot, with icon.library Aros 68k Work)

- "RemLib >NIL:icon.library" generates error, see screenshot

- Loadmodule LIBS:Icon.library + "RemLib >NIL: icon.library" no error shown in the screenshot


Question: Which position should the RemLib and IconsToFastMem commands be placed in in the startup-sequence?

[PeterK]

Originally Posted by AMIGASYSTEM

- "Alpha" version for Aros 68k does not use def_icons (see icon ram on screenshot, with icon.library Aros 68k Work)

Aros reads def_icons directly from ENVARC:Sys, but my Lib uses ENV:Sys like OS 3.1.4/3.5/3.9. The copying of the def_icons is disabled in the Aros startup-sequence, comment that "PAT" stuff out:

Copy >NIL: "ENVARC:" "ENV:" ALL NOPRO NOREQ ; PAT "~(def_#?.info)"

- "RemLib >NIL:icon.library" generates error, see screenshot

Which icon uses "IconX" and what type of icon is that? Project or not?

- Loadmodule LIBS:Icon.library + "RemLib >NIL: icon.library" no error shown in the screenshot

You shouldn't do that. It makes not much sense.

Question: Which position should the RemLib and IconsToFastMem commands be placed in in the startup-sequence?

RemLib should be called at the top of the startup-sequence, at least above SetPatch. IconsToFastMem can be called somewhere below IPrefs, before Wanderer is started.

[AMIGASYSTEM]

Originally Posted by PeterK

Aros reads def_icons directly from ENVARC:Sys, but my Lib uses ENV:Sys like OS 3.1.4/3.5/3.9. The copying of the def_icons is disabled in the Aros startup-sequence, comment that "PAT" stuff out:

Copy >NIL: "ENVARC:" "ENV:" ALL NOPRO NOREQ ; PAT "~(def_#?.info)"

OK solved by adding a simple and fast command: "Assign Add ENV: ENVARC:"

Which icon uses "IconX" and what type of icon is that? Project or not?

Ok Solved, your icon.library modified the tooltypes (from project to tools) of an application in my WBSTartup running a script.

The resolution was going up the toltypes on an OS 3.9, now the icon works well without being changed.

N.B. On AROS 68k there are no tools to edit Toltypes (project, tool, folder etc..) and also the CLI or WB option if it is not set you have to add manually in the Tooltypes, I hope to explain it otherwise I make a video.


Peter, do you like these new icons of mine?

[PeterK]

Originally Posted by AMIGASYSTEM

OK solved by adding a simple and fast command: "Assign Add ENV: ENVARC:"

Not sure whether that is a good idea or not? And loading def_icons from ENV: is faster.

Ok Solved, your icon.library modified the tooltypes (from project to tools) of an application in my WBSTartup running a script.

Usually, this should only happen if an icon has no "default tool" entry.

N.B. On AROS 68k there are no tools to edit Tooltypes (project, tool, folder etc..) and also the CLI or WB option if it is not set you have to add manually in the Tooltypes ...

Since I don't use Wanderer, and DOpus5 has that feature already, I've never tried to install SwazInfo or similar tools on Aros yet:
http://eab.abime.net/showthread.php?...ht=seticontype

Peter, do you like these new icons of mine?

A very nice "black hole" or "dark mode". Cool!

[AMIGASYSTEM]

Originally Posted by PeterK

Not sure whether that is a good idea or not? And loading def_icons from ENV: is faster.

I think an Assign is faster since he doesn't have to copy anything, or is he wrong?

Usually, this should only happen if an icon has no "default tool" entry.

On AROS 68k and x86 when you create an icon you can't change anything, in many cases on my distros I had to put them on OS3. Fortunately, a version of CopyIcon works on AROS 68k

I've never tried to install SwazInfo or similar tools on Aros yet:

No tested programs work, SwazInfo and RAWBInfo just run block the icon information.

[PeterK]

The Wanderer interface for WBInfo plugins is probably different than that from WB.

But I found a working solution for Wanderer and Aros 68k:
http://aminet.net/package/util/dir/icontype

Copy the instruction IconType into C: and then call it from a shell or with IconX:

IconType `requestfile`

IconType ´requestfile´
IconType 'requestfile'

Use the french accent grave (then type on space), not the single quotation mark or apostrophe.

[AMIGASYSTEM]

Thanks Peter, IconType works well, I installed it on Dopus4 so I think it's easier to change functions to icons (see screenshot).

AROS is strange though, if you copy a Tool icon, Project etc. as a folder icon, the icon despite having several functions behaves like a Drawer icon

[PeterK]

Yes, Wanderer is always a wonderer!

Ok, with a DOpus4 button or function IconType should also work nicely.

[AMIGASYSTEM]

Originally Posted by PeterK

Yes, Wanderer is always a wonderer!

Yes, in fact, if with Icontype I change the function to a folder icon, this even if it changes function if I click opens the folder anyway

[PeterK]

No, if there is an existing directory with the same name and the icon has no "default tool" entry then my library automatically converts the type to "drawer". I did that because all of Ken's icons are of type "project", even all the icons for drawers.

[AMIGASYSTEM]

I don't know if I understand you correctly. I meant this, see video


https://drive.google.com/open?id=1hN...w7V0bHW0xtLxPl

[PeterK]

Thank you, now I understand what you mean. Changing a "drawer" icon into a "project" icon should indeed result in a different behavior, asking you for the "default tool", or if it exists, execute it. Not doing that is a bug.

But is there really a "default tool"? No, there is no entry for a "default tool" in your icon!

[AMIGASYSTEM]

Yes, but the strange thing is that this happens only if you set "project" other functions using IconType are not accepted and the icon remains Drawer

[AMIGASYSTEM]

If you change only the icon (without the presence of the folder) icontype can set any function

[PeterK]

I could change a drawer icon to type "project" and could also add a "default tool" like "Sys:utilities/Multiview" and it was saved in the icon, but Multiview was not called. Instead the drawer was opened again as you said, which is a bug.

Changing the type to "tool" makes no sense as long as there is a drawer with that name.

But changing it to "garbage" should work, but it does not.

[AMIGASYSTEM]

Originally Posted by PeterK

But changing it to "garbage" should work, but it does not.

With IconType the conversion to "garbage" works, it is important that the drawer icon is single without the folder.

I am using your icon.library

[PeterK]

But a trashcan really needs a drawer where you can put your garbage in. Maybe Aros wants to manage that waste bin.

[AMIGASYSTEM]

No I meant that the only icon without folder, can be modified with any function. If instead it is present the folder accepts only the project works

On AROS x86 there is a utility called Processicon but it seems not to work, if I understand correctly also confirm HERE

[AMIGASYSTEM]

Found another oddity on AROS x86, see video

https://drive.google.com/open?id=1YE...lXeJItdOnDhIAf

[PeterK]

Sorry Carlo, I can't help you with Aros x86 since I'm a Windows user. On my Amiga system I'm using the 68k version of ProcessIcon together with PIconTools from time to time, mostly to display additional icon information like position, size, number of colors etc. via context menu. I've also tried to install Report+ on Aros 68k, but it doesn't work (asks for OS 3.9 BB2).

Open your original Test.info with a Hex-Editor and look at offset $30. If that byte is $2 then its type is "drawer", $4 is type "project", and that's what you will probably find there. Icon Information calls icon.library, which corrects the type to "drawer" in case that there exists a folder with that name but no "default tool" entry for a project.