Andreas Vox wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > >> >> Question: do you need to protect the call to "find_or_build"? > > Probably find_or_build needs to be protected from being called > while a second show() hasn't finished yet. Maybe not. > Doesn't matter because you have to prevent the following call > to dialog->show() anyhow. > >> If not, then >> isn't "showing" equivalent to dialog->isVisible()? > > No! show() sets dialog->isVisible() to true, hide() sets it to false. > While show() is busy creating, initializing and displaying the > dialog it should not be called again, that's what "showing" is for. > Better name it "in_show" or "critical_show".
Ok. > The problem is that LyX does cooperative multithreading, at > least under Qt. Have a look at the static call tree I posted for > bug 1790: http://bugzilla.lyx.org/show_bug.cgi?id=1790#c1 Yes, I've read it and I understand the point you're making. I'm just thinking of the future when we have multiple LyX windows, each with their own set of dialogs. One improvement over your original patch would be to make 'showing' a member of the src/frontends/Dialogs class. Then 'in_show' or whatever you choose to call it will behave as expected with multiple Dialogs instances. However, what you are really trying to do is to block on a per-individual-Dialog basis. The above solution will fail to open a dialog opened by a dialog, won't it? Ok, that doesn't happen in the current code base, but that's not really the point. > Any call to sync_events may cause calls to timeouts or > dispatch functions. > > IMO the call to sync_events in showCursor just has to go, even > if it causes cursor artefacts. Otherwise we will need to design > LyX for cooperative multithreading (lots of critical sections and > a LyX-owned event queue, I'd say). Yes, I can see the problems. Let's keep things as simple as possible for the time being ;-) -- Angus
