tl;dr: To use a theme png in C++, add #define NAME "path/to/png" to a .hlst and use BitmapEx foo(NAME)
Until recent changes, bitmap (png) resources were described by a define to an arbitrary number in a .hrc with a body in a .src that contains the file name within the theme hierarchy. The .src got compiled into the final .res with resource ids of the hrc defines In the C++ code the .hrc define was passed to a ResID and the resource manager would load the resource in the final .res and suck out the filename entry and then look that up in the theme hierarchy and load the png from there. Now we just consistently use the filename of the png within the theme hierarchy as the argument to the BitmapEx constructor and bypass the .src/.res intermediaries. We used to parse the .src/.res files to find the list of actually used images in LibreOffice to filter out unused icons in the themes. We want to continue doing that, so the scheme is use is to define FOO "path/to/the.png" in a .hlst file and include that from the .cxx and BitmapEx foo(FOO) and add the .hlst to postprocess/CustomTarget_images.mk and the used bitmaps are the only ones packed by (crudely) sucking out the target of the define and converting to the preexisting ilst format[1] The "private:graphicrepository" url syntax e.g. "private:graphicrepository/sd/res/minimize_presi_80.png can continue to be used to load bitmap resources. You can use the .ilst mechanism to ensure they are packed and not ignored as unused. (mostly java/python pieces need this) But support for private:resource/projectname/bitmapex/<number> and private:resource/projectname/bitmap/<number> has been removed and replaced with "private:graphicrepository/res/projectname/bitmapex.png" I think this is clearer than the preceding system and I was able to find a few png which were referenced from cxx code, but didn't exist in our icon-themes It's quite possible that we could now rename all the very arbitrary filenames from e.g. sx10234.png to more reasonable names (watching out for any that might be used from helpcontent2 or loaded via private:graphicrepository) [1] maybe this hlst processing/registering needs to be gbuild-ified to be prettier _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice