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

List:       kde-core-devel
Subject:    Re: KMessageBox::questionYesNo change
From:       Stephan Kulow <coolo () kde ! org>
Date:       1999-11-28 11:45:53
[Download RAW message or body]

Antonio Larrosa wrote:
> 
> Hi,
> 
> I've just added a new method to KMessageBox, which is a questionYesNo
> method with an extra QStringList parameter that is used to display
> a QListBox in the question dialog with the contents of the list.
> 
> The idea is that David, Simon, or someone change Konqueror to show the
> user which files it's going to delete in case you click on "Yes" (instead
> of just saying "the selected files", which is too vague, especially for
> people with bad memory :-) )
> 
> This is just a simple addition, and cannot break any code, as noone called
> this function using a QStringList before. My first idea was to turn it
> into an optional parameter to questionYesNo, changing :
>  static int questionYesNo(QWidget *parent,
>                           const QString &text,
>                           const QString &caption = QString::null,
>                           const QString &buttonYes = QString::null,
>                           const QString &buttonNo = QString::null);
> to :
>  static int questionYesNo(QWidget *parent,
>                           const QString &text,
>                           const QStringList &strlist = QStringList(),
>                           const QString &caption = QString::null,
>                           const QString &buttonYes = QString::null,
>                           const QString &buttonNo = QString::null);
> 
> as if the QStringList is empty, it works exactly as the original
> questionYesNo method, but that would break some code, so it may be a
> thing for after KRASH.
> 
> OTOH, every call to the simple version (99% of them) would create
> a QStringList object which wouldn't be used for anything (except to
> check that it's empty). Anyway, what's a short-living runtime
> QStringList compared to two functions which do the same on the libs ?
> 
> Opinions ?
> 
The default constructor for QStringList does even less than the
assiging operator of QString for passing QString::null. So I don't
think there is a big point in avoid this using two functions. On the
other hand the order of the paramaters sucks in this case as the
QStringList is only used in about 3% of all cases, the yes and no
button texts may be used in more cases. So the QStringList paramter
should be after them.

Greetings, Stephan

-- 
When your memory goes, forget it!

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