<p>Hi!</p>
<p>El 02/05/2013 15:30, "David Faure" <<a href="mailto:faure@kde.org">faure@kde.org</a>> va escriure:<br>
><br>
> On Thursday 02 May 2013 13:07:34 David Faure wrote:<br>
> > > BTW, the definition of QInputDialog says that it "provides a simple<br>
> > > convenience dialog to get a single value from the user." The future new<br>
> > > method getItemList will be able to return more than one value (in a<br>
> > > QStringList, for example). It will force me to change the documentation<br>
> > > and<br>
> > > the definition. We will see, what the reviews say.<br>
><br>
> Hold on, Kévin and I just had a look at all the users of getItemList, to see<br>
> if it was really used.<br>
><br>
> It turns out that it *is* used (in knewstuff, kile, kmymoney and libkcddb),<br>
> but in all cases, the application then takes the first one out of the returned<br>
> list!</p>
<p>Ok, but I think it would be more logical to have the QListView to only allow one value. Otherwise the user could select more than one value, and have only one of them returned.</p>
<p>> Why don't they just use getItem then? The answer: because getItem shows a<br>
> closed combobox, while getItemList shows a much nicer flat list, which shows<br>
> multiple items to the user.<br>
><br>
> So the real solution is not to add getItemList to Qt, but rather to change<br>
> Qt's getItem to use a QListView rather than a QComboBox, in order to improve<br>
> usability.</p>
<p>Ok</p>
<p>> And meanwhile we can deprecate getItemList in favour of Qt's getItem.</p>
<p>Ok</p>
<p>David Gil<br>
<a href="http://www.hackingastrology.net">www.hackingastrology.net</a></p>
<p>> --<br>
> David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr">http://www.davidfaure.fr</a><br>
> Working on KDE, in particular KDE Frameworks 5<br>
><br>
</p>