Let me try to say why I'm confused about how to handle updating the
dialog. Consider update_contents(). Whether before or after my patch, we
do this:
ParagraphParameters const & params = controller().params();
and then params is used to update the dialog. The issue we're facing is
that, if the user has moved the cursor, then the parameters in the
controller are out of sync and need to be reset. Note that this was a
problem before my patch. If you open the paragraph dialog in, say, a
double-spaced paragraph and then click in a single-spaced paragraph, the
dialog doesn't change. It still says "double", which is at best
confusing. Or again: If you start out in a normal paragraph and then
click into a list item, the "label width" bit is still disabled. So the
dialog generally needs to be updated when the user clicks in a new
paragraph.
The temptation has been to do something in update_contents(), which gets
called when the user clicks in the buffer. The idea was floated that we
could simply get the current parameters from kernel().etc.etc, but then
we're just bypassing the controller, and that seems silly. What's worse,
it seems sheer luck that we don't later get problems at apply(), since
the controller is still out of sync. (We don't get problems, in fact,
because params_ is completely overwritten at that point---that's the
luck part.) So SOMEHOW controller().params_ needs to be updated when the
cursor moves, which is why I was tempted to call initParams() in
update_contents(). I now see, for several reasons, that this is not the
right place to do it, but initParams() needs to get called one way or
another.
So I've been exploring this, and I'll report what I've found, in the
hope that it is of some use. It's clear to me now that I'm not going to
solve this problem, so I'm handing it off. I'll rework the dialog with
radio buttons and we can see how that compares to the combobox. The
solution to the initParams() issue will be independent of that, of course.
This part of initParams()
// For now, only reset the params on "show".
// Don't bother checking if the params are different on "update"
if (action == 0) {
params_.reset(tmp);
} else {
delete tmp;
}
suggests that initParams() might be called with something like: update
true\n\align .... Maybe that's what should happen? But how? Nothing I
have managed to do causes that.
In other cases where this update happens---for example, tabulars---it's
because LyXView::updateDialog is called as a result of the signal
BufferView::updateDialog()'s being issued. But updateDialog doesn't get
called simply because the cursor moves and, while one could presumably
arrange that---say, in WorkArea---it has to be called with the name of
the dialog we want to update and the data for doing it, but then it
looks like the existence of QParagraphDialog has to be hard-coded into
WorkArea, and I'm guessing that's bad, too. (The tabular inset can
handle this because it knows it's a tabular inset.) So that doesn't seem
to be the answer either.
So, for what it's worth, it now seems to me that the problem is really
that there is, at present, nothing at all in the code that is really
designed to update the dialogs in a more general way, except when the
buffer is changed in other ways---switched, say, or if the layout is
changed. Indeed, the fact that update_contents() gets called is a happy
accident. Here's what happens when the user clicks in a new paragraph.
WorkArea::dispatch() calls LyXView::updateToolbars() which calls
Dialogs::checkStatus. The comment preceding this call says that its
purpose is to update the readonly status of dialogs. But as a kind of
weird accident, update_contents() gets called to correct for the
apparent over-enthusiasm of refreshReadOnly()---see the comment in
Dialog.C.
One final point. At present, if you switch buffers, the paragraph dialog
just gets hidden (because, while initParams() gets called by
updateBufferDependent(), it gets called with no data and simply returns
false). In effect, that kind of makes this dialog "buffer modal". So one
solution here, at least in the meantime, would be to go back to my
original idea, which was just to make the paragraph dialog modal. Then
none of the problems above arise. That's what I'd suggest we do in the
short term.
Richard
--
==================================================================
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==================================================================
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
