Opened 7 years ago

Last modified 7 years ago

#13466 new enhancement

BToolBar should support trimming icons

Reported by: KapiX Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Currently it's not possible to specify flags for SetIcon in AddAction. SetIcon supports B_TRIM_ICON_BITMAP and it would be useful to pass that directly with AddAction instead of FindButton/SetIcon.

Also, why is BToolBar in private/shared instead of private/interface?

Change History (3)

comment:1 by waddlesplash, 7 years ago

Uh, doesn't B_TRIM_ICON_BITMAP trim the icon size? So then if you had a 32x32 icon which was really only 18x18 or whatever (as may of zuMi's icons are, and they should be fixed before using them...) it'll get cropped to that size, which probably is not what you want.

As for the second question: because it's not ABI-stable yet, and so since it's in private/shared it will get linked into applications statically (-lshared) rather than just being part of libbe but hidden.

comment:2 by KapiX, 7 years ago

This is exactly what I would want. Fixing them isn't really easy because they get blurry.

That's what WebPositive is doing, though using BPictureButton with it's own Trim... function.

Last edited 7 years ago by KapiX (previous) (diff)

comment:3 by pulkomandy, 7 years ago

The main problem here is that Icon-O-Matic doesn't support a 24x24 grid, yet we chose that size for toolbar icons (16x16 is too small, but 32x32 is too large). This is why the icons just leave some empty space on the sides.

Automatic trimming by detecting empty areas in the icon is not going to work, because some may have further empty space inside the 24x24 area. So you need to trim to the expected size 24x24 explicitly?

Anyway, as it is in libshared there is no problem reworking the API, existing binaries will continue to run as they link to it statically.

Note: See TracTickets for help on using tickets.