KIconDialog++

Various KDE 1.-4. Improvements

Source (link to git-repo or to original if based on someone elses unmodified work): Add the source-code for this project on opencode.net

0
5.0
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:

14 years ago

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"

sirlancelot

14 years ago

Is this just a screenshot you made or is it a running app?

If it's the second one, is there anyway it can be made available to us for download?

Report

C

Linuster

14 years ago

No, I actually have the code, but I want to work on it a little more before I release anything.

Report

Ekardnam

14 years ago

Screenshot.

Report

mkosmul

14 years ago

Another thing I would like to see would be for current icon to be selected when the dialog is opened. Currently even if there is already some icon selected e.g. in the application properties dialog box, once you open the icon selector there is no indication of which icon is selected. This makes it hard to revert to the previous icon if you clicked OK but later changed your mind - when you opened the dialog first time you didn't even get any chance to find out the icon's name or location.

Report

Sebien

14 years ago

I support this statement.

I think this is a bug (a bug by omission :-) ) and it should be solved by selecting the current icon when openning the dialog.

I don't know if KIconDialog allow to pass an icon as parameter, so it will perhapse have to wait for KDE4 to make every applications compatible.

But KIconButton (mostly used instead of KIconDialog directly) can internaly pass the current icon name without the app developers having to change any code.

Report

BorgQueen

14 years ago

I use icon ID for directories to help kids quickly find the directory of choice. So, obviously I'm always using kiconDialog. This would make easy work of it.

Hopefully KDE will see fit to incorporate this into the next release of KDE.

Splendid work.

Report

Sebien

14 years ago

Very good.

Concerning the kde-look comment concerning the "Browse..." button position, I've got this idea:

http://slaout.linux62.org/kde-wishs/KIconDialog2.png

That new layout with a listbox instead of a combobox have three advantages:

- The "Browse..." button can be placed right below, and will not be at the
standard "Help..." button anymore.

- Every categories are shown at once, so the user can choose visually and
figure out quickly there exist an "(All Categories)" pseudo-categories.

- It's one click less to choose a category, keeping user concentred in the
task of choosing an icon.

Report

timthelion

14 years ago

why have a brouse button instead of a category called brouse for more icons?

Report

C

Linuster

14 years ago

Because it pops up a file dialog whose interface is fundamentally different from the icon dialog.

Report

C

Linuster

14 years ago

I will be using this design, methinks. Be on the lookout for 0.2.

Report

KMJ

14 years ago

Great improvement over the current dialog.

But I think the Browse button still are a little hidden. Having it on the same line as the filter kind of fades it. And the different size between it and the Clear button are kind of visually unappealing.

Perhaps moving it down below the Filter(but still to the left).

Or plainly move the filter above the icon box.(Besides is that not more in line with how filters are done other places in kde?)

Report

C

Linuster

14 years ago

Actually, we did have the search bar above the icon view, but people suggested it be moved down to make things look more balanced. As for the smaller clear button, that is a layout problem that I have already fixed... but at Seigo's suggestion on kde-usability I am considering doing away with the clear button altogether.

Report

SegFault

14 years ago

I really really like your suggestion.
It solves the problem with the Browse-button
it looks as nice as the first mockup the discussion is about
it adds, as you said, the advantage of being able to see all categories at once

Thumbs up! I support your solution!

Report

maitre

14 years ago

Change search to filter, unless you are actually performing a search on all categories. In which case, do a filter instead. :)

And move the "Icon category" label next to the combox box, not far away from it

Report

fungs

14 years ago

Yes, I did not like this dialog either. Good to hear somebody started some changes...

Another suggestion: klicking a category will result in loading of the picture files. On older computers this takes some time sometimes (depending on the amount of icons). It would be nice to cache the pictures so they don't need to be reloaded when I switch categories. The cache can be deletet when the dialog is closed.

Report

DanaKil

14 years ago

does a middle click on the "clear" button paste the content of the clipboard (like in konqueror) ?

Report

C

Linuster

14 years ago

Not yet, though it wouldn't be hard to implement. I wish there were a standard searchbar widget (TODO).

Report

SegFault

14 years ago

I'd like to add to my previous comment, that another reason why not to put the "Browse"-button in the lower left corner is that this place is usually used for the "Help"-button in KDE dialogs.
Using a place that is already used by a standard button for custom functionality isn't a good idea.

Report

C

Linuster

14 years ago

Actually it is EXACTLY where the help button goes.... because I actually just changed KDialog's built-in help button. I don't ever forsee there being help in KIconDialog, but I don't know if consistency or compactness is more important.

Report

SegFault

14 years ago

I guess consistency is more important.
That's what styleguides are for.
In fact I think inconsistency is the biggest problem in UIs nowadays.
If you have an UI that is rather complicated and silly designed, but is consistent in every dialog it will be easier to use than a clean and mean interface where every dialog looks different to each other.

Report

Ekardnam

14 years ago

Oh, soo that's why I thought it looked wierd to have to browse button there. :)
But I agree what you should be able to browse directly, without selecting "Other Icons". Also, browsing all icons should be possible (as you've written).

Report

SegFault

14 years ago

Hi!
I really like your proposal, but I think the "Browse"-button should be more exposed, it's kinda hard to find it within your proposal.

I think the user shouldn't know about wether the icons are from kde or from any other source as it doesn't make any difference in selecting them and most users wouldn't even know what you'd mean with something like "non-kde icons".
"uncategorized" is quite good, although there may be some better term as the word "uncategorized" leaves a bitter taste for me...
Maybe something simple as "other"?

Just my 0.02 EUR

Report

Headrush

14 years ago

I understand your argument about the user not needing to know where the icons came from, but unfortunately in Linux where we have so many competing DEs and API, this can cause issues and could reflect poorly.

Maybe I'm nit-picking, but assume KDE finally uses all SVG format icons and some app or DE uses xpm icons which would appear to be included with KDE if grouped together. A user selects this icon but when it doesn't size correctly or isn't anti-aliased, the assumption is it is a KDE issue.

I know Linux is about choice, but I like to keep my DE clean and have as little pollution by different DEs and apps as possible.

Report

SegFault

14 years ago

AFAIK you can mix SVG icons and pixmap icons in a single category.
Most KDE icons themes use pixmap icons, so they won't scale, too.
I don't think it is a good idea to distinguish icons by where they come from.
And my previous argument is still valid: most users won't even know that they come from KDE as they don't even know what KDE is.
So what advantage is there in splitting icons in "KDE" and "non-KDE" ones when there are many who don't even know and many won't bother? (No offence, I'd like to understand your view)

Report

logixoul

14 years ago

I consider uncategorized the best choice. Other means that the icon absolutely does not belong to any of the other categories, which is not necessarily the case.
About the browse button, I love it where it is.

Report

14 years ago

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"

12345678910
Be the first to comment
File (click to download) Version Description PackagetypeArchitecture Downloads Date Filesize DL OCS-Install MD5SUM
*Needs pling-store or ocs-url to install things
Pling
0 Affiliates
Details
license
version
0.3
updated May 29 2006
added Feb 21 2006
downloads 24h
0
mediaviews 24h 0
pageviews 24h 2