> >
> > 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:
Yes, this would give us a clean solution with a asymmetric,
master/slave (gui/worker) thread organization.
But I've tried the "wait for the gui response" ansatz, because I hope
that I have to change less code. And I assume your idea would end in
a redesign of several part of LyX.
> 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'
--
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
