Add BIconUtils::GetSystemIcon

Allow to easily access the alert icons and anything that's added to app_server
resources.

Fixes #10887.

Convert BAlert, Debugger AlertWithCheckbox and Keymap ModifierKeysWindow
to make use of it, removing the duplicate code to locate app_server
resources.

The resources are initialized only once (per application), so there is no need
to reload them for every access to the icons.

In the ticket there is discussion about putting this in BControlLook,
but I think this should in fact be moved fully into app_server with
special drawing commands for well-known icons. That would avoid loading
and rendering the icon on the application side to then send it to
app_server (especially in remote_app_server case)?

In any case, this simple API can serve as a base for applications to
use, and we can change how it is implemented later on.

Change-Id: Id370526ae5cf165cfb8bc277bc8a7f46c26f542d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6463
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

Tracker: Add thumbnail support

Define thumbnail attributes in Attributes.h:
Media:Thumbnail to store the thumbnail,
Media:Thumbnail:CreationTime to see if thumbs need to be regenerated.

Store 128x128 thumbnail in attribute, for icon sizes smaller than
128x128 down-scale the 128x128 thumbnail. Use B_FILTER_BITMAP_BILINEAR
to down-scale the image using the bilinear scaling algorithm which
creates nicer looking thumbnails than the default scaling algorithm.

Store thumbnails as WebP images which compress smaller than PNGs and
fit in the inode better at 128x128.

Check the file's modification time in GetFileIconFromAttr() and compare
it to the thumbnail creation time. If the file has not been modified
since the last time we generated thumbnails return the thumbnail from
the attribute, otherwise fetch a new thumbnail with GetThumbnailIcon().

Add "Generate image thumbnails" Tracker setting. Default is turned off
for now. To generate image thumbnails you must first turn this setting
on in Tracker Windows preferences.

Spawn a get_thumbnail() thread to generate thumbnails and retrieve them
later on from the window thread to fill out into the icon. This should
improve responsiveness of generating thumbnails from a folder with a
lot of images. The generator thread will write the thumbnail data to an
attribute if on writable BFS volume.

If not on writable BFS volume, the generator thread will send the data
back to the original thread through a port by calling write_port().

When the thread is finished creating the thumbnail it sends a message
back to the Tracker application thread to update the pose which
instructs the window thread to look for an thumbnail. It either finds a
thumbnail in an attribute, or picks up the thumbnail data that has been
sent through write_port() using read_port().

This works on both read-write and read-only BFS volumes but it still
depends on the presence of a BEOS:TYPE parameter to have been written
to the volume before it became read-only. Thumbnail generation does not
work on other read-only volumes for example an ISO-9660 CD, but it does
work on read-only BFS volumes for example the BeOS R5 CD.

Move BPrivate::CheckNodeIconHintPrivate() from BNodeInfo to Tracker
Model CheckNodeIconHint(). Create Model::CheckAppIconHint() and look
for a vector icon or mini and large icon in that method. Check that
the base type is directory, volume, trash, desktop, or if executable
call CheckAppIconHint().

Add 1 to temp_name to fix the following warning:
src/kits/tracker/FSUtils.cpp:2437:12: note: 'snprintf' output 3 or more
bytes (assuming 267) into a destination of size 266

Rename temp_name to tempName following our style guidelines. Use
strlcpy() and strlcat() instead of strcpy() to safely copy the string.
This fixes thumbnail generation on 64-bit Haiku.

Change-Id: I7f927a5a1f8cf65e4b1aa1e0eb55bbfae87fd969
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3163
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

IconUtils: Improved error checking

IconUtils: Style fixes

* Mostly just renaming variables for clarity and consistency
* whitespace
* fill out #pragma mark's
* indentation

Raised maximum vector data size from 16 KiB to 512 KiB.

* The maximum vector icon data size was a bit low. That may
be hard to track down why a certain vector icon doesn't work,
especially when imported from SVG...
* Don't allocate the vector buffer on the stack anymore.

Fix bitmap scaling

Bug introduced in 810f0a42e50b32d17c478f0bdf73b1b34d315ad0.
The uint8 cast were also acting as masks for each of the pixel
components, moving them out of the multiplications made things go wrong.

Use rgb_color instead of messing with bitshifts and masks for better
readbility (the colors are out of order, but the processing is the same
on each color so the end result is valid).

IconUtis.cpp: Fixed cast.

IconUtils: Add parens to fix warnings

Fixes #9888

A few more bitmap icon updates, edge cases.

* Support downscaling icons to a size smaller than the source.
* For > 4x icon scaling do a scale4x followed by a bilinear scale.

Note that I tried to do a combination of scale2x/scale3x with bilinear scaling
and the results were worse than scale2x/scale3x with down scaling.

The 24x24 icon case looks pretty bad either using bilinear or scale2x followed
by a downscale because I am currently upscaling the 16x16 icon in Deskbar (we
didn't up until now support bitmap icon downscaling so I had no choice). It
might be a better idea to downscale the 32x32 version instead.

Note that all of the above has to do with bitmap icons ONLY and none of it
applies to HVIF icons that scale beautifully without these tricks.

Update bitmap downscaling for BeOS icons.

Implemented a simple down sampling algorithm in the scale_down() function. For
non-integer scaling first scale up using the scale2x, scale3x, or scale4x
algorithm doubling, tripling, or quadrupling the icon then use the downscaling
algorithm to shrink to the desired size. This produces nicer looking results
than bilinear scaling alone.

Note that this only applies to bitmap-based BeOS icons and not vector-based
HVIF icons.

Space after for, thanks Ryan

Refactor IconUtils.cpp

Mostly style changes, some functional changes although there is no
change in functionality for the success case, just cleaner code.

Refactor icon scaling, fix off-by-one error.

Refactor the icon scaling code in IconUtils.cpp to avoid code
duplication. Basically create and delete the temp bitmap to
convert from B_CMAP8 to B_RGBA32 for scale2x/scale3x/scale4x
just one time instead of 3.

There was an off-by-one error in Deskbar which was causing
it to scale up the 16x16 Bitmap icon to 32x32 instead of just
using the 32x32 icon. This only affected BeOS bitmap-based
icons, not Haiku HVIF icons.

Add 96x96 and 128x128 icon sizes to tracker including scaling of BeOS icons using scale3x and scale4x algorithms.

IconUtils: memory leak fix

The intermediate step BBitmap in scale2x wasn't deleted. CID 10692.

Applied patch by John Scipione that adds the scale2x algorithm to BIconUtils
and uses it when old B_CMAP8 icons are to be upscaled exactly 2x. Looks much
better than the previous blurry bilinear scaling. Small cleanups by myself,
closes #7130, thanks a lot!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40678 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Merged weak-symbols branch.
* Fixed trivial merge conflict in src/system/libroot/posix/locale/nl_langinfo.cpp
* Fixed gcc 2 compilation of src/system/glue/init_term_dyn.c.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39571 a95241bf-73f2-0310-859d-f6bbb57e9c96

Enable just enough of the message based format used in Icon-O-Matic to allow
BIconUtils to understand and render it. This makes it possible to use the
HVIFTranslator to also read Icon-O-Matic files out of the box. Will cleanup
now duplicated files next.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30794 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added ConvertToCMAP8() bitmap variant.
* Put header guards in the system namespace.
* Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27035 a95241bf-73f2-0310-859d-f6bbb57e9c96

* when a vector icon was present, BAppFileInfo::GetIcon() would return an
error if the provided bitmap was B_CMAP8, now BIconUtils will convert the
icon to B_CMAP8
-> this behaviour is a little inconsistent compared to what happens when
reading icons from attributes, there, the CMAP8 icon is prefered in case
such a bitmap is passed, even if a vector icon exists. I am not really
sure which behaviour is better. For a consistent UI, maybe it is better
to prefer the vector icon always. I've added a note to BAppFileInfo.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22414 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed build under BeOS.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20652 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Put the remaining libicon.a classes into the BPrivate::Icon namespace.
* Minor cleanup (like removing the extra blank line between the copyright and the
header guard).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20507 a95241bf-73f2-0310-859d-f6bbb57e9c96

resolved TODO


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20479 a95241bf-73f2-0310-859d-f6bbb57e9c96

* fixed off-by-one error in scaling algo


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19303 a95241bf-73f2-0310-859d-f6bbb57e9c96

* fixed a couple of remaining issues with vector icons,
there is some unfortunate code duplication in AppFileInfo,
because it cannot use BMimeType/BNode alone to retrieve icons,
now it works closer to the code in BIconUtils, this fixes
R5 icons not displaying for other icon sizes
* implemented a bilinear scaling function, I don't know if
it is very fast, but I hope it is reasonable. Now that I
see the results though, I wonder if R5 icons should be
scaled with nearest neighbor instead...
* corrected a small bug in the icon format stuff...
7 bit coords are -32-+95, not 96
* improved comment for BIconUtils function


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19302 a95241bf-73f2-0310-859d-f6bbb57e9c96

Axel forgot to adopt this very central place to the new B_VECTOR_ICON_TYPE


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19227 a95241bf-73f2-0310-859d-f6bbb57e9c96

various changes to improve integration of vector icons
* Deskbar uses 32 bit icons now
* vector icons are now correctly converted to B_CMAP8 bitmaps
if no B_CMAP8 icon is available
* small fixes in Tracker (window mode menu)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18803 a95241bf-73f2-0310-859d-f6bbb57e9c96

* integration of vector icons with the registrar and the mime data base
* additional versions of SetIcon[ForType] and GetIcon[ForType] in BMimeType
and BAppFileInfo, which handle flat vector icon data
* changes in Tracker to support scalable icons (currently broken for
non-vector icons and needs cleanup) and drawing icons correctly with alpha
channel (large parts of this work done by Michael Lotz)

If someone feels like looking over the changes, that would be much
appreciated! :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18699 a95241bf-73f2-0310-859d-f6bbb57e9c96

* min/max visibility scale is now between 0 and 4
* flat icon format optimizes for grays in styles


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18508 a95241bf-73f2-0310-859d-f6bbb57e9c96

* copied code from BNodeInfo over to BIconUtils
* implemented a simple "GetIcon" function which loads whatever
icon fits most depending on the available icons and the
colorspace/size of the pre-allocated bitmap passed to the function


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18404 a95241bf-73f2-0310-859d-f6bbb57e9c96

* added a little documentation to BIconUtils in the header


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18401 a95241bf-73f2-0310-859d-f6bbb57e9c96

* cleanup for consistency in FlatIconFormat.h
* used Axels proposals for vector icon attribute name
* added a BIconUtils class, currently only dealing with vector icons,
it will render a vector icon from either a BNode attribute or a flat
buffer in memory into a provided bitmap. The bitmap needs to be of
B_RGBA32 colorspace, the size of the bitmap determines the scaling
of the vector icon, width and height should currently be the same
(square bitmap)
* TODO:
- add reading of "old" BeOS icons / move icon reading from other
places (BMimeType?) into BIconUtils
- add reading icons from resources?
- suggestions?


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18400 a95241bf-73f2-0310-859d-f6bbb57e9c96

IconUtils: Improved error checking

IconUtils: Style fixes

* Mostly just renaming variables for clarity and consistency
* whitespace
* fill out #pragma mark's
* indentation

Raised maximum vector data size from 16 KiB to 512 KiB.

* The maximum vector icon data size was a bit low. That may
be hard to track down why a certain vector icon doesn't work,
especially when imported from SVG...
* Don't allocate the vector buffer on the stack anymore.

Fix bitmap scaling

Bug introduced in 810f0a42e50b32d17c478f0bdf73b1b34d315ad0.
The uint8 cast were also acting as masks for each of the pixel
components, moving them out of the multiplications made things go wrong.

Use rgb_color instead of messing with bitshifts and masks for better
readbility (the colors are out of order, but the processing is the same
on each color so the end result is valid).

IconUtis.cpp: Fixed cast.

IconUtils: Add parens to fix warnings

Fixes #9888

A few more bitmap icon updates, edge cases.

* Support downscaling icons to a size smaller than the source.
* For > 4x icon scaling do a scale4x followed by a bilinear scale.

Note that I tried to do a combination of scale2x/scale3x with bilinear scaling
and the results were worse than scale2x/scale3x with down scaling.

The 24x24 icon case looks pretty bad either using bilinear or scale2x followed
by a downscale because I am currently upscaling the 16x16 icon in Deskbar (we
didn't up until now support bitmap icon downscaling so I had no choice). It
might be a better idea to downscale the 32x32 version instead.

Note that all of the above has to do with bitmap icons ONLY and none of it
applies to HVIF icons that scale beautifully without these tricks.

Update bitmap downscaling for BeOS icons.

Implemented a simple down sampling algorithm in the scale_down() function. For
non-integer scaling first scale up using the scale2x, scale3x, or scale4x
algorithm doubling, tripling, or quadrupling the icon then use the downscaling
algorithm to shrink to the desired size. This produces nicer looking results
than bilinear scaling alone.

Note that this only applies to bitmap-based BeOS icons and not vector-based
HVIF icons.

Space after for, thanks Ryan

Refactor IconUtils.cpp

Mostly style changes, some functional changes although there is no
change in functionality for the success case, just cleaner code.

Refactor icon scaling, fix off-by-one error.

Refactor the icon scaling code in IconUtils.cpp to avoid code
duplication. Basically create and delete the temp bitmap to
convert from B_CMAP8 to B_RGBA32 for scale2x/scale3x/scale4x
just one time instead of 3.

There was an off-by-one error in Deskbar which was causing
it to scale up the 16x16 Bitmap icon to 32x32 instead of just
using the 32x32 icon. This only affected BeOS bitmap-based
icons, not Haiku HVIF icons.

Add 96x96 and 128x128 icon sizes to tracker including scaling of BeOS icons using scale3x and scale4x algorithms.

IconUtils: memory leak fix

The intermediate step BBitmap in scale2x wasn't deleted. CID 10692.

Applied patch by John Scipione that adds the scale2x algorithm to BIconUtils
and uses it when old B_CMAP8 icons are to be upscaled exactly 2x. Looks much
better than the previous blurry bilinear scaling. Small cleanups by myself,
closes #7130, thanks a lot!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40678 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Merged weak-symbols branch.
* Fixed trivial merge conflict in src/system/libroot/posix/locale/nl_langinfo.cpp
* Fixed gcc 2 compilation of src/system/glue/init_term_dyn.c.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39571 a95241bf-73f2-0310-859d-f6bbb57e9c96

Enable just enough of the message based format used in Icon-O-Matic to allow
BIconUtils to understand and render it. This makes it possible to use the
HVIFTranslator to also read Icon-O-Matic files out of the box. Will cleanup
now duplicated files next.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30794 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added ConvertToCMAP8() bitmap variant.
* Put header guards in the system namespace.
* Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27035 a95241bf-73f2-0310-859d-f6bbb57e9c96

* when a vector icon was present, BAppFileInfo::GetIcon() would return an
error if the provided bitmap was B_CMAP8, now BIconUtils will convert the
icon to B_CMAP8
-> this behaviour is a little inconsistent compared to what happens when
reading icons from attributes, there, the CMAP8 icon is prefered in case
such a bitmap is passed, even if a vector icon exists. I am not really
sure which behaviour is better. For a consistent UI, maybe it is better
to prefer the vector icon always. I've added a note to BAppFileInfo.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22414 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed build under BeOS.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20652 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Put the remaining libicon.a classes into the BPrivate::Icon namespace.
* Minor cleanup (like removing the extra blank line between the copyright and the
header guard).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20507 a95241bf-73f2-0310-859d-f6bbb57e9c96

resolved TODO


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20479 a95241bf-73f2-0310-859d-f6bbb57e9c96

* fixed off-by-one error in scaling algo


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19303 a95241bf-73f2-0310-859d-f6bbb57e9c96

* fixed a couple of remaining issues with vector icons,
there is some unfortunate code duplication in AppFileInfo,
because it cannot use BMimeType/BNode alone to retrieve icons,
now it works closer to the code in BIconUtils, this fixes
R5 icons not displaying for other icon sizes
* implemented a bilinear scaling function, I don't know if
it is very fast, but I hope it is reasonable. Now that I
see the results though, I wonder if R5 icons should be
scaled with nearest neighbor instead...
* corrected a small bug in the icon format stuff...
7 bit coords are -32-+95, not 96
* improved comment for BIconUtils function


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19302 a95241bf-73f2-0310-859d-f6bbb57e9c96

Axel forgot to adopt this very central place to the new B_VECTOR_ICON_TYPE


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19227 a95241bf-73f2-0310-859d-f6bbb57e9c96

various changes to improve integration of vector icons
* Deskbar uses 32 bit icons now
* vector icons are now correctly converted to B_CMAP8 bitmaps
if no B_CMAP8 icon is available
* small fixes in Tracker (window mode menu)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18803 a95241bf-73f2-0310-859d-f6bbb57e9c96

* integration of vector icons with the registrar and the mime data base
* additional versions of SetIcon[ForType] and GetIcon[ForType] in BMimeType
and BAppFileInfo, which handle flat vector icon data
* changes in Tracker to support scalable icons (currently broken for
non-vector icons and needs cleanup) and drawing icons correctly with alpha
channel (large parts of this work done by Michael Lotz)

If someone feels like looking over the changes, that would be much
appreciated! :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18699 a95241bf-73f2-0310-859d-f6bbb57e9c96

* min/max visibility scale is now between 0 and 4
* flat icon format optimizes for grays in styles


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18508 a95241bf-73f2-0310-859d-f6bbb57e9c96

* copied code from BNodeInfo over to BIconUtils
* implemented a simple "GetIcon" function which loads whatever
icon fits most depending on the available icons and the
colorspace/size of the pre-allocated bitmap passed to the function


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18404 a95241bf-73f2-0310-859d-f6bbb57e9c96

* added a little documentation to BIconUtils in the header


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18401 a95241bf-73f2-0310-859d-f6bbb57e9c96

* cleanup for consistency in FlatIconFormat.h
* used Axels proposals for vector icon attribute name
* added a BIconUtils class, currently only dealing with vector icons,
it will render a vector icon from either a BNode attribute or a flat
buffer in memory into a provided bitmap. The bitmap needs to be of
B_RGBA32 colorspace, the size of the bitmap determines the scaling
of the vector icon, width and height should currently be the same
(square bitmap)
* TODO:
- add reading of "old" BeOS icons / move icon reading from other
places (BMimeType?) into BIconUtils
- add reading icons from resources?
- suggestions?


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18400 a95241bf-73f2-0310-859d-f6bbb57e9c96