From kde-core-devel Sun Nov 12 02:14:09 2006 From: Luke Sandell Date: Sun, 12 Nov 2006 02:14:09 +0000 To: kde-core-devel Subject: K3Icon Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=116340284022652 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