[openbeos] Re: Tracker icons
- From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 13 Jul 2005 19:46:45 GMT
> "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:
