--===============1216533215==
Content-Type: multipart/signed;
  boundary="nextPart1819734.Xa4J79eK0x";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1819734.Xa4J79eK0x
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi!

A wishlist item for KDE4 API:
KMessageBox::*Cancel* should allow the user to override the text of=20
the "cancel" button, not just the "yes" and "no" buttons. I think this is=20
particualrily important, as the "Cancel"-option is often the least well=20
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=20
far, but I think it would be much more useful to be able to set it to "Save=
 /=20
Discard / Cancel (don't quit)" or something like that. It's nearly always=20
easy to word the dialog so the "Yes" and "No" options are self explanatory,=
=20
but mostly very hard to explain the "Cancel" option in simple words.

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

static int   questionYesNoCancel (QWidget *parent, const QString &text, con=
st=20
QString &caption=3DQString::null, const KGuiItem &buttonYes=3DKStdGuiItem::=
yes(),=20
const KGuiItem &buttonNo=3DKStdGuiItem::no(), const QString=20
&dontAskAgainName=3DQString::null, int options=3DNotify)

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

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

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

Any better ideas / what do you think?

Regards
Thomas

--nextPart1819734.Xa4J79eK0x
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFBBrnEKRv+5DVNhgRAhggAKCymUYOOG8t6IY5PlyeSiNY0VWqMwCbBz9x
9dMJg8TjlOhf2DAE/K9KWnA=
=n+qu
-----END PGP SIGNATURE-----

--nextPart1819734.Xa4J79eK0x--

--===============1216533215==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1216533215==--