Add step parameter to DoubleInput QInputDialog

[David Faure]

On Friday 10 May 2013 10:11:05 Kevin Krammer wrote:
> On Friday, 2013-05-10, David Faure wrote:
> > On Friday 10 May 2013 09:27:44 Kevin Krammer wrote:
> > > On Friday, 2013-05-10, David Faure wrote:
> > > > 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. Option 3: porting coded to the multi-line call (constructor,
> > > > setComboBoxItems, setOptions).
> > > > 
> > > > In my opinion option 2 is best if not too ugly (not sure where to add
> > > > the additional argument, depends how many default values there are
> > > > etc.), otherwise option 3 (depending on how many calls to getItem we
> > > > actually have...).
> > > 
> > > Wouldn't it have to be a new method, i.e. getItems (plural) with single
> > > selection being one of its modes?
> > > Also needed to replace KInputDialog::getItemList(), no?
> > 
> > I found no actual use case in the whole KDE code, for actual
> > multiselection. All calls to getItemList are followed by a .first() or
> > equivalent.
> 
> Ah, I see.
> I thought that if we were to introduce a new method, we could aim at a
> really new one, e.g. a "get items" that is not just single/multi, but
> actually takes a selection mode flag.

Ah, I see. :)
It makes the justification for a new method easier, indeed, from a technical 
point of view.
But if nobody needs that, then the justification for putting it into Qt isn't 
great.
Any idea for an actual use case for multiselection in such a "simple" input 
dialog? :)

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