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

List:       kde-core-devel
Subject:    Re: Use of KMessageBox::warningYesNo for continue/cancel
From:       Anders Lund <anders.lund () lund ! tdcadsl ! dk>
Date:       2003-06-22 18:43:14
[Download RAW message or body]


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 <kde-core-devel.mail.kde.org>
List-Unsubscribe: <http://mail.kde.org/mailman/listinfo/kde-core-devel>,
	<mailto:kde-core-devel-request@mail.kde.org?subject=unsubscribe>
List-Post: <mailto:kde-core-devel@mail.kde.org>
List-Help: <mailto:kde-core-devel-request@mail.kde.org?subject=help>
List-Subscribe: <http://mail.kde.org/mailman/listinfo/kde-core-devel>,
	<mailto:kde-core-devel-request@mail.kde.org?subject=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 
[prev in list] [next in list] [prev in thread] [next in thread]