On Wed, Oct 20, 2010 at 10:37:29AM +0200, Andre Poenitz wrote:
> On Wed, Oct 20, 2010 at 03:54:03AM +0200, Peter Kümmel wrote:
> >
> > > I think what's happening is this. If you export pdf (say) without there
> > > already being a pdf file there, then everything is fine. But if the pdf
> > > file exists, then LyX will try to ask the user whether to overwrite.
> > > This means creating a dialog as a child of the parent. But the parent,
> > > from what I can tell, is in the main thread, and that's not allowed.
> > >
> > > I'll paste the full error I get below. As you'll see, LyX crashes here.
> > > Here's the backtrace:
> >
> > This makes it complicated: pass a signal via Qt::QueuedConnection to
> > the gui thread and wait for the answer before continuing.
> >
> > Andre, what's the best way to wait for the answer from the gui thread,
> > QEventLoop?
>
> I personally believe that nested event loops are always evil.
> In this case I'd completely stop the export, let the gui pop up
> the dialog, and on confirmation re-initiate the export process
> with a 'force' flag or such.
I think the necessity of bidirectional core-gui communication would
be gone, if the core were driven by the gui, not the other way round:
In core (pseudo code):
Result Buffer::export(File file)
{
// No Gui code here.
if (file.exists())
return FileExistsError;
doTheExport();
return EverythingOk;
}
In gui:
void Foo::export(File file)
{
if (file.exists()) {
ConfirmOverwriteDialog dialog;
if (dialog.exec() == NotConfirmed)
return;
file.remove();
}
if (buffer.export() != EverythingOk) {
ProblemDialog dialog;
dialog.exec();
}
}
and in the server:
void Bar::export(File)
{
if (file.exists()) {
if (!forceFlagWasGiven())
return FileExistsError;
file.remove();
}
if (buffer.export() != EverythingOk)
bark();
}
Andre'
