FreeLists / openbeos / [openbeos] Re: Icon Artwork

[Simon Taylor <simontaylor1@xxxxxxxxxxxx>]

That sounds great. Would be nice to have a "global icon size" settable 
somewhere for all icons (toolbar etc) - a fully scalable UI would be brilliant. 
It's maybe hard to do this cleanly whilst maintaining binary compatibility 
though.

I just wanted to say congrats to stippi for his work so far - I like the 
concept of vector icons but SVG seemed such a waste of space. Stephan has 
covered all of my gripes with vector icons scaling to small sizes and the 
storage issue.

I claim responsibility for starting at least a couple of design related threads 
in the past however many years (doesn't time fly?), mainly with the message 
"please lets have a new look for R1", so I'm very happy with the way things are 
going.

I'm off to play with Icon-O-Matic now.

Simon

ps: I don't want to derail the thread, honest, but on the visual topic I'm not 
a big fan of the new(ish) submenu arrows displayed. I like all the other visual 
tweaks that have gone on, but the submenu arrows seem far bolder than the text 
itself and seem to emphasize the fact that it's a submenu much more than the 
text that tells you what it's actually a submenu of. I hope this is still 
relevent, I haven't used a new Haiku build for a couple of months.

> 
> From: Stephan Assmus <superstippi@xxxxxx>
> Date: 2006/07/31 Mon PM 08:18:02 GMT
> To: openbeos@xxxxxxxxxxxxx
> Subject: [openbeos] Re: Icon Artwork
> 
> Hi Jonas,
> 
> I agree with what you have said about the "current theme" and "meta" 
> mimetypes.
> 
> 
> > The only drawback I see is the icon size being fixed. :P
> > Perhaps Stippis new "vectopia" will make that less of
> > a problem? ´:) Anyway. Just an idea.
> 
> Well I intend to solve it this way: Since the application gives you a BBitmap 
> to draw the icon into, it becomes quite easy to support scalable icons. The 
> application should be expected to give you the bitmap in the size it wants, 
> simple as that. For this first step, it will not be possible for the 
> application to get at the actual vector data, but scalable icons per se would 
> be supported. So all current applications, which pass a B_CMAP8 bitmap, keep 
> getting this version (possibly a dithered vector icon, possibly a normal BeOS 
> icon), but in any new application, you can try to request a B_RGBA32 bitmap 
> of any size you like, if you're actually running on Haiku, you get what you 
> asked for, if not, the call returns with an error, and you can try again with 
> the plain old B_CMAP8 version. Actually this is what I thought how yellowTAB 
> would have implemented it, but disappointingly not so (I never got around 
> looking up what new API they have introduced for getting the SVG icon, and 
> they never cared to support old applications with a dithered version of any 
> SVG icon). I never understood why they didn't go with this simple and fully 
> compatible solution. If anyone knows, please speak up... :-) Anyways, with 
> Haiku, I'm sure we will go the extra steps to make for a smooth transition 
> towards vector icons.
> 
> Best regards,
> -Stephan
> 
> 

-----------------------------------------
Email sent from www.ntlworld.com
Virus-checked using McAfee(R) Software 
Visit www.ntlworld.com/security for more information