KMimeTypeChooser

Simon Hausmann hausmann at kde.org
Sun Apr 11 07:58:03 BST 2004


On Sunday 11 April 2004 01:29, Anders Lund wrote:
> Ok, here is a new version of the files.
>
> I have followed the suggestions from Simon, so the data retrievers are not
> const, and added the const char *name standard argument. I also used aenum
> for the visuals, for readability.

Sorry for the misunderstanding, I meant only the methods being const, not 
their return value. (makes little sense IMHO)

> I kept the parent as the first argument, because there is a bunch of
> parameters with default values following.

This could be solved using overloaded constructors. IMHO consistency is king 
here, but that might be just me :}

> I have also, with help from David on irc, made the widget update if a mime
> type is changed while using the dialog. I connect to the KSycoca signal
> only when the mimetype editor is launched, that should be sufficient (?),
> and also on his suggestion added a few parameters:
> * you can now provide a list of groups to show.
> * you can provide a default group to open.
>
> I also renamed KMimeTypeChooserDlg -> KMimeTypeChooserDialog, which I
> believe is more compliant with the rest of KDE.

Good point :)

Another idea: Why not provide an accessor to the KMimeTypeChooser from the 
dialog instead of the two dummy forwarding methods? In case you want to keep 
them IMHO they should at least share the same name in the Dialog as well as 
the raw widget though (currently selectedMimeTypesStringList() vs. 
mimeTypes()).

Also I would name selectedMimeTypesStringList just selectedMimeTypes. It's 
uncommon to decode the return type into the method name. Just an idea.

Oh, and a private d pointer is missing.

> Btw, kio could be considered a more logical loaction for these classes than
> kdeui?

Yes, given that the code actually uses KMimeType and KRun it would have to be 
in kio in order to link.

Simon




More information about the kde-core-devel mailing list