Angus,
Now I've looked at the cross reference dialog, I don't know why Andreas
made it instant apply: it's for inserting new refs as well as editing
existing ones. So in this case I'd say okay/cancel is the appropriate
button setup. This will go in that thread in a moment.
More general comments on the issues associated with instant apply
dialogs follow. Please don't think I'm trying to be argumentative, I'm
just brain-dumping. Have a good trip by the way!
On Thu, 2005-03-10 at 18:41 +0000, Angus Leeming wrote:
> > The reason for doing a manual dispatchParams in the dialog code rather
> > than just triggering the apply method is that these signals represent an
> > interactive process: it should be as streamlined as possible, rather
> > than reading all the parameters out of the dialog just to apply a change
> > to one.
>
> Nonsense. You're updating the state of a single inset. That's conceptually
> a single piece of information.
This point actually isn't all that important to me, if you really want
to call the whole apply process for each change then that doesn't make
much difference.
> Explain to me what is wrong with the UI of the QRef or XRef dialogs and
> how the GRef dialog does things better and I might buy it. However, the
> Controller does a heap of internal accountancy stuff when its told that
> the Apply Button has been pressed. It doesn't *just* call GRef::apply.
> You're subverting all of that by invoking dispatch directly.
Don't confuse the issue of (1) whether to make the dialog instant-apply
with the issue of (2) whether to have the dialog dispatchParams itself
rather than calling the controller's apply function.
As for (2), I don't really know, maybe it's worth reading out the whole
dialog on each change. If you say so. I've never paid much attention
to what the controller does behind the scenes. Anyway, I think the
candidates for instant-apply have already been done: it will be a small
task at some point to go back and make them not use dispatchParams
themselves. No big deal.
As for (1), I shall firstly invoke the holy GNOME HIG of might and
power:
"""
Do not make the user press an OK or Apply button to make the changes
happen, unless either:
* the change will take more than about one second to apply, in
which case applying the change immediately could make the system
feel slow or unresponsive, or
* the changes in the window have to be applied simultaneously to
prevent the system entering a potentially unstable state. For
example, the hostname and proxy fields in a network properties
window.
"""
If you don't agree that lyx-gtk ought to follow the GNOME guidelines,
then I shall simply say that I think the okay/apply/cancel is an
overcomplicated UI for a smallish dialog.
LyX introduces the slightly uncomfortable special case that quite a
number of the dialogs serve for both editing properties and inserting
new objects. This is a third exception to the "instant apply dialogs
are good" policy.
John
