[openbeos] Re: Tracker icons

> "Simon Taylor" <simontaylor1@xxxxxxxxxxxx> wrote:
> > OT is limited in the icons it can display - 32x32x256 being the 
> > biggest 
> > possible. Of course there are lots of concerns about binary 
> > compatibility, but couldn't we retain the normal icons and just add 
> > a 
> > H_HUGE_ICON or something to go with the other icon_size constants 
> > (B_MINI_ICON, B_LARGE_ICON) for GetTrackerIcon?
> 
> If, then it would be *B*_HUGE_ICON - we definitely don't plan to 
> introduce just another naming convention to confuse our developers.

Sure. Post R1 things get a little hazier I guess - unless Haiku plans 
to keep the B prefix forever.

> But 64x64 would be useless for most users anyway (much to big, unless 
> you have image thumbnails), so it would have to be 48x48 pixels. And 
> then, still no other app supports these.
> They would need to be updated, and for what?
> If we should extend the icon mechanism at all, we should do it right, 
> and that's most probably not part of R1. OTOH Michael Lotz has a SVG 
> Kit almost ready and would be alright with donating it to Haiku, and 
> we 
> might want to have a second look at that one, as well. But I could 
> well 
> live with what R5 offers in this regard until R1.1 :-)

I agree with your view on doing it right. I wasn't sure on your stance 
on the whole SVG icon concept - AFAIK OS X just uses large pngs that 
are then resized to the desired dimensions before being shown. If that 
was the direction you were think of going with OT, I thought it would 
be a minimal addition to the API and I was volunteering to help get it 
done before R1 so icon designers weren't so constrained.

Any update at any time will still have the issue that "no other app 
supports it".

"Extending [the icon mechanism] right" to me means following the 
current api - like adding a new icon_size const. Of course if vector 
icons are the target that necessitates more API changes; and I'd 
certainly be against an addition in the normal bitmap direction for R1 
which is then removed and replaced with vector stuff in R2.
 
> > I expect none of the team will want to change OT much before R1 is 
> > out, 
> > and PoseView is pretty horrible, but if there is a plan for 
> > supporting 
> > higher quality icons in Tracker that someone (Axel) could explain, 
> > it 
> > might be something I would be interested in looking at. Move it off
> > -
> > list or to the OT list if you want.
> 
> 1) OT will be changed before R1, it's still a separate project.

I meant in any major way. I asked something similar on the OT list a 
few years back, and you mentioned intending a full add-on-based 
tracker, and that would be the time when the drawing code was 
rewritten. It was a long time ago though, I may have mis-remembered.

> 2) icons are not managed by PoseView

Sorry, long time since I looked at it.

> 3) I don't accept extensions to Tracker that don't reflect the state 
> of 
> the API (ie. there won't be any SVG icons in the main OpenTracker 
> until 
> the API supports them - use the Zeta Tracker or Michael Lotz version 
> of 
> the Tracker.NewFS if you want them now)

I'm aware of that - hence why I was suggesting an update that did 
reflect the current API, and why I asked your opinion on the direction 
icon support in Tracker was going in. I had no intention of doing this 
for anything other that the official OT - newfs already has good 
support for larger icons - I'm was more interested in improving the 
first reaction people have on booting Haiku R1.
 
> > If it is going to be necessary to create a new icon set, I think it 
> > would be nice if we could lift some of the constraints (the 256 
> > color 
> > one especially) from the designers which would force even the new 
> > icons 
> > to look somewhat dated.
> 
> 32x32 == 1024 - the real restriction is not the number of colors but 
> the fixed palette. Anyway, when we extend the icon API (some day), we 
> will definitely not keep it restricted to B_CMAP8.

Good news there :).


Don't bother replying to all that, here's my logic more succinctly:
-> Tracker's icon support is limited and dated (esp fixed palette 
issues).
-> Therefore at some point the icon support will need to be updated. 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).

This was motivated by my understanding that a new icon set would be 
designed for R1. However Michael's comments suggest the plan is to 
stick with Be's official icons. In that case I'd personally be happy 
with 1 or 2. What I'd hate is to have a nice new icon set designed 
(look at the CDT forums!) but constrained to only use Be's fixed 
palette for R1, before having to get the whole icon set redone again 
for R2.
 
Simon

Other related posts: