icon.library 46.4 test versions

[PeterK]

Originally Posted by thomas

WBDock does not allocate any pens on its own. Try to use different patterns for the background and the drag bar. The number of pens depends on the images and datatypes used. If you use no pattern, WBDock will become transparent and allocate no pens at all.

What do you mean, saying that WBDock loads no pens on its own? If I use the funny mode for example then WBDock needs to load the tool icons with the help of icon.library, but still in the task context of WBDock. Icon.library has to do some color mapping for any unknown applications (except WB, Wanderer and DOpus5) and that, of course, will try to allocate pens. At least in the funny mode, you really need the color mapped and C2P converted planar images (even of TrueColor icons) to BitMapScale() them for these nice jumping little tool icons.

It's nothing wrong with that, it's even one of my goals why I'm trying to prevent other unused invisible icons to allocate pens with unwanted colors in WBStartup. Those tools which really need pens should come first in the line in order to get the best colors without sharing crap.

[thomas]

Originally Posted by PeterK

WBDock needs to load the tool icons with the help of icon.library

That's exactly what I mean. Icon.library, picture.datatype and maybe some other helpers are responsible to maintain their pens. There is nothing I could change in WBDock to influence the amount of pens used. You cannot say "WBDock needs 48 pens". That's not true. It's the graphics you choose which requires the pens. WBDock alone does not need any. You have to use optimised icons and graphics to reduce the number of pens used by WBDock.

Talking about styles, the Toolmanager style and the LCARS style do allocate pens. Four or six each IIRC. So WBDock might need six pens. But these styles do not load backgound images, so they don't need more than these six pens.

Pens used by icon.library are always needed of course. I don't count these. It's the same as if you had a drawer window with these icons open all the time. You cannot blame WBDock for loading and showing icons (and keeping their pens allocated all the time). That's its purpose.

[James]

Originally Posted by thomas

You cannot blame WBDock for loading and showing icons (and keeping their pens allocated all the time).

Is this why WBDock can't fully display DualPNG and OS4 icons in the same way that AmiDock does when using PeterK's library?

[AMIGASYSTEM]

Hi Peter, no war with mfilos we have discussed, and found the solution to get fonts with antialias on OS 3.2, I was referring to the graphics part themes and everything else that AfA OS offers.

[James]

Originally Posted by AMIGASYSTEM

and found the solution to get fonts with antialias on OS 3.2

Trouble with this solution is that it causes AmiStart and at least one other application (that I have forgotten) to crash. I use aafont:

https://aminet.net/package/util/wb/aafont

It can give a nice effect when combined with font outlines, but it also has problems -occasional smearing around text, needs to be run separately for each app, and looks a bit too blurry with some apps.

[PeterK]

Originally Posted by James

Is this why WBDock can't fully display DualPNG and OS4 icons in the same way that AmiDock does when using PeterK's library?

None of the normal OS 3.x applications knows anything about the hidden TrueColor images in the extended DiskObject structure when they load icons. The icon.library interface has only support for palette based and planar images. But when an application tries to display the palette based images on a Hi/TrueColor screen and icon.library still finds the ARGB images in the private data structure then it will display the TrueColor images, otherwise RGB colors directly, if possible.

But it could happen that an application works with copies of the images or uses the planar data directly for graphic.library functions, then icon.library can't replace these images anymore by ARGB data.

[James]

Thanks for the explanation PeterK.

[PeterK]

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

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

[mfilos]

Thanks a lot for the continuous work Peter!

[CFou!]

cool

[PeterK]

Update to icon.library #575 for the TrueColor versions:

When icons were moved across the left border by sliding windows horizontally on DOpus5 they could sometimes get black vertical stripes or even become completely black. And a small cleanup in the code without functional changes.

@moderators
I always get a database error when I try to insert this update note into the first post of this thread.

[mfilos]

Thanks for the update Peter as always!

Back to pens... As using Tools --> ResetWB free a lot of pens used, is there a command that can be issued as last priority in WBStartup to ResetWB freeing up as many pens as possible after boot process has finished?

[PeterK]

Hi mfilos,

no, I would not recommend to use WBReset without urgent need for free pens, like using IconEdit, for example.

WBReset tries to remap all icons in the internal list of icon.library, that were mapped to the "GlobalScreen" before, usually the Workbench screen. But it will not distinguish any icons by their owner, the process that once loaded these icons. That owner is not stored in the list.

That's all no problem with a traditional system where all icons are mapped, even those of the Workbench task. But then you won't get a lot of free pens, just better colors after the remapping.

My icon.library, on the other side, won't map icons for Workbench on a Hi/TrueColor screen, only for other tasks, because they may need the color mapping. And that could be the problem: WBReset suddenly handles all icons in the context of Workbench and the pens are just released, but the icons of other applications are not mapped again, which could result in wrong looking colors in the worst case. No problem, of course, as long as no tools are open on WB.

[mfilos]

Ok I get it now! Thanks for the enlightening post Peter.

[kamelito]

Under 3.2.2 using fast WB version (latest) and magic menu when I open an asl requester and I click the right mouse button I got a grey screen
Same with the 020 version

[mfilos]

I don’t have a single issue with TC020 version. Using that from 3.2.1 till now and i’m super happy Kamelito mate.

[itsmedoofer]

Originally Posted by mfilos

I don’t have a single issue with TC020 version. Using that from 3.2.1 till now and i’m super happy Kamelito mate.

Same here, A1200 OS3.2.2, TC020 no issues at all....

[PeterK]

Originally Posted by kamelito

Under 3.2.2 using fast WB version (latest) and magic menu when I open an asl requester and I click the right mouse button I got a grey screen
Same with the 020 version

1.) The FastWB version is not required for OS 3.2, it's only for WB v44-45. Use TC020 (libs/icon.library).

2.) Not enough information: Which screenmode exactly? What are your MagicMenu and ASL configuration settings? Any ASL requester patches installed or MCP? Please upload your configuration files if possible.

but ok, I will try to reproduce it ...

Update: No, couldn't reproduce it yet, tried the "Search" requester (ASL ?) from the WB window menu and also the "requestfile" command, but no grey screen.

So, what exactly are you doing to get an ASL requester?

In MagicMenu preferences enable "Non blocking", and for colors "GUI" and "Prefer screen colors"

[kamelito]

I don’t see a TC020 version in the latest archive on Aminet

[mfilos]

It's the icon.library inside the LIBS drawer.
Just use version to see that it's indeed the TC020

Also if you go to first post in this thread there is a newer version here (where the TC020 is clearly with a name there).