RFC: semantic of KDialog::exec() result etc.

[Olivier Goffart]

Le jeudi 9 novembre 2006 20:43, Friedrich W. H. Kossebau a écrit :
> 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" 

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

But you are right, there is one exception,  it may return KDialog::Yes or 
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 = 0;
> 	  Cancelled = 0;
> 	  // for okay//finish//close/e.g. yes
> 	  Accepted = 1;
> 	  Finished = 1;
> 	  Closed = 1;
> 	  Selected1 = 1;
> 	  // e.g. no
> 	  Selected2 = 2;
> 	  // there are usages for three
> 	  Selected3 = 3;
> 	  // there were five closing buttons before,
> 	  // so stay with it if someone uses all
> 	  Selected4 = 4;
> 	  Selected5 = 5;
> 	};
>
> Makes sense? 

It make sens to me, this is more explicit than the current behavior which may 
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 the
> question/process) are to add parameter field(s) to the dialog. I guess this
> 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 
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 probably 
require rewrite.  I would inherit from KDialog.
Anyway, this is a *huge* work 
(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 
some feature like the "details" button, and it doesn't use KPushButton and 
KGuiItem)
Also, since the layout need to be redone anyway since we need to add 
the "don't ask again" checkbox, I think we should not use QMessageBox


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061110/7237f20c/attachment.sig>