K3Icon

[Hamish Rodda]

Hi,

I also looked into what we need to keep in K3Icon a while back, the 
thread on kde-artists a while back is here: 
http://lists.kde.org/?l=kde-artists&m=116149732502501&w=2

Basically I think most of K3Icon should go, and the remaining few 
concepts we need to keep should be put into KIcon.

Aaron J. Seigo wrote:
> 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.

Yes, we should just have a KIcon constructor that takes an overlay as 
both a KIcon and an enum for standard overlays.

> 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.

Sure, this is just making the API more generic I guess.

> 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.

These groups are really for browsing through the icons, correct?  Or are 
there cases where the icons actually differ when displayed eg. on a 
toolbar vs. on the desktop?  If it is just presentation, can we make it 
metadata that doesn't go in the code?  And if not, why is it needed... 
to me, it just complicates the code.

Cheers,
Hamish.