[yast-devel] Enforcing okButton and cancelButton
https://bugzilla.novell.com/show_bug.cgi?id=422612
This shows that there are cases where it is legitimate to have a pop-up dialog
with a ButtonBox with more than one button, but only an okButton and no
cancelButton:
...message...
<Countdown>
[Stop] [OK]
We (mschmidkunz + tgoettlicher + sh) thought that this is the one exception
from that rule; in general, all dialogs with more than one button should have
an okButton (for the regular end) and a cancelButton (as a safe escape).
Now locilka found one more exception:
...error...
[OK] [Details...]
Now I can't help that sinking feeling that there might be even more.
If there is a significant number of cases where it makes sense to not enforce
that sanity check (must have only one button or both okButton and
cancelButton), we have to get rid of that check. But I still think that it's
useful.
Who has more examples where it might be legitimate to have more than one
button, yet not both an okButton and a cancelButton?
Opinions?
Suggestions?
CU
--
Stefan Hundhammer
On Thu, Sep 04, 2008 at 12:51:16PM +0200, Stefan Hundhammer wrote:
https://bugzilla.novell.com/show_bug.cgi?id=422612
This shows that there are cases where it is legitimate to have a pop-up dialog with a ButtonBox with more than one button, but only an okButton and no cancelButton:
...message... <Countdown>
[Stop] [OK]
...message... <Countdown> [Stop] [OK]
...error... [OK] [Details...]
...error... [Details...] [OK] A way to escape this would be to place the odd (er, even) button outside the ButtonBox. -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Martin Vidner wrote:
On Thu, Sep 04, 2008 at 12:51:16PM +0200, Stefan Hundhammer wrote:
https://bugzilla.novell.com/show_bug.cgi?id=422612 ... ...message... <Countdown>
[Stop] [OK]
...message... <Countdown> [Stop] [OK]
...error... [OK] [Details...]
...error... [Details...] [OK]
A way to escape this would be to place the odd (er, even) button outside the ButtonBox.
It would be quick but wrong solution. We wanted to have buttons placed and aligned according the current desktop type (Qt/GTK/ncurses). Check, for instance, KDE pop-up dialogs, they don't solve such things by putting `customButtons above. L.
Dňa Thursday 04 September 2008 13:12:36 Martin Vidner ste napísal:
On Thu, Sep 04, 2008 at 12:51:16PM +0200, Stefan Hundhammer wrote:
https://bugzilla.novell.com/show_bug.cgi?id=422612
This shows that there are cases where it is legitimate to have a pop-up dialog with a ButtonBox with more than one button, but only an okButton and no cancelButton:
...message... <Countdown>
[Stop] [OK]
...message... <Countdown> [Stop] [OK]
...error... [OK] [Details...]
...error... [Details...] [OK]
A way to escape this would be to place the odd (er, even) button outside the ButtonBox.
But you want the alignment functionality (in fact, the desktop independence in general) to retain. So, yes, it's a workaround. IMO the best would be to convert all such buttons to custom ones so the check will ignore this. Stano -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stanislav Visnovsky wrote:
IMO the best would be to convert all such buttons to custom ones so the check will ignore this.
I'm afraid it will not. A `ButtonBox with two `customButtons will fail the same way: UI syntax error, I've tried that. On the other hand, it would be nice, if the check ignored it in such case :) L.
Martin Vidner wrote:
On Thu, Sep 04, 2008 at 12:51:16PM +0200, Stefan Hundhammer wrote:
https://bugzilla.novell.com/show_bug.cgi?id=422612
This shows that there are cases where it is legitimate to have a pop-up dialog with a ButtonBox with more than one button, but only an okButton and no cancelButton:
...error... [OK] [Details...]
Where can I reproduce the case of having an error pop up with OK and details? The only error pop up with details I came across so far was the error pop up in LDAP browser (when no connection to LDAP server is possible). In this case the details are shown if the user clicks on a "Show Details" check box. Maybe this would also be appropriate in the case mentioned above? Cu, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ----------------------------------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stefan Hundhammer wrote: [...]
Now I can't help that sinking feeling that there might be even more. If there is a significant number of cases where it makes sense to not enforce that sanity check (must have only one button or both okButton and cancelButton), we have to get rid of that check. But I still think that it's useful.
My question is why is the failed check considered as a fatal error? Isn't it rather a minor problem? Would be an y2warning message enough instead of aborting the module? -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On čt 4. září 2008, Ladislav Slezak wrote:
Stefan Hundhammer wrote: [...]
Now I can't help that sinking feeling that there might be even more. If there is a significant number of cases where it makes sense to not enforce that sanity check (must have only one button or both okButton and cancelButton), we have to get rid of that check. But I still think that it's useful.
My question is why is the failed check considered as a fatal error? Isn't it rather a minor problem? Would be an y2warning message enough instead of aborting the module?
I agree. Seems strange that such developer's error that could be considered cosmetic has such consequences. j -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Donnerstag, 4. September 2008, Ladislav Slezak wrote:
My question is why is the failed check considered as a fatal error? Isn't it rather a minor problem? Would be an y2warning message enough instead of aborting the module?
It doesn't abort the module; it makes UI::OpenDialog() fail. You could easily
catch that in YCP code (but it's not done anywhere in production code):
http://svn.opensuse.org/svn/yast/trunk/ycp-ui-bindings/examples/ButtonBox2.y...
void showDialog( term buttonBox )
{
boolean success = (boolean)
UI::OpenDialog(
`VBox(
`HVCenter( `Label( "Hello, World!" ) ),
buttonBox
)
);
// Most YCP developers never use the return value of UI::OpenDialog().
// Many of them probably don't even know that it has a return value.
//
// Used properly, that return value can be used to recover from error
// situations that would otherwise abort the program - like in this
//case.
if ( success )
{
UI::UserInput();
UI::CloseDialog();
}
}
Past experience shows that y2warning() calls are generally ignored, so they
are pretty useless.
CU
--
Stefan Hundhammer
On Thu, Sep 04, 2008 at 01:27:48PM +0200, Stefan Hundhammer wrote:
Past experience shows that y2warning() calls are generally ignored, so they are pretty useless.
Then display an error pop-up. That is annoying enough to get the issue fixed and yet does not break the application (⇒ less work for you). -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On čt 4. září 2008, Stefan Hundhammer wrote:
Past experience shows that y2warning() calls are generally ignored, so they are pretty useless.
Because of this:
// Most YCP developers never use the return value of UI::OpenDialog(). // Many of them probably don't even know that it has a return value. //
is relying on the fact that developers will check return value of UI::OpenDialog() even worse. Use y2error instead of y2warning, that will certainly be annoying enough for the people looking into the logs. -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Donnerstag, 4. September 2008, Jiří Suchomel wrote:
Because of this:
// Most YCP developers never use the return value of UI::OpenDialog().
That is a fact, and it was meant as a statement of fact. But...
// Many of them probably don't even know that it has a return value.
...this is not due to a lack of documentation. To the contrary. It's always been there, and it's always been documented. http://forgeftp.novell.com///yast/doc/SL11.0/tdg/YCP_UI_OpenDialog_with_opti... http://forgeftp.novell.com///yast/doc/SL10.3/tdg/YUI_builtins_OpenDialog.htm... http://forgeftp.novell.com///yast/doc/SL10.2/tdg/YUI_builtins_OpenDialog.htm... http://forgeftp.novell.com///yast/doc/SL10.1/tdg/YUI_builtins_OpenDialog.htm... http://forgeftp.novell.com///yast/doc/SL10.0/tdg/YUI_builtins_OpenDialog.htm... (can't go further back there - we used to have a different server back then)
is relying on the fact that developers will check return value of UI::OpenDialog() even worse.
It's not relying on anything like that. But it's preventing the UI to continue
with invalid data.
From some problems you can recover; from some you cannot. In general, the UI
is _very_ forgiving when it comes to YCP UI code that does things wrong. Most
UI built-ins like UI::OpenDialog(), UI::ChangeWidget(), UI::QueryWidget()
complain in the logs when something is very wrong, but try to continue anyway
and assume (or return) some reasonable value.
But at some point you just can't go on regardless of application programmer
errors. And if UI::OpenDialog() failed (it catches exceptions thrown from
lower lib layers), there is no open dialog, so you cannot expect input from
that dialog.
In almost (?) all cases it's not UI::OpenDialog() that causes a program's
forceful termination but a UI::UserInput() that tries to work on the same
dialog that could not successfully be created. So it's actually not fatal to
do one thing wrong, but to try to continue without respect to any previous
errors.
I call that _very_ forgiving.
CU
--
Stefan Hundhammer
On Thu, Sep 04, 2008 at 03:45:36PM +0200, Stefan Hundhammer wrote:
On Donnerstag, 4. September 2008, Jiří Suchomel wrote:
Because of this:
// Most YCP developers never use the return value of UI::OpenDialog().
That is a fact, and it was meant as a statement of fact. But...
What should I do? Open a dialog stating that I coulnd't open a dialog? Or log an error and abort (what happens already)? Any action will just make the code unreadable for almost no benefit. ciao Arvin -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Donnerstag, 4. September 2008, Arvin Schnell wrote:
What should I do? Open a dialog stating that I coulnd't open a dialog? Or log an error and abort (what happens already)?
Any action will just make the code unreadable for almost no benefit.
If you read back on the archive of this list, those were almost my exact words
when this discussion was brought up late last year.
In most cases, you can't continue. Game over. And the UI will even post a
pop-up (if still possible) with the exact C++ exception text.
But still, if there is a reasonable way to continue, or if code is part of a
library that can get invalid values from the outside and still react
reasonably, the possiblity is there to handle errors gracefully. But in most
cases it won't be worth the hassle; something is already broken somewhere.
CU
--
Stefan Hundhammer
Arvin Schnell wrote:
On Thu, Sep 04, 2008 at 03:45:36PM +0200, Stefan Hundhammer wrote:
On Donnerstag, 4. September 2008, Jiří Suchomel wrote:
Because of this:
// Most YCP developers never use the return value of UI::OpenDialog(). That is a fact, and it was meant as a statement of fact. But...
What should I do? Open a dialog stating that I coulnd't open a dialog? Or log an error and abort (what happens already)?
Any action will just make the code unreadable for almost no benefit.
But what you actually *can* do, is really checking whether opening the dialog was successful and only in that case you can close it. See this common example: --- cut --- Wizard module - Opens Wizard a dialog ... UI::OpenDialog() do something UI::CloseDialog() ... Wizard module - Closes a Wizard dialog --- cut --- If you don't check the UI::OpenDialog() return value, UI::CloseDialog closes the Wizard module dialog. --- cut --- Wizard module - Opens Wizard a dialog ... boolean success = (boolean) UI::OpenDialog() do something if (success) UI::CloseDialog() ... Wizard module - Closes a Wizard dialog --- cut --- This is safer and even though it's not perfect, you might recover from that error sometimes. This is, for instance, vitally important for installation because one more UI::CloseDialog() can kill it. Bad luck. Bye Lukas
On Thu, Sep 04, 2008 at 04:09:40PM +0200, Lukas Ocilka wrote:
Arvin Schnell wrote:
On Thu, Sep 04, 2008 at 03:45:36PM +0200, Stefan Hundhammer wrote:
On Donnerstag, 4. September 2008, Jiří Suchomel wrote:
Because of this:
// Most YCP developers never use the return value of UI::OpenDialog(). That is a fact, and it was meant as a statement of fact. But...
What should I do? Open a dialog stating that I coulnd't open a dialog? Or log an error and abort (what happens already)?
But what you actually *can* do, is really checking whether opening the dialog was successful and only in that case you can close it.
See this common example:
[...] I will not clutter code with that stuff. With this brand new concept of object oriented programming the effect would be easy to achieve. Create an object that opens the dialog and remembers the status. In the destructor close the dialog. The dialog would even be closed when returning in the middle of the function. Just like fstream objects in C++. ciao Arvin -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
We now have a new `opt(`relaxSanityCheck) for the ButtonBox widget that will
perform a less stringent version of the sanity check. It allows to have more
than one button, yet not both an okButton and a cancelButton.
http://svn.opensuse.org/svn/yast/trunk/ycp-ui-bindings/examples/ButtonBox3-r...
Use your common sense when to use this.
CU
--
Stefan Hundhammer
Hi there, Qui, 2008-09-04 às 12:51 +0200, Stefan Hundhammer escreveu:
https://bugzilla.novell.com/show_bug.cgi?id=422612
This shows that there are cases where it is legitimate to have a pop-up dialog with a ButtonBox with more than one button, but only an okButton and no cancelButton:
...message... <Countdown>
[Stop] [OK]
We (mschmidkunz + tgoettlicher + sh) thought that this is the one exception from that rule; in general, all dialogs with more than one button should have an okButton (for the regular end) and a cancelButton (as a safe escape).
I'm not sure what the problem is with this one. The Stop button is clearly acting as a Cancel button here. It could have been re-labeled as such, and you wouldn't know the difference.
Now locilka found one more exception:
...error... [OK] [Details...]
I would vote to align that Details button as a Help button, since it doesn't trigger an action, and it's providing information. I think I've seen the Details button aligned to the Left in KDE error messages as well (in Gnome, an expander is generally used, so dunno). Cheers, Ricardo -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Ricardo Cruz wrote:
Hi there,
Qui, 2008-09-04 às 12:51 +0200, Stefan Hundhammer escreveu:
https://bugzilla.novell.com/show_bug.cgi?id=422612
This shows that there are cases where it is legitimate to have a pop-up dialog with a ButtonBox with more than one button, but only an okButton and no cancelButton:
...message... <Countdown>
[Stop] [OK]
We (mschmidkunz + tgoettlicher + sh) thought that this is the one exception from that rule; in general, all dialogs with more than one button should have an okButton (for the regular end) and a cancelButton (as a safe escape).
I'm not sure what the problem is with this one. The Stop button is clearly acting as a Cancel button here. It could have been re-labeled as such, and you wouldn't know the difference.
Well, this is actually `specialButton as it doesn't cancel anything, it stops the countdown and waits. If you click on the OK button, it's just as it was a normal informational message with OK button only. So what the Stop button does? Changes the the countdown message to informational message --> clearly a "special function".
Now locilka found one more exception:
...error... [OK] [Details...]
I would vote to align that Details button as a Help button, since it doesn't trigger an action, and it's providing information. I think I've seen the Details button aligned to the Left in KDE error messages as well (in Gnome, an expander is generally used, so dunno).
This idea sounds good. It's really similar to the Help button considering the type of information it provides. Bye Lukas
Lukas Ocilka wrote:
I would vote to align that Details button as a Help button, since it doesn't trigger an action, and it's providing information. I think I've seen the Details button aligned to the Left in KDE error messages as well (in Gnome, an expander is generally used, so dunno). Or provide an easy way to show a message with (by default) hidden details.
Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Seg, 2008-09-08 às 09:59 +0200, Lukas Ocilka escreveu:
Ricardo Cruz wrote:
Hi there,
Qui, 2008-09-04 às 12:51 +0200, Stefan Hundhammer escreveu:
https://bugzilla.novell.com/show_bug.cgi?id=422612
This shows that there are cases where it is legitimate to have a pop-up dialog with a ButtonBox with more than one button, but only an okButton and no cancelButton:
...message... <Countdown>
[Stop] [OK]
We (mschmidkunz + tgoettlicher + sh) thought that this is the one exception from that rule; in general, all dialogs with more than one button should have an okButton (for the regular end) and a cancelButton (as a safe escape).
I'm not sure what the problem is with this one. The Stop button is clearly acting as a Cancel button here. It could have been re-labeled as such, and you wouldn't know the difference.
Well, this is actually `specialButton as it doesn't cancel anything, it stops the countdown and waits. If you click on the OK button, it's just as it was a normal informational message with OK button only.
I see. I still see it as a cancelButton because it currently means two slightly different roles: * dismiss an operation. The user triggers some operation that prompts him a dialog, so the developer offers a Cancel button in case he made a mistake and wants to restore the previous state. * deny an operation. A dialog asks the user about performing an operation, allowing the user to reject it. Probably this is functioning more in line of a No button, but either way, I still see it as a cancelButton. Anyway, please put the "OK" button there as the okButton, and that one as something else. By the way, we may want to split the cancelButton by those two roles, so we can support close dialogs like: "Some documents are not saved. Save them? [Cancel] [No] [Yes]". (If you do change that, you may want to consider renaming the okButton to confirmButton, but maybe I guess I'm just being too picky. ;P)
So what the Stop button does? Changes the the countdown message to informational message --> clearly a "special function".
Now locilka found one more exception:
...error... [OK] [Details...]
I would vote to align that Details button as a Help button, since it doesn't trigger an action, and it's providing information. I think I've seen the Details button aligned to the Left in KDE error messages as well (in Gnome, an expander is generally used, so dunno).
This idea sounds good. It's really similar to the Help button considering the type of information it provides.
Yeah, but I think you should try to keep the Details a checkbox as you do in some dialogs; it should then expands the dialog to show that extra information in a plain YRichText (you guys do that at least for some sw_single dialog as I recall...). Cheers, Ricardo -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stefan Hundhammer wrote:
Now locilka found one more exception:
...error... [OK] [Details...]
I don't think this case should be solved that way. Here details is an action on the message, not the dialog It should be something like .... error .....
_Details_
[OK] (details being an hyperlink or collapsable message) Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (10)
-
Arvin Schnell -
Duncan Mac-Vicar Prett -
Jiří Suchomel -
Ladislav Slezak -
Lukas Ocilka -
Martin Schmidkunz -
Martin Vidner -
Ricardo Cruz -
Stanislav Visnovsky -
Stefan Hundhammer