[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    KIconDialog 0.2
From:       Luke Sandell <kdelists () luketopia ! net>
Date:       2006-02-28 22:10:33
Message-ID: 200602282210.33374.kdelists () luketopia ! net
[Download RAW message or body]

I have continued to work on KIconDialog. I have redone the interface in 
designer, which also required splitting off KIconCanvas into a separate file. 
I'm not sure why KDE places multiple exported classes in a single file in the 
first place. The latest screenshot screenshot is posted at 
http://www.kde-look.org/content/show.php?content=35528 

I have found that designing an application's functionality is far more 
difficult than implementing it, so I would appreciate your comments on the 
following matters.

My original plan was to add three meta-categories to the dialog box, All 
Icons, Recent, and Custom. All Icons is self explanatory, Recent  is all 
those that have recently been selected, and Custom includes the whole history 
of icons chosen using the Browse button. 

I have decided against including the Custom category, for a variety of 
reasons. The main reason is that the Recent category already serves as a 
decent cache for custom icons, and I don't want to include unnecessary 
complication. I am also considering including storing custom icons 
permanently in the Unspecified category (or whatever I end up calling it) 
category, though I don't know how useful this would really be.

*** This following part is more for development people ***

Another set of issues I have deal with the fact that the current KIconDialog 
API is CRAZY. First you have the basic modes, which allow you to set the icon 
context (category) and size. This isn't too hard to understand. Then you have 
the strictIconSize boolean, which supposedly makes all icons conform to the 
given size, except for the non-KDE icons which do not have an associated 
size. Then there is the user boolean which was used to select the lower radio 
button (Unspecified icons). And the customLocation which REPLACES the 
unspecified icons with icons from a custom location. Finally, we have the 
lockCustom and lockUser booleans which disabled the browse button and 
category combos, respectively. 

My question is are all these options still necessary, and how will they be 
implemented in the new GUI? For instance, now that User (Unspecified) is just 
another category (and one that should never be set by default), does it 
really make sense to have a separate boolean option for it? If lockUser is 
set, should we just gray out the listbox? Or why would we want to lock the 
GUI down in the first place... why keep our users from doing what they want 
to do? Some of it is just illogical ... such as why on earth would one want 
to set lockUser but not lockCustom (letting them browse but not switch from 
the Unspecified category???). The only real feature that I think might be 
worth keeping is the custom location mode, which might be needed by some 
applications (though it seems to me, if you want to restrict the choice of 
icons for an application, you use a more specialized widget). Thus I think 
this API can greatly be streamlined, but I am not the expert here.

And this is not even getting into the Appicon path that can be set in the 
KIconLoader. I'm not even sure how that works.

-Luke Sandell
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]