[openbeos] Re: Tracker icons
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 21 Jul 2005 20:16:23 +0200 CEST
Stephan Aßmus <superstippi@xxxxxx> wrote:
> > > The current API is also more or less fixed to B_CMAP8.
> Not at all. At least not the one from BNodeInfo.
That's actually what I meant: the BBitmap is created by the caller, and
therefore, it's always B_CMAP8 - if you wanted to change just that, all
applications would need to be updated to have the desired effect.
If the bitmap was created inside the API implementation, all apps would
directly benefit from that change.
> > GetTrackerIcon returns a BBitmap - I was just proposing adding
> > another
> > enum member to return a bigger bitmap with a non CMAP8 colorspace.
> > B_MINI_ICON and B_LARGE_ICON would still be kept for backwards
> > compatibility, and would still be CMAP8 of course.
> Well, it is even simpler than that. Yes, we could add another
> constant, but
> notice that the BBitmap is not returned, but supplied by the caller.
> So if
> an application simply provided a B_RGBA32 bitmap, the function could
> render
> a high quality icon, no matter the requested size. The API is
> actually no
> restriction at all. Even the size of the icon is actually given by
> the
> BBitmap, we don't even have to care about the icon_size constant, it
> could
> merely specify the source for the bitmap.
That's what I thought as well, I would just add another call to get a
BPicture (or something more advanced, like a SVG object - maybe we
should just extend BPicture to have features like gradients), to have a
resolution independent representation of the icon, if available (that's
obviously an API extension :-)).
But there is another problem we'd have to solve when changing how the
API works: we need to have a common way to store these kind of icons,
something like an additional "best quality representation" icon -
BEOS:M:STD_ICON and BEOS:L:STD_ICON should probably stay like they are,
or not (the size, not necessarily the color depth)?
Bye,
Axel.
Other related posts:
