Description: An improved icon dialog for KDE. This is just a preview edition, but the source code is more or less complete. It even includes a test application. If for some strange reason you wish to build it, you must manually edit the makefile, seeing as it is not yet autotooled. See README, BUGS.Last changelog:
Version 0.3
- Fixed some of the annoyances with the initial GUI. - Scale down non-system icons that are larger than requested size. - Change lockUser and lockcustomDir parameters to lockContext and lockBrowse, respectively, because that is more descriptive of what they currently do. - KIconButton supports all options of KIconDialog, including customDir, lockContext, and lockBrowse. - Full-featured testbed, KIconTester.
Version 0.2
- Totally new GUI layout, done with Qt Designer. - KIconCanvas split off into its kiconcanvas.h and kiconcanvas.cpp (so that it could be used in the GUI design). - Searchbar is now replaced by progress bar during loading. - New "Recent" category saves recently chosen icons. - Icons are now sorted case insensitvely, for bad icon themes that contain caps. - "Mimetypes" renamed to "File Types" - "Filesystems" renamed to "Filesystem" - "Search" renamed to "Filter"
What do you guys think about a zoom in/out tool? (Like in Konqueror). Useful or a waste of space?
Back to the mockup: I think the "Browse..." button and the filter bar should be at the top, and the browse button should be to the right of the bar. Also, I kind of miss the "Clear" button, even if I never use it.
The actual icon dialog load takes long time loading all the icons each time. It doesn't use cache for showing them quickly.
Have you considered improving the speed by using icons cache?
Good job!
Yes, I have considered this. The problem is that when you start caching icons you can use up megs of memory really fast. This is especially bad because the icon dialog is inactive most of the time, so it doesn't make sense to keep it loaded in memory. And of course there are going to be multiple instances that cannot share the same icons in memory. The real solution, I believe, is KIconServer, which provides a system-wide shared cache for the KDE icons.
hi, this is the first descent Idea I have seen for a while, I've always had problems with my own Icon Changer, it should be put into KDE as soon as possible.
i think it would be far better if the browse button would be on the right-top corner of the dialog, with the filter edit field left beside the browse button, and let the category list span over the whole vertically space
just my 2 cents for this...
bad that you cannot edit your posts...
better if you put the filter edit field and the browse button at bottom, below the icon list, but the browse button right beside the filter field and let the category list span over the whole vertically.
i think that would finally solve the "browse issue", since in all other dialogs like the "open file" dialog, the browse button is at right-bottom too :D
Ok finally got it to compile so here we go with what I had to change.
First:
kiconcanvas.cpp:121: error: 'min' is not a member of 'std'
#include
instead of
#include
Which meant I had to add -I/usr/include/c++/4.0.3/
Is this something odd with gcc4 vs gcc3 or what's the deal here? perhaps its something to do with visibility as I have that enable? -fvisibility-inlines-hidden
Tho I've not had a problem like this yet.
Next Linking errors:
cannot find -lkdecore and -lqt-mt
Add these to the LIBS var.
-L/usr/kde/3.5/lib/ -L/usr/qt/3/lib/
And there you have it .. now to see if this thing works! :D
yes but I figured I'd report it to find out why I had to edit the source to fix that compile error.
plus it seemed rather odd that the library search path wasn't included in yours?
It's simple. Every distribution is different as far as where it stores its files. For me, KDE libs are stored under /usr/lib, for you they are stored under /usr/kde/3.5/lib. Since /usr/lib is already the default library path, i didn't think to include it. As for the <cmath> thing, I don't know what the problem is. I do know that you should _never_ have to include <bits/stl_algobase.h>; that is an internal header to gcc that is not meant to be used directly. Try doing a find /usr -name 'cmath' and see what that turns up; then, add it to your include path.
Whenever I open up the application, I have to wait some time for the the fault category to load. This gets very annoying after a while. I suggest that when it is opened, instead of loading a category, a small piece of text is shown, inviting the user to choose which category to look at.
This won't do, because some applications request to open a particular category.
However, this could be sped up somewhat by KIconServer, which was discussed on kde-optimize awhile ago. I think Mandriva uses it, but it hasn't made it into KDE yet.
How much does this KIconServer speed KIconDialog loading?
And as a complementary solution, we could always have an instance of KIconDialog created in some KDE deamon thread.
Then, when an application want to display that dialog, the API/class send a DBUS message to the deamon that immediatly display the dialog with every icons already loaded.
The dialog would then be instantly displayed, and users would be ultra-happy :-)
I think KIconServer would speed things up a lot, but I don't know by how much. However, I don't think keeping an instance of KIconLoader in memory is a good idea. For this to be effective it would have to keep ALL the KDE icons in memory. Do the multiplications, and you will find that this will quickly take up several megabytes. It doesn't seem worthwhile when we have a better solution, KIconServer, that actually would cause less memory usage by allowing icons to be shared between applications.
This is very intuitive and elegant scheme. I have one suggestion though.
Please put the Browse button on the right, because that is how it is in all the other applications.
Hoping to see the code soon.
Ratings & Comments
58 Comments
Definetly easier to use than the KDE default. I think they are using this in Basket, if I remember well...
What do you guys think about a zoom in/out tool? (Like in Konqueror). Useful or a waste of space? Back to the mockup: I think the "Browse..." button and the filter bar should be at the top, and the browse button should be to the right of the bar. Also, I kind of miss the "Clear" button, even if I never use it.
The actual icon dialog load takes long time loading all the icons each time. It doesn't use cache for showing them quickly. Have you considered improving the speed by using icons cache? Good job!
Yes, I have considered this. The problem is that when you start caching icons you can use up megs of memory really fast. This is especially bad because the icon dialog is inactive most of the time, so it doesn't make sense to keep it loaded in memory. And of course there are going to be multiple instances that cannot share the same icons in memory. The real solution, I believe, is KIconServer, which provides a system-wide shared cache for the KDE icons.
hi, this is the first descent Idea I have seen for a while, I've always had problems with my own Icon Changer, it should be put into KDE as soon as possible.
yeah, i think it's good enough...
What is thre button "browse.." for? From a usability perspective it looks strange
It opens up a file dialog that lets the user choose a custom icon. Do you have a suggestion for a better name?
it just looks like it browses for a new category, since it is below the category names..
i think it would be far better if the browse button would be on the right-top corner of the dialog, with the filter edit field left beside the browse button, and let the category list span over the whole vertically space just my 2 cents for this...
bad that you cannot edit your posts... better if you put the filter edit field and the browse button at bottom, below the icon list, but the browse button right beside the filter field and let the category list span over the whole vertically. i think that would finally solve the "browse issue", since in all other dialogs like the "open file" dialog, the browse button is at right-bottom too :D
huh, i must have been trunken that i said that the open-file dialog had a browse button in it :) . but i think you know what i mean...
Ok finally got it to compile so here we go with what I had to change. First: kiconcanvas.cpp:121: error: 'min' is not a member of 'std' #include instead of #include Which meant I had to add -I/usr/include/c++/4.0.3/ Is this something odd with gcc4 vs gcc3 or what's the deal here? perhaps its something to do with visibility as I have that enable? -fvisibility-inlines-hidden Tho I've not had a problem like this yet. Next Linking errors: cannot find -lkdecore and -lqt-mt Add these to the LIBS var. -L/usr/kde/3.5/lib/ -L/usr/qt/3/lib/ And there you have it .. now to see if this thing works! :D
Ok reading the preview to make sure its what I want is a good thing.... #include bits/stl_algobase.h> instead of #include cmath>
although not tested, i would say #include :D
although not tested, i would say #include <algorithm> :D
yeah, like i said this is non-autotooled, so you have to know how to hack a make file.
yes but I figured I'd report it to find out why I had to edit the source to fix that compile error. plus it seemed rather odd that the library search path wasn't included in yours?
It's simple. Every distribution is different as far as where it stores its files. For me, KDE libs are stored under /usr/lib, for you they are stored under /usr/kde/3.5/lib. Since /usr/lib is already the default library path, i didn't think to include it. As for the <cmath> thing, I don't know what the problem is. I do know that you should _never_ have to include <bits/stl_algobase.h>; that is an internal header to gcc that is not meant to be used directly. Try doing a find /usr -name 'cmath' and see what that turns up; then, add it to your include path.
Whenever I open up the application, I have to wait some time for the the fault category to load. This gets very annoying after a while. I suggest that when it is opened, instead of loading a category, a small piece of text is shown, inviting the user to choose which category to look at.
This won't do, because some applications request to open a particular category. However, this could be sped up somewhat by KIconServer, which was discussed on kde-optimize awhile ago. I think Mandriva uses it, but it hasn't made it into KDE yet.
How much does this KIconServer speed KIconDialog loading? And as a complementary solution, we could always have an instance of KIconDialog created in some KDE deamon thread. Then, when an application want to display that dialog, the API/class send a DBUS message to the deamon that immediatly display the dialog with every icons already loaded. The dialog would then be instantly displayed, and users would be ultra-happy :-)
I think KIconServer would speed things up a lot, but I don't know by how much. However, I don't think keeping an instance of KIconLoader in memory is a good idea. For this to be effective it would have to keep ALL the KDE icons in memory. Do the multiplications, and you will find that this will quickly take up several megabytes. It doesn't seem worthwhile when we have a better solution, KIconServer, that actually would cause less memory usage by allowing icons to be shared between applications.
This is very intuitive and elegant scheme. I have one suggestion though. Please put the Browse button on the right, because that is how it is in all the other applications. Hoping to see the code soon.
Foget what I said. The browse button should be on left because 'filter' text box should be beneath the icons' list.