FreeLists / openbeos / [openbeos] Re: Tracker icons

["Simon Taylor" <simontaylor1@xxxxxxxxxxxx>]

[...]
> > "Extending [the icon mechanism] right" to me means following the 
> > current api - like adding a new icon_size const. Of course if 
> > vector 
> 
> The current API is also more or less fixed to B_CMAP8.

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.

[...] 
> > 2 possible directions:
> >     1) Stick to the current bitmap approach, but include support 
> > for 
> > a 
> > larger bitmap with more colours that can be resized as needed (ala 
> > MacOSX). In this case a minimal API change would enable support to 
> > be 
> > added for R1.
> >    2) Go for a full vector approach - this has more dependencies 
> > and 
> > would not be feasible for an R1 release, but would bring 
> > theoretically 
> > limitless flexibility for the size of icons that could be displayed 
> > (although I doubt how useful that really is).
> 
> Why do you think we need decide for a direction? To me, both 
> directions 
> are pretty much the same, and will be realized with the same API. The 
> main point is that the system should be fast and flexible - there is 
> no 
> reason not to support both: we should try different formats and adopt 
> the best ones, vector and bitmap based.

Simply that if the bitmap direction was decided on, it could be added 
without too much hassle.

I like the idea of keeping the whole thing very flexible but I 
recognise that will be more of an API change so won't happen in R1. No 
worries, good things come to those who wait.


Simon