[openbeos] Re: Tracker icons

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Fri, 22 Jul 2005 10:21:03 +0200 CEST

"Simon Taylor" <simontaylor1@xxxxxxxxxxxx> wrote:
> > 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 

I didn't just mean abandoned apps - I just really mean *all apps* that 
draw icons.

> 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.

There are lots of apps that draw icons in some places, but changing the 
color space would probably not pose a lot of problems for them - the 
icons would just look worse than usual, so it might be acceptable.

> 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.

Definitely.

> 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.

I would rather have only one attribute for this - since it currently 
contains plain data (without any header), the size of the attribute 
would need to determine what kind of data the attribute contains - if 
it's 32*32 = 1024 bytes long, it would be a plain data 8 bit image; if 
it's any other size, it should have a header that describes the data 
first.
Of course, this would break compatibility with all apps that read out 
the attribute directly, if any.

> 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).

True.

> 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.

Since the worst thing that happens are not so nicely "downsampled" 
icons, I think we could actually consider it for R1.

Bye,
   Axel.


Other related posts: