Use of KMessageBox::warningYesNo for continue/cancel questions.
anders.lund at lund.tdcadsl.dk
Sun Jun 22 19:43:14 BST 2003
X-BeenThere: kde-core-devel at mail.kde.org
Reply-To: kde-core-devel at kde.org
List-Id: KDE Core Development <kde-core-devel.mail.kde.org>
<mailto:kde-core-devel-request at mail.kde.org?subject=unsubscribe>
List-Post: <mailto:kde-core-devel at mail.kde.org>
List-Help: <mailto:kde-core-devel-request at mail.kde.org?subject=help>
<mailto:kde-core-devel-request at mail.kde.org?subject=subscribe>
Sender: kde-core-devel-bounces-+kde-kde-core-devel=m.gmane.org at mail.kde.org
Errors-To: kde-core-devel-bounces-+kde-kde-core-devel=m.gmane.org at mail.kde.org
On Sunday 22 June 2003 18:05, Ingo Klöcker wrote:
> > hrm... as per our recent IRC chat, how about the attached patch? this
> > would allow the application to tell KMessageBox if the action is
> > "dangerous" and should therefore be protected by safer defaults,
> > allow applications to use the "proper" KMessageBox variants, and not
> > alter the current default behaviour nor add any new methods to
> > KMessageBox...
> Isn't that a little bit to special? Wouldn't it be better to add a
> defaultButton parameter? Or do you fear that this would lead to
> inconsistent usage of those dialogs because every developer would
> choose the default according to his own gusto instead of only changing
> the predefined default only if it's really appropriate (i. e. in case
> of destructive actions)?
We actually has a "question" style message box that may - should, imo - be
used for events where you wan't the user to decide on a not critical issue.
The decision weather to send mail now is a good example.
I think that is a issue is serious enough for the developer to issue a
warning, the user should not be given the option not to see it.
> On a related issue: Does anyone object against adding three-button
> message boxes to KMessageBox? We need those in KMail. Currently we are
> using QMessageBox which allows three buttons with arbitrary text and
> arbitrary default button. The arbitrary default button is probably not
> that important. IMO always the first button should be the default
> button. But the arbitrary button text is important and therefore the
> YesNoCancel message boxes can't be used. Furthermore the QMessageBoxes
> return (by default) -1 in case the user aborted the message box with
> Esc or by closing the window instead of selecting one of the buttons.
Three-button questions often makes sense. You can set the strings for the
buttons in the constructor:
* @param buttonYes The text for the first button.
* The default is i18n("&Yes").
* @param buttonNo The text for the second button.
* The default is i18n("&No").
That is just my 2c of cause ;)
More information about the kde-core-devel