[openbeos] Re: Tracker icons
- From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 21 Jul 2005 20:12:51 +0100 BST
> 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.
I think you're overstating the "all apps" thing a bit much... I
personally can't think of many "abandoned" apps that draw icons. I
wrote some code to get icons for downloads in firefox, but that would
be very easily changed to grab a 32bit icon. NetPositive is in fact the
only app I can think of that would be affected.
[...]
> 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)?
I'm personally a big fan of small icons anyway - I would almost
certainly keep my desktop icons at 32x32 and have tracker windows in
list view with the mini 16x16 icons. Certainly at these small sizes I
think hand-tuned bitmaps work much better than vector graphics.
I don't see any reason why R1 couldn't also support BEOS:M:STD_ICON and
BEOS:L:STD_ICON with higher colour depths reading through your mail.
Then if GetTrackerIcon is passed a CMAP8 bitmap it could do the
conversion. Alternatively I suppose 32bit versions could be stored in
different attributes and GetTrackerIcon could pick which one to load
based on the colorspace of the bitmap the caller passed in.
Tracker/Deskbar are obviously the big two as far as icon display is
concerned, but changing them to ask for 32bit icons should not be a big
job, if the sizes of the icons available are still the same (icon
placement logic wouldn't be affected).
I'm still hopeful 32 bit icons could be an R1 thing. "A more modern R5"
is how I tend to think of Haiku R1, and icons are a big part of that
for me.
Simon
> Bye,
> Axel.
>
>
Other related posts:
