Aaron J. Seigo
aseigo at kde.org
Mon Nov 13 16:53:52 GMT 2006
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
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
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel