From kde-core-devel  Fri Nov 10 22:11:08 2006
From: Olivier Goffart <ogoffart () kde ! org>
Date: Fri, 10 Nov 2006 22:11:08 +0000
To: kde-core-devel
Subject: Re: RFC: semantic of KDialog::exec() result etc.
Message-Id: <200611102311.14755.ogoffart () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=116319677704631
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1688366.1RjMusoxty"

--nextPart1688366.1RjMusoxty
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le jeudi 9 novembre 2006 20:43, Friedrich W. H. Kossebau a =E9crit=A0:
> Hi,
>
> "KDialog" is a "QDialog". So the semantics of "QDialog" should be valid
> also with "KDialog", right? Reading
> http://doc.trolltech.com/4.2/qdialog.html
> "QDialog::exec()" is said to return a "QDialog::DialogCode" result.
>
> But "KDialog" does not, instead it currently even mixes
> "QDialog::DialogCode" with "KDialog::ButtonCode"=20

Not really.
It does almost always return a QDialog::DialogCode.

But you are right, there is one exception,  it may return KDialog::Yes or=20
KDialog::No code. (this is for compatibility with old KMessageBox)


> [...] I would propose to build on the "QDialog::DialogCode" and
> add a "KDialog::ResultCode" enum like this:
>
> 	enum ResultCode {
> 	  // for cancelling
> 	  Rejected =3D 0;
> 	  Cancelled =3D 0;
> 	  // for okay//finish//close/e.g. yes
> 	  Accepted =3D 1;
> 	  Finished =3D 1;
> 	  Closed =3D 1;
> 	  Selected1 =3D 1;
> 	  // e.g. no
> 	  Selected2 =3D 2;
> 	  // there are usages for three
> 	  Selected3 =3D 3;
> 	  // there were five closing buttons before,
> 	  // so stay with it if someone uses all
> 	  Selected4 =3D 4;
> 	  Selected5 =3D 5;
> 	};
>
> Makes sense?=20

It make sens to me, this is more explicit than the current behavior which m=
ay=20
be confusing.
Anyway, I'm not sure is is good to add so many equal terms in the enum.

> [1] The code currently closes the dialog only
> on "Cancel", "Ok", "Close", "Yes", and "No". So practically all questions
> with more than two fixed options (remember that cancelling is rejecting t=
he
> question/process) are to add parameter field(s) to the dialog. I guess th=
is
> is due to good usability? Should be documented then. ...found, there are
> three options with e.g. accepting storing passwords for websites
> (html_formimpl.cpp). Is there a senseful upper limit to the number? I
> choose here 5.

In fact, this is again only usefull for KMessageBox,  and there is no=20
KMessageBox with more than 3 options.

maybe this could be implemented in KMessageBox and not in KDialog anyway.

> [2] Shouldn't "Close" and "Okay" be mutually exclusive? Currently the code
> allows both to be added to a KDialog box. Same for "Cancel" and "Close".

Yes, they are in practice mutually exclusive.


> Or is there any plan to go with QMessageBox anyway?

I don't know if we should use QMessageBox,  but the KMessageBox class proba=
bly=20
require rewrite.  I would inherit from KDialog.
Anyway, this is a *huge* work=20
(this is a big class with lots of method + it is used everywhere)

The only problem with QMessageBox is that it is not a KDialog. (so we loose=
=20
some feature like the "details" button, and it doesn't use KPushButton and=
=20
KGuiItem)
Also, since the layout need to be redone anyway since we need to add=20
the "don't ask again" checkbox, I think we should not use QMessageBox



--nextPart1688366.1RjMusoxty
Content-Type: application/pgp-signature

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

iD8DBQBFVPkCz58lY8jWrL0RAqXzAJ0ehTA6tIBTm1bAdsUek5AiVFv6AwCeKoZ+
DZ8CaN3+UVSI1dbBNeRS+b4=
=zlZc
-----END PGP SIGNATURE-----

--nextPart1688366.1RjMusoxty--