[haiku-commits] Re: haiku: hrev46746 - src/add-ons/screen_savers/icons

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sat, 25 Jan 2014 10:58:58 +0100

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


Other related posts: