As MacOS X, and arguably, GNOME, have shown, many people love photorealistic icons despite the theoretical trade-offs with usability. So if you've ever wondered about the philosophy behind KDE's default icons, you might want to read Torsten Rahn's recent article on the matter. Tackat explains how KDE's default icons are a compromise between good usability and beauty, using a mock up of traffic signs to illustrate his points. To conclude, Tackat proposes a slightly different approach for KDE 3.1: Add more photorealistic design to the application icons, while sticking to 2D for toolbars and mimetypes. But wait, there's more. In related news, Kristof Borrey has announced the release of iKons 0.5.5. More importantly, Kristof is now working on getting iKons 0.6 in shape for inclusion in KDE3. For other icon activity, check out everaldo et al on the kde-artists list. I should also point you to the growing number of KDE icon themes on KDE-Look.org.
Comments
I agree i think the current icon set needs modernized without becomeing a total mac or windows rip off. iKons are not pretty enough for me though. They to greyish and don't have enough color.
Craig
I like that the current KDE icons are not photo-realistic. They are what they are supposed to be: icons, not photos.
That said, there are some very nice ideas in iKons. It would be worthwhile having this as a second standard KDE icon theme.
If you want to see what the 'enemy' :) is doing, here's a link to what will become the Gnome 2 default icons. They, too, have moved away from photorealism:
http://primates.ximian.com/~tigert/new_stock_project/
Note the slight influence KDE's icons have had on them :)
Howdy from the "other camp" :)
I pretty much agree that having photorealistic icons is bad for usability - unless they are very big. They work pretty okay on MacOSX because the icons are just huge. It works well for the desktop/panel/application icons on GNOME too, though I wouldnt call the style "photorealistic". I think it is more like "cartoony" or "airbrushed" (I use the Bezier tool in Gimp much like airbrush artists do with real world tools). But whatever people want to call it..
Anyway, the "big" icons on Gnome have a 3D perspective look. I decided to not go with "isometric" perspective (45 degree angles everywhere, a good example is BeOS) because I wanted to make them more natural looking, but Tackat has been doing a very nice job using isometric angles for KDE icons. I guess it is a matter of personal preference and style. Isometric definitely gives you less jaggy edges if you do 1bit transparency versions of icons.
Now, to the "KDE influence", noooooooo! :o) Seriously though, the current GNOME toolbar icons have a 3D perspective, but I have realized the same usability issues with them, the 24x24 pixel grid is just not enough for perspective tricks, the resolution is way too low. Even when we now have full transparency support for toolbars thanks to Gtk2. It would just look too blurry. Thus we made the decision to go with flat "face-on" perspective (which MacOSX also uses for toolbar icons by the way) - it makes it a lot easier to do clean, understandable icons.
For the style, I bet every designer takes influence from others. I like Tackat's work, although I personally prefer a bit less bright color palette. But I guess the biggest influence for the lighter colors has been from using Macos, mostly MacOS 9.x (for printwork, I need Illustrator to do that, and Mac is the way to go with those apps) - Apple uses a very light and "happy" color scheme which I like. And it looks like WinXP is also going to the same direction. Beos was like that too. I was never too fond of making my desktop look like Quake anyway .. :-)
In any case, judging from the feedback I and Jimmac got from the icons, looks like we are going to the right direction.
By the way, I found a nice link to WinXP icon style guide, they suggest people do icons first with a vector drawing app and then convert to bitmaps from that. The page also gives the winxp color palette, which is a lot like the one I did for GNOME, though it has more blue colors.
href="http://msdn.microsoft.com/library/?url=/library/en-us/dnwxp/html/winxpic...
Sometimes I wonder how much influence Microsoft takes from us.. I think I see some Gnome and KDE influence on WinXP ;-)
Best wishes,
Tuomas
To me, the technical underpinnings of the icon system need more attention. Bitmaps only make sense when you have limited range of display resolutions, but this is no longer true. A handheld might have resolution of 50dpi while a nice display can have up to 140dpi. The range is too large for bitmaps to work.
I'd prefer to see icons implemented as SVG. This is how MacOS X works. There has been some work to add more SVG icons to GNOME. An initial screenshot from many months ago is here: http://jimmac.musichall.cz/screenshots/gorilla4.png
Would anyone else like to see scalable icons in KDE?
I agree. Gnome icons are indeed beautiful.
The problem with using vector graphics, is that you have no control over how things look when you scale down.
Notice that the screenshot you posted had rather large icons. How good do you think they would look, if scaled down to 32x32, or 16x16?
The advantage of having multiple bitmaps, is that the artist can hand correct the smaller icons to still look good and be recognisable
This is not true. An SVG can be created to add detail as it is scaled up, and remove detail as it is scaled down. It is very powerful, and can even be used to do things such as zoom into a fractal.
But does any image editor support those features? -_-
No, but things like Adobe Illustrator manipulate SVG.
I would like to!
And about little icons in svg looking bad, well, I already saw some screenshots of gnome with svg icons and ultil 22*22 they look great, don't know about 16*16, but this size of icons is getting in desuse in KDE already.
> 16*16, ...icons is getting in desuse in KDE already.
16x16's still see frequent use on 800x600 remote X terminals. This type setup is more common than an owner of a single-user install might think--offices, schools and even homes of resourceful users where one newer box runs KDE and old hardware provides seats. Think LTSP: http://www.ltsp.org or City of Largo.
So.. in this case, why not simply using a option to user choose between bitmaps and svg?
I want svg, some want bitmap, let's make both of them happy :)
Sure, just make SVGs for all the KDE icons, and code in that option, and that would be great! :-)
If SVG icons are used (let's hope they finally are) the method should be similar to the one used with some scalable fonts, that is: include bitmap "snapshots" for some concrete resolutions, for example for 16x16 and maybe for 32x32, when the SVG icon might look bad. This does NOT mean including snapshots for all icons at a particular resolution, it just means that if the author thinks the icon will be used at 16x16 and will look bad, he should include a bitmap version for that resolution.
If not, anyway, we are now using 16x16 and 32x32 icons. What's the deal with leaving the 16x16 icons and replacing the rest with SVG?
I always create two panels, each at size TINY.
This causes me to use 16x16 icons, and that's the way I always do it on my 1024x768, because this way I still have plenty room left to place my apps.
Most icons you see in KDE are displayed by the application menus and especially by the Kicker menu. These icons are displayed at 16x16.
Most other icons are displayed in the toolbars (22x22).
Then there are the icons on the desktop: Still most people are using 32x32 there (Of course I like 48x48 much better).
So how do you get your idea of 16x16 getting "in desuse in KDE already"?
BTW: I haven't seen too many screenshots showing svg-icons at 22x22 - perhaps you could post a URL :-) ?
Greetings,
Tackat
Good question, I tryied finding it again but couldn't (maybe I dreamned?) :)
But you can simply test it. There is a plugin for netscape on adobe.com, and you can try getting gnome .svg icons and resizing it, I'll try it for myself to see the results, but judjing by flash examples I saw already, probally it gets good.
But anyway, svg should be used for 32*32 or bigger icons IMHO.
How fast processor is needed to render such icons ? Some apps need to display a few dozen icons at start, so they must be rendered and stored as pixmaps somewhere.
i fear it will be slooow..
svg is xml-based afaic, and xml parsing is slow, and offcourse
you need to do extra math for rendering..
maybe we could get around that by reviving the icon server or icon cache idea,
i don't know a lot about the topic so excuse me if i'm talking nonsense.
The question isn't how fast does your processor need to be, but rather how good is your programmer? MacOS X uses SVG icons and it runs interactively on really stupid and slow CPUs like the 300MHz PowerPC 750. You don't need bug iron, you need smart programming.
Are you good enough, then, I take it?
If so, I am sure ksvg developers would appreciate your help.
More signficantly, though, IMHO, SVG is a ridiculously complicated standard, which is an overkill
for icons. And in general, how often do you want to see an icon larger then 48x48?
:: how often do you want to see an icon larger then 48x48?
When displays start leaping ahead to resolutions expressed in hundreds of DPI. Memory is now cheap, even video memory, and the CRT is being discarded. I have no doubt that a major factor that will hold back exponential leaps in resolution is pixel based systems. Right now, write a new widget set and window decoration, and most things in KDE will scale - except icons.
Having said that, I'll kick in my 2 Eurocents to the thread. Bitmaps display quickly. They should be the default. Extending the icon system to *support* SVG is a good thing for those who want to install icon packs that use vector icons (read: people with multi-gigahertz machines). That also moves a final step towards being able to discard pixel units as resolution (note that it is not the final step in actually doing it, just the last system that comes to mind that needs to be fundimentally reworked).
--
Evan
But why not use the .svg icons to -batch generate- bitmap icons
of the required size in advance (even during installation)? (Or certainly a 'commonly used subset' of them.) Thus one has a speed/space trade-off that can be set as required. That said, this is part of the job of an icon cache,
so I guess that's where any effort on this cort of thing should be directed (if necessary). Besides that, if you recall how fast early versions of Xara studio
were at anti-aliased transparent rendering (on Win95 that is), if the rendering
architecture is fast enough, this shouldn't be a problem anyhow (if it is,
speeding up rendering of the .svg's should become the priority).
Personally, I think .svg is the way to go with icons. I know little about
.svg but, is it possible for aspects of an .svg image to be parametrised (e.g.
for colour schemes, etc.?).
On a 400dpi display, a 48x48 icon would be practically invisible. You'll have a 400dpi display in fewer than 5 years. All modern computer display systems have OVERWHELMINGLY rejected bitmapped fonts in favor of scalable vector fonts. TrueType fonts, the popular flavor, are vector glyph descriptions each of which comes with a little program that runs inside of a virtual machine. Why not do the same for icons?
Think SVG icons would be slow? You already draw tens of thousands of scalable vectors all over your screen all the time.
> You'll have a 400dpi display in fewer than 5 years.
I already thought this 5 years ago. While working on KDE 2 I did some research concerning this topic on expos like CeBit. Judging from that I'm quite sure that you'll be wrong for the next 5 years, too.
I don't whink that we will have resolutions like 3200x2400 in common use any time soon: think of all those myriads of webpages out there: each one would have to be redesigned (or displayed with magnified bitmaps).
And yes: drawing svg-icons would be quite slow as you need lots of shades, alphablending, etc. Don't get me even started to talk about the limitations you run into once you try to paint some very close parallel lines!
Tackat
MacOSX *does not* use vector icons! It *does not* use SVG icons. I don't know where this rumor started but it's absolutely not true. MacOSX icons contain normal bitmap graphics for the icons in 3 sizes, then uses scaling to make it the proper size (kindof like KDE, except all the images are in one file ;-). One of the sizes is 128x128, so it can scale down to whatever size it needs. I don't know if Gnome started the rumor but it's not true, because it's a dumb idea.
Vector graphics for icons is a horrible idea. You can't "paint" them, you have to draw it all as graphics primitives. Not only do you then have to parse a graphics control language for all the icons, but then you end up with icons that all look like Windows Meta Files. "Painted" icons are much higher quality, not to mention can be created in any drawing application.
I ment that the rasterized versions could be stored somewhere on the disk, so all frequently used icons would be always ready to display as pixmaps. If there would be no pixmap version or SVG file would have the later modification time, the pixmap should be (re)generated. However I think that it is a huge work and no advantages over the ordinary method.
What about tools like autodraw (iirc) that attempt to convert bitmaps to vectors? That way, the icon's don't look significantly different, but it's easier to do things like smooth scaling, isn't it?
It would be impossible to get the same quality as you can with a painted icon. How do you describe something like a photograph or photorealistic image as vectors? You can't, (well, actually you can but the result would be much worse than scaling because each pixel would be a vector point ;-) As you figured, it's not only far easier to do smoothscaling but also this provides much better results. Like I said, with vectors you end up with images like Windows Meta Files, not Photoshop ;-) Whoever spread the rumor that MacOSX uses vector icons was *wrong*. It's nonsense.
Hmm, isn't there any vector conversion tools that convert bitamps using higher levels of abstraction though? Things that attempt to discern high-level things like gradients and lines and curves within a bitmap, to produce a vector that was truer to the original bitmap? I'm not volunteering to do such a thing, nor attempting to say that such a thing would be a good idea, but merely asking if such a thing has been implemented or is being implemented, or is even plausible?
Also, I never said MacOS X uses vector icons. However, there are a lot of things that MacOS X doesn't do that KDE/UNIX does (such as Open Source the GUI :-)
You can make good looking vector icons, just look what Jakub did with the Scalable Gorilla - and he just started to do vector stuff not that long ago.
Of course it is a lot more work, and the tools are different, but it is certainly possible. The style will naturally look a bit different, but if you end up with bad clipart then you have a bad artist :-)
I agree with you though, that it makes no sense to render the stuff on screen as vectors, one really renders to a bitmap and caches that. It gets really slow otherwise too.
Tig
I can't say about MacOSX because I'm clueless.
Alas, there's something else: when you draw icons, or do any graphics,
using a painting program, you really do abstract, vector things, even if you
*think* you're working pixel-oriented. Most painting program operations, such
as fills, gradients, filtering effects are just atomic operations that you
could essentially do on an image scaled to any size. Imagine you draw a zig-zag
with a pen, and then add a few finishing touches to it, finish it wish a shadow.
All of your "operations" were abstract - they didn't necessarily need to work
on image of that particular size. Well, if you say that changing a single pixel
is not too abstract think of this: it may be not too abstract if you look at it
as changing (r,g,b) triad in the array of 32-bit pixels.
Things change if you think of it as modifying an infinite-resolution image.
Infinite-resolution images don't contain more information than finite-resolution
ones, it's just that the representation allows much nicer scaling. A line or
a bezier on such an image always retains its shape and never becomes jaggy
(if you scaled a bitmap, it would), and single pixel alterations will be seen
as gaussian peaks (for example) of given color. When you work on a 256x256 icon
that way, it will always render exactly same for 256x256 size, you can
even hint it a little if you think that "default" rendering algorithms do
a bad job at say 128x128 size. That's what's done in font rendering. Yet, if you
have that crazy 210 dpi display device, and you want your icon to still be of
the same size on the screen, it should render just fine even it its 768x768 then.
I'm not saying that bitmap scaling would do a bad job there, it's just that
for things like printing, or low-resolution displays, it's always a good thing
to get a non-pixel-oriented representation. Bitmap programs reduce information
- you draw a vector, you get changed pixel values. The fact that this was a
nice vector, or a nice "lighten" pen sweep is lost forever in all but simple
images.
I would say that the fact that SVG doesn't support most of this theoretical
framework is irrelevant. It can be done, and it can be done nicely, and it's
about the only way to go. A decent renderer can take less than 100kb of
compiled code and execute perfectly fast on a 486/100 embedded system.
So, while most posters here are right that SVG is useless, it doesn't mean that
non-bitmap oriented icon handling is a wrong thing to do. Alas, I'm personally
in disfavor of text-oriented formats (like SVG or XPM) for distributions, since
they are size-hogs - even if *after* they get loaded they consume little
space, they still need that much cache and buffer space in order to *get*
loaded, and on small systems that's what does make your disk churn away
needlessly... All xml-like hierarchical markup documents can be represented
very effectively in binary form, with size benefits (without any further
compression, ie. w/o using bzip-lib nor zlib) for graphical (svg-like) markup
well in 1:10 area.
Cheers, Kuba
1. Vector Icons are much easier to make. Anyone doing a lot of graphics knows that for drawing, you need a vector app.
2. Scaling vector icons is NOT easier, it might even take more, because for every size the complete icon has to be redrawn on the screen. Imagine a osX dock, rasterizing 20 resizing vector icons all at the same time. Combining Pixels for scaling is much more efficient. If you want to use vector icons, and scale them, then it'll probably be faster to cashe the rasterized icon (bitmapped) and then resize that one.
3. Vector icons aren't useful. Icons are small, and then the vector icons will probably be even larger in size then bitmapped ones.
SO
make them in vactor, raster them for usage. That's the way.
Vector Graphics are great, but unuseful for icons.
Vector graphics for Icons can in fact be painted, just as well as a bitmap or raster images can. As long as the rendering engine supports gradients, all sorts of FX can be implemented. Vectors can be automatically traced out of Bitmaps which use patches of color(not necessarily on a per pixel basis) to render photographic images. The added advantage of vector? Independent resolution at any size. Make it big and it stays sharp, make it small and it's still clear.
I don't know why you spread this nonsense here but just to keep things correct:
Mac OS X does _NOT_ use SVG-icons.
There are nice articles on arstechnica available like this one
http://arstechnica.com/reviews/1q00/macos-x-gui/macos-x-gui-6.html
which discuss how Mac OS X works in regard to icons. If you read throught them you might realize that the technique used in Mac OS is comparable to the one that KDE is using (in fact KDE even does it in a superior way).
They store each icon in several sizes (128x128, ... , 32x32, 16x16) and SCALE them down to the size needed.
You can even SEE this in Mac OS X if you look at the icons while dragging the scaling-slider: at some points (48x48, 32x32 e.g. ) the icons get a lot sharper!
Concerning Gnome: They don't use SVG's yet either. Unfortunately the SVG's done by Jimmac are not available for download yet - they exist on screenshots only.
Apart from the screenshots I haven't seen them anywhere so I don't know how slow it works. But I guess there's a good reason why the new icons they made for Gtk2/Gnome2 are still based on pixmaps ...
Tackat
The theme works (the screenshots are not mockups that is, but real ones) - but it is a bit slower. It is of course slower to render a vector illustration than it is to load a bitmap. It is not that bad in reality though since Nautilus is caching the stuff, so it is not getting rendered all the time.
But yea, at least I find it easier to draw bitmap icons since I havent done vectors much yet. The SVG is neat if you want to scale icons large though. I used to have this one huge trashcan on the desktop a while ago. An artist gets a lot of scratch paper you know :-)
Tig
What about complete SVG background ??
Without real icons, but objects scaled directly in the background -the desktop-
Coupled with javascript -like we do with xhtml... xml-
It could completely interactive
Filling on the background, SVGed space to display any type of informations !
Like RSS, xHTML... any xml compliant style !
(using associated xmlns)
I'm personnaly tired of the concept of icons ! :/
KDE's icons are ugly as shit. If people think this doesn't directly impact KDE's usability, well, they should just keep on using KDE. No need to drag OS X and GNOME into things.
That's true, I find GNOME ugly as hell and the Icons not just ugly but completely unusable. I never know WHAT I am clicking on when I click on a GNOME icon.
GNOME icons has zero customizatability like KDE icons. Everybody misses this point. KDE is so flexible, it doesn't matter what the icons look like, you can change anything.
The fact that KDE icons are so well designed and clean doesn't enter into it.
Gnome icons (indeed all GTK+ icons) will be customisable from 2.0+
http://www.kde-look.org/content/preview.php?file=732-1.jpg
What about these?
Some are kind of cool but the home icon is to dark.
instead of moaning, get off you lazy arse and create some damn icons. Add some colour to the 'home' icon, make other changes you see fit and release it to the world as a new icon set. KDE has too many moaners and not enough contributers.
> instead of moaning, get off you lazy arse
[...]
> KDE has too many moaners and not enough contributers
have a look at control center -> font installer -> about
BTW constructive criticism is good thing and this is what Craig did. IMHO you over-reacted a bit...
Umm.... I wrote the font installer, but it wasn't me who posted the previous comment. I have *no* complaints with the KDE icons...
They rock ! Good work.
everaldo ... Look in kde-artists mailing list ... Those icons look really cool imo
-- Fab
Nice, I missed that. Is there a web-page for the everaldo icons? Oh well, I just added a pointer to kde-artists.
They are not everaldo's icons. Some of icons are MacOSX icons, some of them are KDE default icons, some of them are iKons folders.
What everaldo did? He (just) applied one glassy effect on all of them, changed color on some of them and that's it. Yes they look nice with that effect, but I expect something more original from him, because he is talented :)
Yes, but what he did is magic! :) Take the KMail icon for example. I've never really been very fond of the original KMail icon, but with some everaldo magic it suddenly looks very attractive. No need to create an entirely new KMail icon now. People will still recognize it (doesn't need to "learn" a new icon) but is still treated with a fresh new look. Lovely.