Default button issues in Qt dialogs

[elbows@…]

In most of the Qt frontend dialogs, the default button (invoked by hitting
enter) is either Cancel or Restore. This behavior is different from most other
applications, and from previous versions of lyx, and is therfore confusing. It
also objectively makes sense to have "Ok" be the default -- most users will be
more likely to make changes they want to keep, than changes they want to discard.

[levon]

Somewhat of an exaggeration. Most dialogs do in fact have OK as default.
Exceptions :

Character, Paragraph, Document, Minipage,
Float, External -> should fix

Cross -> apply is default (this is new, not in 1.3). Should
probably fix.

Preferences -> should not fix, would regress a UI problem

Citation -> not sure, needs testing

All others look OK to me, tell me if I missed some.

We need to be careful with the sudden disappearing window syndrome,
in particular the qlineedits are a problem.

[elbows@…]

Patch

[levon]

Before I apply this, you did use a designer from Qt 2 didn't you ?

The problem is that it's reasonably natural to press return after
entering text in a QLineEdit. In a dialog with a default button,
this activates it. Personally I consider this a Qt bug, but there
are cases such as preferences where this is actually a real PITA.

"OK" is disabled until you change something

I think "Escape" is relatively well known. The OK disabling is a side-effect
of the controller code. It may be possible to use autoDefault = true
with OK|Close to get the right behaviour here. Fancy doing an experiment ?

[elbows@…]

Yeah, I used the qt2 designer.

I messed around with autoDefault, and it mostly does what we want, but sometimes
produces weird results. For example, in the Paragraph dialog I set OK to
default, Cancel to autoDefault. If you open the Paragraph dialog for an empty
paragraph, OK is disabled, and Cancel becomes the default. When OK becomes
enabled, it usually becomes default. However, if you use the accelerator key to
check the "No Indent" box, OK becomes enabled but Cancel remains the default. I
am not sure why this happens.

One possible solution is to set Cancel to default, and when OK becomes enabled,
manually set that to default. But after glancing at the controller code, it
looks like this might be tricky.

As for the disappearing window problem -- it seems that, of the dialogs I have
changed, only Document has enough QLineEdits to cause trouble (in the margin
panel, for example). I could make this dialog have no default button, or I could
try to do some special handling of the enter key when focus is in a QLineEdit.

[levon]

OK becomes enabled but Cancel remains the default.

How odd. What happens if you set OK to default, and *both*
OK and Cancel to autodefault ? Are you also using Qt 2 ?

As for the disappearing window problem -- it seems that, of the dialogs I have

Actually, I wasn't remembering correctly. The really troublesome
widget is QSpinBox, where editing the value directly requires a return.
So the QLineEdits should be OK-ish.

[elbows@…]

How odd. What happens if you set OK to default, and *both*
OK and Cancel to autodefault ?

Then OK is always the default.

Are you also using Qt 2 ?

Actually, qt 3.1.1 (multithreaded version)
I have qt2 instaled, but configure won't detect it properly (probably the
presence of both versions is confusing things).

Also, I have noticed that I don't seem to have to hit enter when I edit a
QSpinBox. Maybe they fixed this for Qt 3?

[levon]

Then OK is always the default.

Well we'll have to scrap that then. For now at least.

Also, I have noticed that I don't seem to have to hit enter when I edit a

QSpinBox. Maybe they fixed this for Qt 3?

No, the behaviour's the same, the signal is only sent
if you mouse the pointer out of the spin box. It's insane but true.

Anyway, I'll apply your patch if we ever get cvs.lyx.org back up
and running !

[levon]

Applied to branch and trunk.