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

List:       kde-devel
Subject:    KMessageBox custom Cancel button
From:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2006-09-10 14:02:12
Message-ID: 200609101602.16419.thomas.friedrichsmeier () ruhr-uni-bochum ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi!

A wishlist item for KDE4 API:
KMessageBox::*Cancel* should allow the user to override the text of 
the "cancel" button, not just the "yes" and "no" buttons. I think this is 
particualrily important, as the "Cancel"-option is often the least well 
explained. Typical example:

"Do you want to save your file before quitting?" -> "Yes / No / Cancel".
You can set this to "Save / Discard / Cancel" easily with the API provided so 
far, but I think it would be much more useful to be able to set it to "Save / 
Discard / Cancel (don't quit)" or something like that. It's nearly always 
easy to word the dialog so the "Yes" and "No" options are self explanatory, 
but mostly very hard to explain the "Cancel" option in simple words.

Adding this functionality - unfortunately - is not entirely trivial, as the 
API is always (example for yesNoCancel):

static int   questionYesNoCancel (QWidget *parent, const QString &text, const 
QString &caption=QString::null, const KGuiItem &buttonYes=KStdGuiItem::yes(), 
const KGuiItem &buttonNo=KStdGuiItem::no(), const QString 
&dontAskAgainName=QString::null, int options=Notify)

Simply adding a "const KGuiItem &buttonCancel=KStdGuiItem::cancel()" is 
problematic, as a QString passed at that position will automatically be 
converted to a KGuiItem. Hence, if previously an app defined a 
dontAskAgainName, compilation will run smoothly, but the dontAskAgainName 
will be shown as the text of the cancel button, and dontAskAgainName will be 
set to the default QString::null. In other words, in many cases this would 
give an unexpected result when porting to KDE4.

Still I think this functionality is important and should be added for KDE4. Do 
you agree so far?

Possible ways to do this:
1) Simply add the "const KGuiItem 
&buttonCancel=KStdGuiItem::cancel()"-parameter, regardless of the above 
mentioned problem
2a) Rename the new function to 
static int   questionYesNoCancelCustom (...)
or something like that to avoid the problem.
Downside: If I counted correctly, this would mean adding 10 new static 
functions
2b) change naming of all functions or "KMessageBox" itself so the old code 
will no longer compile but can be ported trivially.
Downsides: Current naming seems good to me. Adds porting work that is not 
really needed in many/most cases.
Upside: Probably it would not be a bad idea to merge KMessageBox::XY, 
KMessageBox::XYList, KMessageBox::XYWid, and KMessageBox::XYListWid into a 
single function (the strlist and parent_id parameters would be appended at 
the end and default to and empty list and 0, respectively). IMO this would 
reduce a lot of clutter. And since all these functions are about showing a 
dialog to the user, the added overhead would be absolutely neglegible.
3) Add a new generic function that takes a single QList of KGuiItems for the 
buttons instead of separate parameters. Return value would be the index 
position of the button pressed. The old functions would be deprecated but 
continue to work as before.
Downsides: Would probably make the function calls less readable. Would make it 
dangerously easy to create non-standard dialogs with the order of 
yes/no/cancel mixed up.

Any better ideas / what do you think?

Regards
Thomas

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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