On 01/25/2014 12:41 AM, John Scipione wrote:
On Thu, Jan 23, 2014 at 4:11 AM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: What was wrong with the previous method was that it would produce garbled bitmaps sometimes. This apparently happened sometime around the PM merge. I realize that my solution was incomplete as the query was only pulling in app, not document icons. So, in hrev46756 I've reverted it to use the MIME db again. However, it doesn't produce garbled icons because I'm now checking to make sure that GetIcon returns B_OK before displaying them. I've got at least one report from kallisti5 that app icons are being pulled from the MIME db, but, they don't for me. I tried rebuilding my image with --use-xattr support, no luck. I'm not sure, but, I think that there is a problem adding the vector icons to the MIME database in the build system, at least on OS X.
There does indeed seem to be a regression. The build here on openSUSE 13.1 results in application MIME DB entries with 32 byte vector icon attributes. I could have sworn they were correct when I changed the MIME DB layout. Will have a look.
Furthermore, there is nothing wrong to allocate/delete a POD structure via new/delete. Using malloc/free is rather messy. Furthermore, a better change would have been to use a BObjectList for fVectorIcons that own its entries, so that they are actually freed when the screen saver is unloaded (and not leaked like it is now).I implemented the BObjectList part of you suggestion. For the new/delete part, is it more messy to use malloc or to deal with exceptions? I guess I could use std::nothrow, but, I'd rather not deal with the implicit constructor at all for this simple struct.
I don't think an implicit default constructor is generated for PODs. CU, Ingo