Hi Volker! Hm, ok, I see. Thanks a lot for the explanations.
Turned out the reason why the autoDefault heuristics kicks in is because the accept-role- button is disabled by default (until the user selects an item from the table). So the heuristic takes over a bit to early. To provide a non-auto-default I will need to set the default button programmatically. Still I am not satisfied. People tend to finish text input by pressing Enter, even in dialogs. For dialogs containing a sumplementary line edit (not being the main input of the dialog) this may also trigger some dialog action ahead of time. Is there a good solution to help user avoiding that mistake? I considered not to have a default button at all (neither set programmatically nor selected automatically) but that seems difficult with that always-on heuristics. > The default button gets pressed when the user presses Enter in a dialog, > unless an > autoDefault button has focus, in which case that button will be pressed. > That’s what the > user would expect. > > So, that your button is pressed when focus is in a QLineEdit would suggest > that your > clear button is the next autoDefault button in the focus chain (as per the > documented > behavior, and that there is no default button. Note that when using > QDialogButtonBox, > you only get a default button if one of the buttons in the box has the > “Accept” role - > otherwise you have to make one of the buttons the default button explicitly. > > So to your questions: > > 1) the behavior you are seeing seems to be as it should be, but you might > have to set a > default button for autoDefault heuristics not to take over completely and > cause > confusion. > 2) Opt-out would make it more work to have the kind of UI the user expects > (focused > button is pressed on Enter). > 3) QDialogButtonBox isn’t visible to the user, so a button behavior > differnelty in a > dialog just because it’s laid out in code with the help of QDialogButtonBox > seems > somewhat arbitrary. > 4) Default values of object properties being context dependent is not that > unusual > > > Cheers, > Volker > -- Best Regards, Bernhard Lindner On 11 Feb 2019, at 22:47, Bernhard Lindner <priv...@bernhard-lindner.de> wrote: > > > > Hi! > > > > I just experienced same strange behavior of QPushButton. I want to kindly > > ask for some > > explanations. > > > > I wrote a QDialog derived dialog. That dialog has a standard > > QDialogButtonBox with > > "Accept" and "Close" buttons. It also has various other widgets, especially > > a table > > view > > for item selection and a more complex generic/reusable filter panel > > (QWidget derived) > > that > > can be attached to any table view for complex user side filtering. That > > panel contains > > various widgets, including two buttons. > > > > I now have tripped painfully over a strange behavior that I could track > > back to the > > fact > > that one of those two buttons was automagically set as the dialog's default > > button. > > Now, > > whenever a user presses <Enter> to confirm QLineEdit filter input, also the > > mentioned > > clear button is activated - causing a fabulous mess. > > > > After some research I could explain that unexpected behavior: > > > > autoDefault : bool > > This property holds whether the push button is an auto default button. > > ... > > This property's default is true for buttons that have a QDialog parent > > > > This also means there is a workaround: I need to call > > "setAutoDefault(false)" on each > > button that has the slightest chance to be ever used in a dialog. > > Everywhere. That is > > doable but seems very counterintuitive to me. > > > > So my questions are: > > 1. Is this actually how the autoDefault mechanism should work? > > 2. Why an opt-out instead of an opt-in? > > 3. Regarding opt-out: Why not restricting the autoDefault default of true > > to buttons > > with > > QDialogButtonBox parents instead of QDialog parents? > > 4. Anyway, is it good style to change the default value (!) of a property > > dynamically > > like > > this?> > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
