Re: [Development] [SPAM] Re: QDialog vs QPushButton and it's autoDefault default

2019-02-19 Thread Bernhard Lindner 
> Did you try to accept the Enter in your line edit instead? That way, it 
> would not propagate up. You could simply eat it or make it focus the 
> next item in the focus chain or something that makes sense in your context.

I thought about that. But it means a workaround out of position. What about 
line edits in 
delegates? Or in editable comboboxes, etc.? This can get nasty. Some kind of 
dialog-global 
option would be necessary.

I did a lot of research and found several people having the same issue with the 
current
implementation. Alas I could not find a clean way to solve it. 

So as a workound I finally changed the significantly complex dialog .ui files 
from QDialog
to QWidget, introduced a custom base class, threw away the QDialogButtonBoxes 
and added
the dialog buttons as normal buttons in a separate layout. This way the 
standardized
dialog behaviour and design is down the drain but for non-trivial dialogs this 
is much
better than frustrating users using  by accident.

A new option to disable the autoDefault feature for entire dialogs would be 
very helpful.
I considered writing a corresponding suggestion but I guess it would rot in the 
issue
tracker forever.

-- 
Best Regards, 
Bernhard Lindner


signature.asc
Description: This is a digitally signed message part
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] [SPAM] Re: QDialog vs QPushButton and it's autoDefault default

2019-02-19 Thread André Somers 
Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  On 12/02/2019 20:54, Bernhard Lindner wrote: > 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. [...] 

Content analysis details:   (5.4 points, 4.0 required)

 pts rule name  description
 -- --
-0.0 BAYES_20   BODY: Bayes spam probability is 5 to 20%
[score: 0.0987]
 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
  [Blocked - see ]
 0.0 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[91.208.229.55 listed in bl.mailspike.net]
-0.0 SPF_HELO_PASS  SPF: HELO matches SPF record
 1.3 RCVD_IN_RP_RNBLRBL: Relay in RNBL,
https://senderscore.org/blacklistlookup/
[91.208.229.55 listed in bl.score.senderscore.com]
 2.7 RCVD_IN_PSBL   RBL: Received via a relay in PSBL
[91.208.229.55 listed in psbl.surriel.com]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---


On 12/02/2019 20:54, Bernhard Lindner wrote:

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.



Did you try to accept the Enter in your line edit instead? That way, it 
would not propagate up. You could simply eat it or make it focus the 
next item in the focus chain or something that makes sense in your context.


André


--- End Message ---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development