[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    toolbar icons
From:       Torsten Rahn <torsten () kde ! org>
Date:       1999-12-19 7:48:35
[Download RAW message or body]

Ooops, it seems my quoting got completely messed up -- here a better
readable version. Sorry for posting twice :-(

> our toolbar icons.  They have served us well to this time.. but they
> have a few problems which need fixing.
>

Yes!!!!!!!!!!!!!!!!!!!!!! Finally!

>
> 1) They only come in locolor (8-bit) when most of us are now running
>    hi-color systems
>
> 2) They only come in "small" size (no medium or large versions)
>
> 3) Their size is wrong
>

Yes!!! It's really great that you did some research on this. This is
something that bugs me (and other people) since kde 1.0-beta4!

>  However, this isn't quite true!  If you look at the toolbar
>  icons closely, you'll see that MOST (if not all) of them are in fact
> 16x16 icons with a 3 pixel transparent border around them.
>
> I found this out when I was trying to use non-toolbar icons in a
> toolbar.  I noticed that the toolbar buttons assume that the
> transparent border is there.  This is wrong!  All widgets using icons
> MUST assume that the icon is "full".

Most people did it like this because there was a lack of the
toolbar-widget.
If one would use the full toolbar-area the pixmap would hit the edge
(i.e.
the shadow/highlight) of the button. That would look very
unprofessional.
Therefore it was part of the artists work to leave a transparent border
around the icon. Of course it should be the toolbar that should reserve
this
space making it impossible to use it.

> There are two possible solutions to this.
>
> 1) Say that the small size of the toolbar buttons is 22x22 but strip
>    off the transparent border off of the icons and make them the 16x16

>    icons that they really are.  The buttons must compensate for this.

> 2) Redraw the toolbar icons to take up the full 22x22 size.  The
>    toolbar buttons would then have to be bigger than that to have some

>    sort of buffer (for aesthetic purposes)

I favor 2). First because I doubt that all icons measure 16x16. I
think there are lots of icons which use about 20x20.
Second, it's really hard to paint very good-looking meaningfull icons on

16x16 especially using locolor. 32x32 is already way too big for most
applications and screens. Therefore 22x22 or 20x20 would result in
good-looking
and screenspace-saving icons. The border around should measure 2 pixels
on each side. (Jost -- what do you think?)

> I favor 1).

> My proposed to solution to problems 1) and 2) are the same: integrate
> the toolbar icons into our current icon scheme.

Yes!

> We know have (for example):
>
> $SHARE/icons/small/locolor/apps
> $SHARE/icons/small/locolor/devices
> $SHARE/icons/medium/hicolor/mimetypes

> I propose that we extend this by adding the following subdirs:

> icons/small/locolor/toolbar
> icons/small/hicolor/toolbar
> icons/medium/locolor/toolbar
> icons/medium/hicolor/toolbar
> icons/large/locolor/toolbar
> icons/large/hicolor/toolbar

I agree -- where

small = 16x16
medium = 22x22 or 20x20
large =32x32

It would be possible to support medium lo/hicolor and large hicolor for
KDE 2.0.
(We really can't support all sizes.) But all other sizes/color-depths
should
already be technically implemented.

ADDITION:

Something that would really improve the look of our toolbars (i.e. make
them more
decent) would be  desaturating toolbar icons on mouse-out and displaying
them
normally on mouseover. If you don't know what I mean have a look at:

http://people.redhat.com/jrb/GNOME-PIXMAP/index.html

the very last image on the page shows a beautiful apple made by TigerT.
It would be very nice to have at least the first (greyed out) and the
last effect
(less saturation) for hicolor-icons (If the user selects locolor-icons
this
option should be disabled).

(I would vote for the last one being default to avoid making KDE look to
triste.)
Right now our toolbar-buttons look very colorful. One should know that
toolbar-icons
usually are a completely different thing than application-icons:
- Toolbar-icons are usually more symbolic and simple to improve
usability:
You use toolbar-icons much more than application-icons
and need to find them fast. To seperate them visually from application
icons
(and to avoid that the desktop looks too blarring colorful) there are
two
things one may (and we really should!) do:

1) the artist prefers a certain shade of color (like Netscape / Corel
does
with their browser using shades of blue/violett). We already do this
with
KFM, too: this is the reason why the KFM looks so grey. Many people
already told me
that they would like to see the Netscape/Corel-like look for the
Konqueror-toolbar
instead and I agree very much on this wish.

2) greying out/ desaturate the toolbar-icons on mouse-out. This would
have to
be done by the programmer as providing two different pixmaps would be
too much
work for the artists in an OpenSource-project.

Application-icons on the other side are usually much more beautiful and
less
symbolic. Instead they try to be much more unique and original -- they
are the
brand of the application and are used to "advertise" the application in
the
users head (Think of the CorelDraw icon e.g. -- If you wouldn't know
what
this icon is about you would never guess that a
vector-graphic-application
starts once you click on it). Toolbar-icons are tools one just wants to
use. Making them too detailed, color- and beautiful decreases usability
a lot.

So if you implement the desaturation/...-effect this should be done for
toolbar-
icons only (or you should be able to switch it on and off for toolbar-
and
application-icons separately.)

Torsten

> Thoughts? Comments?
> --
> Kurt Granroth            | http://www.pobox.com/~kurt_granroth
> KDE Developer/Evangelist | SuSE Labs Open Source Developer
> granroth@kde.org         | granroth@suse.com
>     KDE -- Putting a Friendly Face on Unix

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic