[openbeos] Re: Tracker icons
- From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 20 Jul 2005 17:27:13 +0100 BST
[...]
> > "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
Other related posts:
