-
 KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
--
-
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
--
-
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Arch-Stuff.org Art And Stuff for Arch Linux 
 Frugalware-Art.org Themes for Frugalware 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
--
-
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
--
-
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
--
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    LinuxDaily.com    Linux42.org    OpenSkillz.com   
 
Artwork
News
Groups
Knowledge
Events
Forum
People
Jobs
Register
Login



Sponsoring


-
- Content .- Fans  . 

KIconDialog++

   0.3  

KDE Improvement

Score 80%
KIconDialog++
zoom


Link:  http://
Minimum required   KDE 3.5.x
Downloads:  1572
Submitted:  Feb 21 2006
Updated:  May 30 2006

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.




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"




LicenseLGPL
Source(kicondialog-0.3.tar.gz)
Send to a friend
Subscribe
Other  Artwork  from Linuster
Report inappropriate content



goto page: prev   1  2  3 

-

 Layout Suggestion

 
 by Sebien on: Feb 22 2006
 
Score 50%

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.


Author of BasKet Note Pads (take notes and keep a full range of data on hand).
http://basket.kde.org/

Reply to this

-
.

 Re: Layout Suggestio

 
 by SegFault on: Feb 22 2006
 
Score 50%

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!


Reply to this

-

 Re: Layout Suggestion

 
 by Linuster on: Feb 22 2006
 
Score 50%

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


Reply to this

-

 Re: Re: Layout Suggestion

 
 by KMJ on: Mar 1 2006
 
Score 50%

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?)


Reply to this

-

 Re: Re: Re: Layout Suggestion

 
 by Linuster on: Mar 3 2006
 
Score 50%

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.


Reply to this

-

 Re: Layout Suggestion

 
 by timthelion on: May 30 2006
 
Score 50%

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


Reply to this

-

 Re: Re: Layout Suggestion

 
 by Linuster on: May 30 2006
 
Score 50%

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


Reply to this

-
.

 Outstanding Idea

 
 by BorgQueen on: Feb 23 2006
 
Score 50%

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.


Reply to this

-
.

 Nice

 
 by mkosmul on: Feb 23 2006
 
Score 50%

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.


Michal
Reply to this

-
.

 Re: Nice

 
 by Sebien on: Mar 1 2006
 
Score 50%

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.


Author of BasKet Note Pads (take notes and keep a full range of data on hand).
http://basket.kde.org/

Reply to this

-

 available to public

 
 by sirlancelot on: Mar 1 2006
 
Score 50%

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?


Reply to this

-

 Re: available to pub

 
 by Ekardnam on: Mar 1 2006
 
Score 50%

Screenshot.


Reply to this

-

 Re: available to public

 
 by Linuster on: Mar 1 2006
 
Score 50%

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


Reply to this

-
.

 Wonderful

 
 by anupamsr on: Mar 3 2006
 
Score 50%

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.


Reply to this

-

 Re: Wonderful

 
 by anupamsr on: Mar 3 2006
 
Score 50%

Foget what I said. The browse button should be on left because 'filter' text box should be beneath the icons' list.


Reply to this

-

 "select category"?

 
 by DarkCow on: Mar 5 2006
 
Score 50%

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.


Reply to this

-

 Re: "select category"?

 
 by Linuster on: Mar 6 2006
 
Score 50%

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.


Reply to this

-
.

 Re: Re: "select category"?

 
 by Sebien on: Mar 13 2006
 
Score 50%

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 :-)


Author of BasKet Note Pads (take notes and keep a full range of data on hand).
http://basket.kde.org/

Reply to this

-

 Re: Re: Re: "select category"?

 
 by Linuster on: Mar 26 2006
 
Score 50%

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.


Reply to this

goto page: prev   1  2  3 

Add commentBack






-

-
Do you like or dislike Ubuntu Unity?
 Yes, unity is alien technology!
 It is less confusing than Gnome 3 default, shell.
 Granny thinks it is much more usable than Gnome 2
 Canonical is embarrasing itself with this split project
 Gnome 3 default shell is much better
 I dislike Unity, Gnome 3 default shell is alien technology!
 None of the above, I like the 2Gb for free and Apple alike behavior. Will post a comment instead

resultmore




 
 
 Who we are
Contact
More about us
Frequently Asked Questions
Register
Twitter
Blog
Explore
Artwork
Jobs
Knowledge
Events
People
Updates on identi.ca
Updates on Twitter
Facebook App
Content RSS   
News RSS   
Discussion RSS   
Events RSS   

Participate
Groups
Forum
Add Artwork
Public API
About KDE-Look.org
Legal Notice
Spreadshirt Shop
CafePress Shop
Advertising
Sponsor us
Report Abuse
 

Copyright 2001-2014 KDE-Look.org Team  
All rights reserved. KDE-Look.org is not liable for any content or goods on this site.
All contributors are responsible for the lawfulness of their uploads.
KDE and K Desktop Environment are trademarks of KDE e.V.