On Thu, 5 Oct 2000, Angus Leeming wrote:
> On Thu, 05 Oct 2000, Allan Rae wrote:
> > This should be an updateBufferDependent() and the insets should hide
> > themselves if appropriate. I did this in the old tree and it worked fine.
> > I'll commit this as it is at present however (once I've looked through and
> > test compiled of course).
>
> Allan, I've read your comments, here, in the ChangeLog and in
> BufferView_pimpl.C.
>
> As I understand it, you're suggesting that each FormXXX would store a
> Buffer * dialogBuffer. This would be set to 0 when the dialog was hidden, but
> would be set to the current buffer in show(). update() would check that
> (dialogBuffer == lv->buffer()) and, if not, would call hide().
>
> Is this the idea?
I was thinking of just a bool. We don't need extra pointers lying around.
The idea is simply to have something like:
void FormBase::show()
{
...
if (update()) {
// raise or show form as appropriate
} else {
hide();
}
}
However we actually need the call to hide() within update() since update
is connected to updateBufferDependent. Therefore we get something like:
void FormWhatever::update()
{
bool updateable(true); // assume it'll be updatable
...
// determine if this dialog is still valid.
// If for example a buffer switch occurred the inset won't
// exist in this buffer so you should be able to test that
// without crashing LyX and can then set updateable = false;
// and not do any updating
...
if (false == updateable) {
hide();
}
}
actually you should be able to write something like:
void FormWhatever::update()
{
if (...test if dialog should be updated or hidden...) {
bc_.cancel(); // see further below
// update the dialog
} else {
hide();
}
}
Therefore we can leave show() alone:
void FormBase::show()
{
...
update();
if (form()->visible)
// raise form
} else {
// show form
}
}
A call to show() is only made when the user wants to access a dialog. It
might already be visible in which case the update() should be successful
(ie. it didn't hide() the dialog). I don't think we'd have a situation
where a call to show() occurred where update() would want to hide() a
dialog that was already visible when we haven't switched
buffers. Toggling read-only calls update() via updateBufferDependent and
isn't a problem.
The only tricky case I can think of might be due to your code in some of
the insets that effectively forces you to close an inset dialog in order
to open it again with a new insets details. I think this is overly
restrictive. Just upadte the dialog with the new insets details and if
the user loses their changes from the previous stuff in the dialog too
bad. They obviously wanted the new dialog contents or they wouldn't have
asked for it.
There is however a small problem with my introduction of ButtonController
into FormBase and that is that then state of the ButtonController for each
dialog needs to be kept in each buffer. Why? Try this: open two
documents, open the Document dialog, change something, switch documents.
The contents has been updated but the ButtonController is in the wrong
state for this dialog. Actually, switching buffers like this should reset
the ButtonController to the INITIAL state. Hmmm... I think we can safely
fix this by adding a call to bc_.cancel() at the start of update() --
since we might need a call to bc_.read_only(...) somewhere in the body.
...thinking... Yes, I'm sure that's what's needed. I could do this
myself but you are so keen I'll let you argue it out a bit further before
implementing it.
There may be one small catch with the bc_.cancel() addition and that would
be for dialogs like Tabular that update part of their dialog based upon
cursor movement. These should use a separate signal and target though
since only part of the dialog is updated so shouldn't really be a problem.
> I have one final question. In BufferView_pimpl.C, your new
> updateBufferDependent() signal occurs before the
>
> if (!buffer_) {
> buffer_ = bufferlist.first();
> }
>
> Shouldn't the signal be emitted immediately after this call? Finally, the
> extra updateBufferDependent() signal in the next if( buffer ) loop is now
> redundant?
Damn, I knew there was a call there somewhere but obviously didn't look.
The newest line should be removed -- the one added yesterday. The old one
worked as I'd expected before.
> Shall I have a go at all this?
Sure. I'll be away all weekend and nowhere near a computer. Hopefully my
back will thank me.
Allan. (ARRae)
