From kde-core-devel Sun Jun 22 18:43:14 2003 From: Anders Lund Date: Sun, 22 Jun 2003 18:43:14 +0000 To: kde-core-devel Subject: Re: Use of KMessageBox::warningYesNo for continue/cancel X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105632024123903 X-BeenThere: kde-core-devel@mail.kde.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kde-core-devel@kde.org List-Id: KDE Core Development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: kde-core-devel-bounces-+kde-core-devel=progressive-comp.com@mail.kde.org Errors-To: kde-core-devel-bounces-+kde-core-devel=progressive-comp.com@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 ;) -anders