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

List:       kde-usability
Subject:    Re: Include alphanumerical icons
From:       Sebastien Laout <sebastien.laout () tuxfamily ! org>
Date:       2003-11-20 16:24:23
[Download RAW message or body]

> > > I think it would be very useful to have alphanumerical icons - icons that
> > > just show a letter or a digit - available as a category in the default
> > > installation.
> > 
> > I thaught it was described in some KDE guideline that this is a bad thing
> > because it will look bad when people use another font for the interface
> > than in the icons and they also can't change the font. I fully agree with
> > this but maybe (I don't know if this is possible) font changing is possible
> > with SVG-icons: so in this case it could be useful but otherwise it's a not
> > done.
> 
> Since the icons don't show up in the default installation and are only for programs \
> the user adds himself, I don't see how they can possibly harm anyone. 
> If any user is offended by different fonts he can just not use them or replace \
> them, but even the availability of standardized icon names and places would greatly \
> improve the usability of KDE. (ie if you bind an app to the "A"-icon and then move \
> the settings to another KDE-machine, the correct icon shows up and not the \
> "unknown" icon.) It would greatly reduce the hassles when upgrading or reinstalling \
> distributions. I lose icons all the time that version xy included or I added myself \
> but version yz doesn't. 
> These icons don't have to be beautiful, they don't have to be in SVG and they don't \
> have to support different fonts. People who want beautiful ions don't have to use \
> them and won't use them anyway.  These icons are for people who just want the job \
> done (= assign any icon that is distinguishable and available in future versions)  \
> without hassles.

There is a good way to do this (IMHO).

First, take a point of the actual solution :

* All apps that want an icon call a class method and don't get icons
directly by loading file with hardcoded path !!!
* With KDE 3.2, icons will can be in SVG format : only one file and
icons will be GENERATED for different sizes : apps doesn't see this.

So, I propose :

* To have a special KIcon::Number category that will GENERATE the icons.
* Icon themes can go with theire own Number icons, that can be :
  - PNGs as now (or SVG in KDE 3.2)
  - Better, provides 16*32 images with only [0,9] numbers (and
    then image will be centered for [0,9] asked icons
    or combinated side by side for [10,99] asked icons)
    (16*32 in the 16x16 directory, 8*16 in the 16x16 directory, etc...)
  - Can be PROGRAMS (plugins...) as KWin styles are !
    KIcon will then call the IconNumberFactory program according the
    current style (provide a KDE default IconNumberFactory if style
    hasn't Number icons : this factory could take care of current
    fonts ! )
* Then, icons can be cached for faster next asks ; and we haven't to
provide all 100 icons : just 10 or those they are needed...

To summarize, I don't think number icons is a bad idea if they are
GENERATED (KSVG already generate icons, so why not numbers icons),
* according font (very simple : no specific icons per theme (as now) is
needed : default factory is used insteid of recreate the wheel for each
apps need number icons)
* or according the icon theme (if this theme provide custom icons)
* or the both in same time (if themes provides programs that generate
icons with current font AND icon theme) !

With this good design, I doesn't see where is the problem.
Isn't it ?

Best regards,

Sebastien Laout.

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


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