K3Icon

[Aaron J. Seigo]

On Saturday 11 November 2006 19:14, Luke Sandell wrote:
> IMO, K3Icon::Overlays definitely needs to go, along with the corresponding
> KIconTheme methods. It is time to generalize the concept of an overlay and
> allow any icon to be used for this purpose. Right now we have ugly hacks,
> like the aformentioned as well as our special folder icons (folder_image,
> folder_html, etc). I think we should come up with some sort of standard to
> specify which corner of an icon should be used for what type of overlay
> (e.g. bottom right for emblems, bottom left for lock, etc). This
> functionality could then be incorporated into KIcon.
>
> Thoughts? I am just trying to avoid writing legacy code here.

well, yes and no. we should have some consistency in how icons are 
represented. it would be just asking for a mess to have every app specify 
which icon should represent a lock overlay by name. so there is a benefit to 
having such abstractions.

where i agree with you is that we should have the ability to overlay any given 
icon onto any other given icon. the defined overlays should simply call these 
underlying methods.

KIconTheme::*Overlay could probably be easily collapsed into one method that 
takes an int that is an overlay context as defined in KIcon.

we also will want the concept of "underlays". this is for things like the 
mimetype sheet. it should be possible to generate a mimetype icon simply by 
providing an application icon (for instance); the icontheme should then be 
able to compose the app icon on top of the mimetype sheet. complicating this 
is that some mimetype templates have a "3D" element to them and have parts 
that are supposed to cross over the application icon. so in the case of 
mimetypes we need an underlay and also possibly an overlay.

so the idea of "overlay" is a bit outdated, really. an alternative concept of 
icon contexts has been suggested by the artists.. so there is a "compressed 
file" context or a "mimetype" context. this would take a base icon (by name 
or a KIcon?) and one of a set of predefined contexts and "do the right 
thing". alternatively, one could manually add over and underlays.

i agree with you that the idea of noting types of overlays, e.g. "emblem" 
vs "sheet", is a good idea so one knows how to handle placement. an emblem 
would be sized down to an appropriate size and put in the first available 
corner; a sheet would be applied full size to the icon; etc...

these changes will affect KIcon (in kdeui/utils/kicon.h), KIconEngine and 
maybe KIconTheme? the big question, i suppose, is what parts of this logic 
belong where amongst these classes.

other improvements that are really needed:

we need at least two more groups: General and Filemanager. icon size for the 
filemanager does not apply to the desktop or to things like the run dialog 
and application configuration dialogs. right now, as soon as you jack up the 
file manager icons to, say, 128px, then icons -everywhere- grow in size which 
looks very poor and makes the desktop itself useless for putting anything 
there.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061113/53b8b9c3/attachment.sig>