Add step parameter to DoubleInput QInputDialog

[David Faure]

On Friday 10 May 2013 23:00:31 David Gil Oliva wrote:
> 2013/5/10 David Faure <faure at kde.org>
> 
> > On Wednesday 08 May 2013 17:26:17 David Gil Oliva wrote:
> > > Therefore, I think that it would be best to add a static method called
> > > getItemFromListView. What do you think?
> > 
> > Option 1: adding getItemFromListView (the name looks a bit odd)
> > Option 2: adding a getItem overload that takes an InputDialogOptions
> > parameter, so that this will be ready for more options if any, in the
> > future.
> 
> There's something odd about the second one. I could write a getItem
> overload with a InputDialogOptions parameter, but the value of that
> parameter could be:
> 
>     enum InputDialogOption {
>         NoButtons                    = 0x00000001,
>         UseListViewForComboBoxItems  = 0x00000002,
>         UsePlainTextEditForTextInput = 0x00000003
>     };

4, not 3. So that it doesn't imply NoButtons.

> The third one is for the new getMultiLineText method.
> 
> Actually, only the second one has something to do with the other
> static-getItem-with-listView method. Therefore it turns out the aim is not
> to have a listView in getItem, but to be able to use any existing option,
> even when they don't make any sense for the getItem method. I find it weird
> and counter-intuitive.

That's just a matter of documentation. It can always be documented that such 
and such option only applies to such and such method.

It's already the case right now, where you could do 
setOptions(UseListViewForComboBoxItems) for any kind of input dialog, even 
text or int. But it will be ignored, rightfully.

I think this is a common way of preventing API explosion: a single set of 
options, but documenting what makes sense.

(Thiago did something pretty similar in QUrl).

> > Option 3: porting coded to the multi-line call (constructor,
> > setComboBoxItems,
> > setOptions).
> 
> Sorry that I insist

Ooops my bad, forgot to answer that. I meant: not adding a static method in 
qinputdialog, but instead porting the KDE code to say

QInputDialog dlg(parent);
dlg.setComboBoxItems(...);
dlg.setOptions(...);
if (dlg.exec()) ....

A bit more code, but it doesn't lead to more static methods with a huge number 
of parameters, which makes it hard to add more (like we'd like to add 
"Options" to the getItem one).

It's quite usual in Qt that the "most common" cases are covered by static 
methods, and the more advanced use cases are covered by "constructor + 
setters". QFileDialog, QColorDialog etc. all do this.

Overall I'm a bit unsure about what we should do; I'm presenting our options, 
but you'll have to look further into which ones seem to make more sense :)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5