K3Icon

[Luke Sandell]

Hello,

I am the author of KIconDialog++, and have begun porting it to Qt/KDE 4. My
question concerns the role of K3Icon in KDE 4. The fact that it has been
renamed seems to suggest that it is deprecated. However, we at still need
to have the K3Icon::Context enum to designate categories for the icon
chooser. I'm not sure about the other enums: K3Icon::StdSizes,
K3Icon::Group, etc. Hopefully with the new size-independent KIcon class and
scalable graphics there will be no need to query icons by a particular size
(there will still need to be a way to tell the icon dialog how big to make
the icons in its QListView, but this could be a simple integer or QSize).
K3Icon being an such awkward name, if the enums are still needed for
reasons other than backward compatibility, they should IMO be moved into
another class or namespace. 

I also notice that somebody has added several new items to K3Icon::Context,
apparently to conform to the Tango specification. Don't know if we want
these contexts to be displayed by the icon chooser - they are pretty
specialized (emoticons, emblems, etc). Also, if we ever want do conform
completely to the Tango specification, the long icon names will never fit
into the icon chooser without introducing ellipsis hell[1].

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.

P.S. - I have found Qt's Model-View classes very helpful for this project! I
have subclassed QAbstractItemModel to provide the icon list to the dialog.
Not only does this make coding easier (and dispenses of that EVIL hack,
KIconCanvas), it also allows us to batch-load our icons on demand, meaning
there is no more "progress bar" or tiresome waiting for the icons to load!

1.http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

-Luke Sandell