I've benn using BeOS for a long time and I always thought that its 8bit icons were a big limitation from the GUI-attractiveness point of view... A month ago or so, on BeBits (BeOS software site) appeared an "SVG Pack" that brought SVG support to the OS along with SVG icons.
For those who don't know what I'm talking about, SVG is a vector-based image format that is being used, among many other things, for icons by MacOS X, Gnome and KDE: being not bitmaps, but vectors, SVG graphics can be scaled to any size ABSOLUTELY without quality loss.
It means that such icons can be of any size and still be pretty cool looking.
I think MorphOS should take this path for its GUI (MUI) in the future: I'm sure that SVG will become the format of choice for icons in a very short time. Those of you who have already seen SVG icons in action would agree with me...Go here to see how cool are my BeOS SVG icons!
I admit PNG icons are fine, but it's a question of technlogy: if MorphOS wants to be cool and up to date, I think it should keep SVG in mind. It would need a good redeveloping of MUI, but SVG is open-source, so it won't be a big matter.

What do you think about it? Are we going to see such changes in the future of MorphOS? I really hope that a part from icons, MUI and MorphOS will soon get a restyling...

Try to make something like current MorphOS icons using a vectorial format like SVG... it will be a bit difficult.

BeOS icons are very differents.

This can probably be done through a plugin-module for Ambient (in a distant future, far, far away) :)

i think displaying the vector image data is not too difficult (if there's a datatype which can handle it), a bigger problem is: how to store tooltypes and other icon information into such fileformat. It is possible with PNG or with IFF (w/o violating the file format definition), but with SVG too?

anyway... i personaly would prefer png icons anyway: they load faster, need less cpu and in the end they look better.

regards,
tokai

@Tokai

SVG is XML-based, so it should be easy to store icon information in there.

Hmm... I think MorphOS should support this format. I hate, that there is no standard size of icons, and every program comes with different size icon (OK, there is the rescale option of Ambient, but it's ugly, especially with old icons). There is no unique icon look, too. I would prefer the old GlowIcons in 32 bit. Mason is a good artist, but I don't like his new OS4 icons. I like the old Matt Chaputt one's better. :/

On the other side: supporting SVG would make the chaos much bigger. There is at this time 4 icon formats for Amiga and clones: OS2.x-3.1, NewIcons, ColorIcons and PNG Icons. I know, that this is the future, but need we a 5th format?

Technically an SVG with MorphOS icon information may not exactly "conform" to the SVG specs anymore. Also, the information would be arbitrarily stripped out every time you edited it (no SVG editors will "preserve" the tags.. most parsing will remove them anyway).

PNG has special provisions for this which is why the icon chunk is something like "icOn" (the letters have different "flags" hidden in them, see http://www.libpng.org/pub/png/spec/iso/index-object.html#5Chunk-naming-conventions - basically the MorphOS icon chunk is ancillary to the data stream (not necessary for decoding), privately defined (not PNG spec), the O is capital because the flag is reserved, and the last letter means "safe to copy", which implies "please store this data and put it back in when you re-save a PNG").

How do I know that? Well I designed the initial format :)

IFF chunks can be handled in a similar way by iffparse.library but it's much, much more crude.

Personally I am intrigued by the idea of using vector images for skins - for icons you tend to want lots of detail which sometimes isn't acheivable with vector graphics without embedding bitmaps. Most vector icons end up looking rather plasticcy as a result (and nobody implements the parts of thr SVG spec required to "texture" their SVG data properly). For window gadgets and border imagery though, the style is usually meant to scale with the fonts used (which bitmaps do not without creating 100s of seperate sizes) and things like scrollbars would be better rendered with vector imagery (see MUI xenbar.. that's a vector image).

That's far off though. We'd want to use an SVG parser that wasn't under the GPL, and tie it in closely with the graphics system. Cairo is promising (www.cairographics.org I think..) with replacable backends and MIT licensed. It currently doesn't support enough of the SVG spec in terms of the backends to render anything wonderful though. MorphOS has an XML parser already (expat based, with a tag API to make it simpler) that we can hook in. It's renderers and conforming to the specs I'm worried about.

Neko

The other problem is that there are no SVG image editors for MorphOS.
I don't think it is likely that there will be one in the near future.

--Aaron

@Aaron

This is no problem. Just boot into linux ;)

@killbill

I have a philosophical objection to booting into linux to make MOS
icons. I feel that if we are going to radically change our icon and
gadget system, we should be able to make the icons and gadgets on our
own platform.

--Aaron

Quote:

Now that could be helped quite easily I think......

@ RockmanX

Quote:

Let's get rid of that rumour once and for all... MacOS does NOT use vector icons. Doing photorealistic icons as found in MacOS X using SVG would result in a MAJOR slowdown (and would also be more complex from a graphician's viewpoint).

The MacOS icon format is *bitmap*-based and the default size of all icons is 128x128 pixels.


Quote:

Being "hip" and "cool" means nothing if you are just following some overhyped trend. Here is a quote from "jimmac" who is one of the leading graphicians contributing to GNOME and works for Novell Inc.

"What is specific about SVG icons is that it only works well for simple artwork. If you start adding a lot of detail the performance hit can become apparent. All of the current themes in Gnome are pretty simple, so you can hear statements about SVG icons being as faster than png themes. It was just designed so. The theme needs to work well rasterized to 16x16 px and also scaled up to 128x128+. Vectors are definitely linked with a specific style or set of styles. Aiming for photo-realism using vectors would be a bit foolish."


If you like the style of the BeOS icons, you may be happy to use SVG icons. People who prefer a photorealistic look (raytraced icons, etc.), have no choice but to use PNG icons, however. PNG icons are just way more flexible and usually also easier to create for novice users. In MacOS, you can just take an image on a website and turn it into an icon with a few mouse clicks. This just doesn't work for vector icons.

Once there is a native renderer editors would pop up pretty quickly.

Vector icons are looking not very appealing to me.
I like the photo realistic style.


[ Edited by Wishmaster on 2004/8/2 15:45 ]

OSX icons... PDF I assume? :)

Anyways.. one could do as in the linux desktops (and OSX for that matter), and not put any image data into the .info file itself, but rather reffer to an image file to use, be it png, jfif, ilbm, svg, or whatever the datatypes support. This would also make it _very_ easy to theme the icons.. just change the assigns to where the icons are stored, and tada..

Quote:

Nope, I like PNG icons.

As for SVG ... this is XML stuff. For a starter, there's no XML library in MorphOS yet. You've got to have this, and then you've got to have SVG rendering, and SVG can be pretty complex AFAIK. Given the small size and high speed of MorphOS I'd say you might well end up wasting more resources on icons than on the rest of the OS.

I'd be happy already if I could find all those icons I see on people's screenshots ...

Quote:

Please not! This would multiply the ammount of files and lead to some strange directories filled with a lot of icon resource files. And if you are interested in some specific icon you first have to look into the .info file to get the name of the resource file... Next disadvatage. The system would slow down because first the system must read all info files and then load (in a second read process) the according icon resource.
No, the current easy way with that info file being an iff or png with extended information within the file header is best I can think of. Just keep it that way.