Bug 31617 - A Proposal for more advanced icon handling in KDE
Summary: A Proposal for more advanced icon handling in KDE
Status: RESOLVED NOT A BUG
Alias: None
Product: kde
Classification: I don't know
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-08-26 14:48 UTC by kdebugs
Modified: 2020-09-30 00:52 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kdebugs 2001-08-26 14:48:03 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           konqueror
Version:           KDE 2.2.0 
Severity:          wishlist
Installed from:    Debian Packages
Compiler:          Not Specified
OS:                Linux
OS/Compiler notes: Not Specified

No file manager yet gets icon handling
right yet.  Konq comes very close.

Many icon's on your desktop are composed of parts: a base type (A CD-ROM for example) and then something more specific to clarify it (Perhaps super imposing a movie camera over the CD to designate that this is in fact a DVD).

Icon makers are required to painstakingly assemble many icons to represent postscript gif wav mp3 each carefully super imposed over some standard image that represents a "File".  If you want to change the image that represents the "File" you need to resave dozens if not hundreds of files.

What is even worse is that different icons are necessary for different scales.  Using the example I described above scaling a CD w/ a movie camera superimposed over it down to say 16x16 necessary for display in a tree view of a file system it becomes unrecognizable.  So you create a small view: just the movie camera.

What I propose is that Konqueror be smarter about Icons.  It lets you choose a base icon for logical groups (CD is a good example Document is another Directories are the other most common but there are more).  This base then has some simple rules about superimposing the more specific type image: the dimensions and location.  Maybe opacity and what not but thats getting a little silly.  Also what is the Smallest size the icon can go and still meaningfully superimpose the other image.

Now what can happen is a user can have a collection of images to represent data types and he can easily change the icon he uses to represent "File" or "Folder" without actually having to resave hundreds of pngs.  And KDE can be smart about its icon selection too: when an application needs a small icon it can simply return the top image instead of the base image.  Thus removing the need to build different icons for different scales.

Admittedly this is less relevant for custom hand drawn icons such as the set currently in use in KDE but for photo-realistic icons this functionality would be a godsend.  And I think this sort of icon will be very desirable in future desktops as demonstrated by MacOS X.  As alpha blended icons become standard (they already are within KFM the desktop and the panel itself...  hopefully soon they will also be standard in menus trees toolbars etc) we will start needing tools like this to really make things look lovely.

Plus there are other interesting options... like superimposing icons to represent "Locked" for files you can't read...  or something to represent compressed files.  Suddenly a file that you don't have permission to read can be visually apparent that it is say a PDF but also that you don't have perms.

Finally is a minor thing.  Rid KDE of these arbitrary icon dimensions.  16x16?  48x48?  Give us a slider.  10..256.  Let the user choose.  Some resolutions won't look nice but let them choose!  KDE itself can already handle this but the icon themes restrict themselves and the kcontrol app is a drop down.  Artists don't think in terms of powers of 2 and shouldn't be restricted as such.

(Submitted via bugs.kde.org)
Comment 1 Daniel Arnold 2006-11-03 19:37:05 UTC
As this bug is quite old there were several efforts in the meantime adressing that topic via making icons more uniform. For example the crystal icon set and many others. As well icons now get designed as SVG files. So artists can reuse basic icons more easily.

Stacking several icons is not trivial if you still want to have it looking pleasant. So I suppose artits would reject that idea.

As this does not really affect Konqueror but the general icon handling of KDE I have reassigned it to the HIG (no other component seems to fit better) so that the HIG people can review that bug.
Comment 2 Celeste Lyn Paul 2008-09-14 02:27:25 UTC
Is this related to XDG? http://www.freedesktop.org/wiki/Specifications/icon-theme-spec

This isn't a HIG bug, are we using this already in KDE? If not, should we?
Comment 3 Nate Graham 2020-09-30 00:52:56 UTC
There is an XDG icon spec now, which supersedes this request, I'm afraid. :)