Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Freitag, den 22.10.2010, 16:44 +0200 schrieb Pavel Sanda:
 Richard Heck wrote:
  Along these same lines, I wonder if we should pop up an info box when
  the export is done. If it takes a while, then the user may not notice the
  status message, and those get over-written quickly, anyway.
 
  In a way, that would solve this issue: It's still going until you get told 
  that
  it's not.
 
 previously we had to wait some time for generation now we will spend it via
 mouse haunting of ok button :) why can't we have the normal mouse cursor
 with small hourglass cursor as windows have when something goes in background?
 
 pavel

Now the cursor switches for 3 seconds to the busy symbol until the
thread has finished.

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Samstag, den 23.10.2010, 12:52 +0200 schrieb Peter Kümmel:
 Am Freitag, den 22.10.2010, 16:44 +0200 schrieb Pavel Sanda:
  Richard Heck wrote:
   Along these same lines, I wonder if we should pop up an info box when
   the export is done. If it takes a while, then the user may not notice the
   status message, and those get over-written quickly, anyway.
  
   In a way, that would solve this issue: It's still going until you get 
   told 
   that
   it's not.
  
  previously we had to wait some time for generation now we will spend it via
  mouse haunting of ok button :) why can't we have the normal mouse cursor
  with small hourglass cursor as windows have when something goes in 
  background?
  
  pavel
 
 Now the cursor switches for 3 seconds to the busy symbol until the
 thread has finished.

every 3 sec for 3 sec

 
 Peter
 
 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Freitag, den 22.10.2010, 16:44 +0200 schrieb Pavel Sanda:
> Richard Heck wrote:
> > Along these same lines, I wonder if we should pop up an info box when
> > the export is done. If it takes a while, then the user may not notice the
> > status message, and those get over-written quickly, anyway.
> >
> > In a way, that would solve this issue: It's still going until you get told 
> > that
> > it's not.
> 
> previously we had to wait some time for generation now we will spend it via
> mouse haunting of ok button :) why can't we have the normal mouse cursor
> with small hourglass cursor as windows have when something goes in background?
> 
> pavel

Now the cursor switches for 3 seconds to the busy symbol until the
thread has finished.

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Samstag, den 23.10.2010, 12:52 +0200 schrieb Peter Kümmel:
> Am Freitag, den 22.10.2010, 16:44 +0200 schrieb Pavel Sanda:
> > Richard Heck wrote:
> > > Along these same lines, I wonder if we should pop up an info box when
> > > the export is done. If it takes a while, then the user may not notice the
> > > status message, and those get over-written quickly, anyway.
> > >
> > > In a way, that would solve this issue: It's still going until you get 
> > > told 
> > > that
> > > it's not.
> > 
> > previously we had to wait some time for generation now we will spend it via
> > mouse haunting of ok button :) why can't we have the normal mouse cursor
> > with small hourglass cursor as windows have when something goes in 
> > background?
> > 
> > pavel
> 
> Now the cursor switches for 3 seconds to the busy symbol until the
> thread has finished.

every 3 sec for 3 sec

> 
> Peter
> 
> 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Guenter Milde]

On 2010-10-21, Vincent van Ravesteijn wrote:

  but now we have new problem - how to notice user that exporting is stillbr=
  in progress or finished (some subvserion of hourglass cursor?).br

 Status bar: Moving icons. Text. Messages.

greyed out (or otherwise modified) export toolbar buttons?

Günter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Guenter Milde wrote:
  Status bar: Moving icons. Text. Messages.
 
 greyed out (or otherwise modified) export toolbar buttons?

wont help in case you use only menu.
pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/21/2010 07:17 PM, Vincent van Ravesteijn wrote:


Status bar: Moving icons. Text. Messages.

Op 22 okt 2010 01:13 schreef Pavel Sanda sa...@lyx.org 
mailto:sa...@lyx.org:


Richard Heck wrote:
 On 10/20/2010 08:59 PM, Peter Kümmel wrote:
 Am Dienstag, den 19.10.2010, 20...

i checked that export works on simple document here too.
but now we have new problem - how to notice user that exporting is still
in progress or finished (some subvserion of hourglass cursor?).


Along these same lines, I wonder if we should pop up an info box when
the export is done. If it takes a while, then the user may not notice the
status message, and those get over-written quickly, anyway.

In a way, that would solve this issue: It's still going until you get 
told that

it's not.

Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Richard Heck wrote:
 Along these same lines, I wonder if we should pop up an info box when
 the export is done. If it takes a while, then the user may not notice the
 status message, and those get over-written quickly, anyway.

 In a way, that would solve this issue: It's still going until you get told 
 that
 it's not.

previously we had to wait some time for generation now we will spend it via
mouse haunting of ok button :) why can't we have the normal mouse cursor
with small hourglass cursor as windows have when something goes in background?

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Edwin Leuven]

i suppose for the same reason that we cannot have a pointing finger
when the mouse hovers something clickable...

On 2010-10-22, Pavel Sanda sa...@lyx.org wrote:
 Richard Heck wrote:
 Along these same lines, I wonder if we should pop up an info box when
 the export is done. If it takes a while, then the user may not notice the
 status message, and those get over-written quickly, anyway.

 In a way, that would solve this issue: It's still going until you get told

 that
 it's not.

 previously we had to wait some time for generation now we will spend it via
 mouse haunting of ok button :) why can't we have the normal mouse cursor
 with small hourglass cursor as windows have when something goes in
 background?

 pavel



-- 
http://leuven.economists.nl

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Guenter Milde]

On 2010-10-21, Vincent van Ravesteijn wrote:

> > but now we have new problem - how to notice user that exporting is 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Guenter Milde wrote:
> > Status bar: Moving icons. Text. Messages.
> 
> greyed out (or otherwise modified) export toolbar buttons?

wont help in case you use only menu.
pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/21/2010 07:17 PM, Vincent van Ravesteijn wrote:


Status bar: Moving icons. Text. Messages.

Op 22 okt 2010 01:13 schreef "Pavel Sanda" >:


Richard Heck wrote:
> On 10/20/2010 08:59 PM, Peter Kümmel wrote:
>> Am Dienstag, den 19.10.2010, 20...

i checked that export works on simple document here too.
but now we have new problem - how to notice user that exporting is still
in progress or finished (some subvserion of hourglass cursor?).


Along these same lines, I wonder if we should pop up an info box when
the export is done. If it takes a while, then the user may not notice the
status message, and those get over-written quickly, anyway.

In a way, that would solve this issue: It's still going until you get 
told that

it's not.

Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Richard Heck wrote:
> Along these same lines, I wonder if we should pop up an info box when
> the export is done. If it takes a while, then the user may not notice the
> status message, and those get over-written quickly, anyway.
>
> In a way, that would solve this issue: It's still going until you get told 
> that
> it's not.

previously we had to wait some time for generation now we will spend it via
mouse haunting of ok button :) why can't we have the normal mouse cursor
with small hourglass cursor as windows have when something goes in background?

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Edwin Leuven]

i suppose for the same reason that we cannot have a pointing finger
when the mouse hovers something clickable...

On 2010-10-22, Pavel Sanda  wrote:
> Richard Heck wrote:
>> Along these same lines, I wonder if we should pop up an info box when
>> the export is done. If it takes a while, then the user may not notice the
>> status message, and those get over-written quickly, anyway.
>>
>> In a way, that would solve this issue: It's still going until you get told
>>
>> that
>> it's not.
>
> previously we had to wait some time for generation now we will spend it via
> mouse haunting of ok button :) why can't we have the normal mouse cursor
> with small hourglass cursor as windows have when something goes in
> background?
>
> pavel
>


-- 
http://leuven.economists.nl

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 08:59 PM, Peter Kümmel wrote:

Am Dienstag, den 19.10.2010, 20:40 -0400 schrieb Richard Heck:
   

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:
 

Could you check if it still crashes?

   

No crash! Nice work. Seems to work with child documents, too.

Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Richard Heck wrote:
 On 10/20/2010 08:59 PM, Peter Kümmel wrote:
 Am Dienstag, den 19.10.2010, 20:40 -0400 schrieb Richard Heck:

 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:
  
 Could you check if it still crashes?


 No crash! Nice work. Seems to work with child documents, too.

i checked that export works on simple document here too.
but now we have new problem - how to notice user that exporting is still
in progress or finished (some subvserion of hourglass cursor?).

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Vincent van Ravesteijn]

Status bar: Moving icons. Text. Messages.

Op 22 okt 2010 01:13 schreef Pavel Sanda sa...@lyx.org:

Richard Heck wrote:
 On 10/20/2010 08:59 PM, Peter Kümmel wrote:
 Am Dienstag, den 19.10.2010, 20...
i checked that export works on simple document here too.
but now we have new problem - how to notice user that exporting is still
in progress or finished (some subvserion of hourglass cursor?).

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 08:59 PM, Peter Kümmel wrote:

Am Dienstag, den 19.10.2010, 20:40 -0400 schrieb Richard Heck:
   

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:
 

Could you check if it still crashes?

   

No crash! Nice work. Seems to work with child documents, too.

Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Richard Heck wrote:
> On 10/20/2010 08:59 PM, Peter Kümmel wrote:
>> Am Dienstag, den 19.10.2010, 20:40 -0400 schrieb Richard Heck:
>>
>>> 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:
>>>  
>> Could you check if it still crashes?
>>
>>
> No crash! Nice work. Seems to work with child documents, too.

i checked that export works on simple document here too.
but now we have new problem - how to notice user that exporting is still
in progress or finished (some subvserion of hourglass cursor?).

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Vincent van Ravesteijn]

Status bar: Moving icons. Text. Messages.

Op 22 okt 2010 01:13 schreef "Pavel Sanda" :

Richard Heck wrote:
> On 10/20/2010 08:59 PM, Peter Kümmel wrote:
>> Am Dienstag, den 19.10.2010, 20...
i checked that export works on simple document here too.
but now we have new problem - how to notice user that exporting is still
in progress or finished (some subvserion of hourglass cursor?).

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Andre Poenitz]

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.

Andre'

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Abdelrazak Younes]

On 10/20/2010 10:37 AM, 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 agree. But this would mean that all dialog related code must be 
removed from the export functions... which would be a good thing in 
itself but is a bit more involved than what was originally thought.


Abdel.

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Andre Poenitz]

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' 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

 
 I agree. But this would mean that all dialog related code must be 
 removed from the export functions... which would be a good thing in 
 itself but is a bit more involved than what was originally thought.

The box is open again ;)

 
 Abdel.
 
 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Peter Kümmel wrote:
  
  I agree. But this would mean that all dialog related code must be 
  removed from the export functions... which would be a good thing in 
  itself but is a bit more involved than what was originally thought.
 
 The box is open again ;)

ouch. is there easy way to switch back or would it mean revert the whole
serie of patches?

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Enrico Forestieri]

On Wed, Oct 20, 2010 at 11:00:46AM +0200, Andre Poenitz wrote:
 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();
 }
 

It is a bit more complicated than that. For example, if you export to
latex, every bitmap graphics is converted to eps and, if an eps with
same name exists, LyX tries to popup a dialog for overwrite confirmation.
The moral is that a change like this should be first well thought and
designed, instead of throwing it there and then trying to solve the
problems that will inevitably arise.

-- 
Enrico

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 04:37 AM, 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 don't know enough about this to know if this is a silly idea or not, 
but I'll mention it anyway.


The dialogs we are discussing are all of the frontend::Alert variety. 
Indeed, unless I am mistaken, those are the only dialogs we create from 
the core. Is there any way we could encapsulate the needed logic there?


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 04:37 AM, 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 don't know enough about this to know if this is a silly idea or not, 
but I'll mention it anyway.


The dialogs we are discussing are all of the frontend::Alert variety. 
Indeed, unless I am mistaken, those are the only dialogs we create from 
the core. Is there any way we could encapsulate the needed logic there?


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 05:44 AM, Pavel Sanda wrote:

Peter Kümmel wrote:
   

I agree. But this would mean that all dialog related code must be
removed from the export functions... which would be a good thing in
itself but is a bit more involved than what was originally thought.
   

The box is open again ;)
 

ouch. is there easy way to switch back or would it mean revert the whole
serie of patches?

   
Some of the early ones were just cleanup, and export code itself is in 
an #if 0 block,
so it shouldn't be that bad. Maybe it would be worth reverting r35726. 
To answer
Peter's question, in the log, I'm not sure that is better. If we go back 
to before that,

then it's fairly easy.

The attached patch should do it.

Richard

Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp   (revision 35728)
+++ src/frontends/qt4/GuiView.cpp   (working copy)
@@ -370,9 +370,6 @@
static docstring compileAndDestroy(Buffer const * orig, Buffer * 
buffer, string const  format);
static docstring saveAndDestroy(Buffer const * orig, Buffer * buffer, 
FileName const  fname);
 
-   templateclass T
-   static docstring runAndDestroy(const T func, Buffer const * orig, 
Buffer * buffer, string const  format, string const  msg);
-   
// TODO syncFunc/previewFunc: use bind
bool asyncBufferProcessing(string const  argument,
   Buffer const * used_buffer,
@@ -2818,37 +2815,48 @@
 
 
 #if (QT_VERSION = 0x040400)
-templateclass T
-docstring GuiView::GuiViewPrivate::runAndDestroy(const T func, Buffer const * 
orig, Buffer * buffer, string const  format, string const  msg)
+docstring GuiView::GuiViewPrivate::compileAndDestroy(Buffer const * orig, 
Buffer * buffer, string const  format)
 {
bool const update_unincluded =
buffer-params().maintain_unincluded_children
 
!buffer-params().getIncludedChildren().empty();
-   bool const success = func(format, update_unincluded);
+   bool const success = buffer-doExport(format, true, update_unincluded);
delete buffer;
busyBuffers.remove(orig);
return success
-   ? bformat(_(Successful  + msg +  to format: %1$s), 
from_utf8(format))
-   : bformat(_(Error  + msg +  format: %1$s), 
from_utf8(format));
+   ? bformat(_(Successful compilation to format: %1$s), 
from_utf8(format))
+   : bformat(_(Error compiling format: %1$s), from_utf8(format));
 }
 
-docstring GuiView::GuiViewPrivate::compileAndDestroy(Buffer const * orig, 
Buffer * buffer, string const  format)
-{
-   bool (Buffer::* mem_func)(std::string const , bool, bool) const = 
Buffer::doExport;
-   return runAndDestroy(bind(mem_func, buffer, _1, true, _2), orig, 
buffer, format, export);
-}
-
+#if 0
+/// Asynchronous export runs into problems with the  creation of
+/// dialogs from the export thread:
+/// http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg162502.html
 docstring GuiView::GuiViewPrivate::exportAndDestroy(Buffer const * orig, 
Buffer * buffer, string const  format)
 {
-   bool (Buffer::* mem_func)(std::string const , bool, bool) const = 
Buffer::doExport;
-   return runAndDestroy(bind(mem_func, buffer, _1, false, _2), orig, 
buffer, format, export);
-
+   bool const update_unincluded =
+   buffer-params().maintain_unincluded_children
+
!buffer-params().getIncludedChildren().empty();
+   bool const success = buffer-doExport(format, false, update_unincluded);
+   delete buffer;
+   busyBuffers.remove(orig);
+   return success
+   ? bformat(_(Successful export to format: %1$s), 
from_utf8(format))
+   : bformat(_(Error exporting to format: %1$s), 
from_utf8(format));
 }
+#endif
 
 docstring GuiView::GuiViewPrivate::previewAndDestroy(Buffer const * orig, 
Buffer * buffer, string const  format)
 {
-   bool(Buffer::* mem_func)(std::string const , bool) const = 
Buffer::preview;
-   return runAndDestroy(bind(mem_func, buffer, _1, _2), orig, buffer, 
format, preview);
+   bool const update_unincluded =
+   buffer-params().maintain_unincluded_children
+
!buffer-params().getIncludedChildren().empty();
+   bool const success = buffer-preview(format, update_unincluded);
+   delete buffer;
+   busyBuffers.remove(orig);
+   return success
+   ? bformat(_(Successful preview of format: %1$s), 
from_utf8(format))
+   : bformat(_(Error previewing format: %1$s), 
from_utf8(format));
 }
 #endif
 
@@ -2936,14 +2944,7 @@
dispatch(FuncRequest(LFUN_DIALOG_SHOW, 
sendto), dr);
break;
}
-#if 0
-   // 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Abdelrazak Younes]

On 20/10/2010 13:51, Richard Heck wrote:

On 10/20/2010 04:37 AM, 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 don't know enough about this to know if this is a silly idea or not, 
but I'll mention it anyway.


The dialogs we are discussing are all of the frontend::Alert variety. 
Indeed, unless I am mistaken, those are the only dialogs we create 
from the core. Is there any way we could encapsulate the needed logic 
there?


whenever in a thread frontend::Alert could send a signal that would be 
caught by GuiView in the main thread. Once sent the thread would sleep 
up until it receives a signal from GuiView. Upon reception of the 
signal, GuiView would execute the required Alert dialog and send a 
signal when done. Should be doable without much work...


Abdel.

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 04:24 PM, Abdelrazak Younes wrote:

On 20/10/2010 13:51, Richard Heck wrote:


I don't know enough about this to know if this is a silly idea or 
not, but I'll mention it anyway.


The dialogs we are discussing are all of the frontend::Alert variety. 
Indeed, unless I am mistaken, those are the only dialogs we create 
from the core. Is there any way we could encapsulate the needed logic 
there?


Whenever in a thread frontend::Alert could send a signal that would be 
caught by GuiView in the main thread. Once sent the thread would sleep 
up until it receives a signal from GuiView. Upon reception of the 
signal, GuiView would execute the required Alert dialog and send a 
signal when done. Should be doable without much work...


Well, perhaps someone can try to implement this kind of idea. I have no 
idea myself how to do any of it. Threads are beyond my level of 
competence, I'm afraid.


rh

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

 whenever in a thread frontend::Alert could send a signal that would be 
 caught by GuiView in the main thread. Once sent the thread would sleep 
 up until it receives a signal from GuiView. Upon reception of the 
 signal, GuiView would execute the required Alert dialog and send a 
 signal when done. Should be doable without much work...
 
 Abdel.

I added a helper class to ensure a function (atm no-member only)
is called in the gui-thread.

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

On 20.10.2010 14:02, Richard Heck wrote:
 On 10/20/2010 05:44 AM, Pavel Sanda wrote:
 Peter Kümmel wrote:

 I agree. But this would mean that all dialog related code must be
 removed from the export functions... which would be a good thing in
 itself but is a bit more involved than what was originally thought.

 The box is open again ;)
  
 ouch. is there easy way to switch back or would it mean revert the whole
 serie of patches?


 Some of the early ones were just cleanup, and export code itself is in 
 an #if 0 block,

Yes this if disables the old code, but the other multit hreaded code
would stay enabled.

But I hope we could use the new functionality.


 so it shouldn't be that bad. Maybe it would be worth reverting r35726. 
 To answer
 Peter's question, in the log, I'm not sure that is better. If we go back 

At least the patch removes the copypaste code.

 to before that,
 then it's fairly easy.
 
 The attached patch should do it.
 
 Richard
 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 08:33 PM, Peter Kümmel wrote:

On 20.10.2010 14:02, Richard Heck wrote:
   

On 10/20/2010 05:44 AM, Pavel Sanda wrote:
 

Peter Kümmel wrote:

   

I agree. But this would mean that all dialog related code must be
removed from the export functions... which would be a good thing in
itself but is a bit more involved than what was originally thought.

   

The box is open again ;)

 

ouch. is there easy way to switch back or would it mean revert the whole
serie of patches?


   

Some of the early ones were just cleanup, and export code itself is in
an #if 0 block,
 

Yes this if disables the old code, but the other multit hreaded code
would stay enabled.

But I hope we could use the new functionality.

   
Yes, that's what I had hoped to do. But perhaps your latest commit will 
enable us to evade the existing problem? Unfortunately, I do not really 
understand what it does. We are at the limit of what I understand about 
Qt, etc.



so it shouldn't be that bad. Maybe it would be worth reverting r35726.
To answer
Peter's question, in the log, I'm not sure that is better. If we go back
 

At least the patch removes the copypaste code.

   

Yes, I was trying to preserve that, for sure.

rh

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Dienstag, den 19.10.2010, 20:40 -0400 schrieb Richard Heck: 
 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:

Could you check if it still crashes?

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Julien Rioux]

On 20/10/2010 8:16 PM, Peter Kümmel wrote:



whenever in a thread frontend::Alert could send a signal that would be
caught by GuiView in the main thread. Once sent the thread would sleep
up until it receives a signal from GuiView. Upon reception of the
signal, GuiView would execute the required Alert dialog and send a
signal when done. Should be doable without much work...

Abdel.


I added a helper class to ensure a function (atm no-member only)
is called in the gui-thread.

Peter



svn does not compile anymore for me under ubuntu with 
autogen/configure/make. Could it be that you have edited the wrong 
Makefile.am?


I get
make[5]: Entering directory `/svn/lyx-devel/src/support'
make[5]: *** No rule to make target `InGuiThread.o', needed by 
`liblyxsupport.a'.  Stop.


You have added
Asrc/frontends/qt4/InGuiThread.h
Asrc/frontends/qt4/InGuiThread.cpp

and modified
Usrc/support/Makefile.am

Regards,
Julien

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kuemmel]

  
  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 euro;/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kuemmel]

 You have added
 Asrc/frontends/qt4/InGuiThread.h
 Asrc/frontends/qt4/InGuiThread.cpp
 
 and modified
 Usrc/support/Makefile.am
 
 Regards,
 Julien
 

You are right, I've not updated the .am files when moving the files.
It's fixed (but not tested)  now.

Peter
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Julien Rioux]

On 20/10/2010 9:17 PM, Peter Kuemmel wrote:

You are right, I've not updated the .am files when moving the files.
It's fixed (but not tested)  now.

Peter


It compiles, thanks!
--
Julien

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Andre Poenitz]

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.

Andre'

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Abdelrazak Younes]

On 10/20/2010 10:37 AM, 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 agree. But this would mean that all dialog related code must be 
removed from the export functions... which would be a good thing in 
itself but is a bit more involved than what was originally thought.


Abdel.

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Andre Poenitz]

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' 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

> 
> I agree. But this would mean that all dialog related code must be 
> removed from the export functions... which would be a good thing in 
> itself but is a bit more involved than what was originally thought.

The "box" is open again ;)

> 
> Abdel.
> 
> 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Peter Kümmel wrote:
> > 
> > I agree. But this would mean that all dialog related code must be 
> > removed from the export functions... which would be a good thing in 
> > itself but is a bit more involved than what was originally thought.
> 
> The "box" is open again ;)

ouch. is there easy way to switch back or would it mean revert the whole
serie of patches?

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Enrico Forestieri]

On Wed, Oct 20, 2010 at 11:00:46AM +0200, Andre Poenitz wrote:
> 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();
> }
> 

It is a bit more complicated than that. For example, if you export to
latex, every bitmap graphics is converted to eps and, if an eps with
same name exists, LyX tries to popup a dialog for overwrite confirmation.
The moral is that a change like this should be first well thought and
designed, instead of throwing it there and then trying to solve the
problems that will inevitably arise.

-- 
Enrico

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 04:37 AM, 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 don't know enough about this to know if this is a silly idea or not, 
but I'll mention it anyway.


The dialogs we are discussing are all of the frontend::Alert variety. 
Indeed, unless I am mistaken, those are the only dialogs we create from 
the core. Is there any way we could encapsulate the needed logic there?


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 04:37 AM, 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 don't know enough about this to know if this is a silly idea or not, 
but I'll mention it anyway.


The dialogs we are discussing are all of the frontend::Alert variety. 
Indeed, unless I am mistaken, those are the only dialogs we create from 
the core. Is there any way we could encapsulate the needed logic there?


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 05:44 AM, Pavel Sanda wrote:

Peter Kümmel wrote:
   

I agree. But this would mean that all dialog related code must be
removed from the export functions... which would be a good thing in
itself but is a bit more involved than what was originally thought.
   

The "box" is open again ;)
 

ouch. is there easy way to switch back or would it mean revert the whole
serie of patches?

   
Some of the early ones were just cleanup, and export code itself is in 
an #if 0 block,
so it shouldn't be that bad. Maybe it would be worth reverting r35726. 
To answer
Peter's question, in the log, I'm not sure that is better. If we go back 
to before that,

then it's fairly easy.

The attached patch should do it.

Richard

Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp   (revision 35728)
+++ src/frontends/qt4/GuiView.cpp   (working copy)
@@ -370,9 +370,6 @@
static docstring compileAndDestroy(Buffer const * orig, Buffer * 
buffer, string const & format);
static docstring saveAndDestroy(Buffer const * orig, Buffer * buffer, 
FileName const & fname);
 
-   template
-   static docstring runAndDestroy(const T& func, Buffer const * orig, 
Buffer * buffer, string const & format, string const & msg);
-   
// TODO syncFunc/previewFunc: use bind
bool asyncBufferProcessing(string const & argument,
   Buffer const * used_buffer,
@@ -2818,37 +2815,48 @@
 
 
 #if (QT_VERSION >= 0x040400)
-template
-docstring GuiView::GuiViewPrivate::runAndDestroy(const T& func, Buffer const * 
orig, Buffer * buffer, string const & format, string const & msg)
+docstring GuiView::GuiViewPrivate::compileAndDestroy(Buffer const * orig, 
Buffer * buffer, string const & format)
 {
bool const update_unincluded =
buffer->params().maintain_unincluded_children
&& 
!buffer->params().getIncludedChildren().empty();
-   bool const success = func(format, update_unincluded);
+   bool const success = buffer->doExport(format, true, update_unincluded);
delete buffer;
busyBuffers.remove(orig);
return success
-   ? bformat(_("Successful " + msg + " to format: %1$s"), 
from_utf8(format))
-   : bformat(_("Error " + msg + " format: %1$s"), 
from_utf8(format));
+   ? bformat(_("Successful compilation to format: %1$s"), 
from_utf8(format))
+   : bformat(_("Error compiling format: %1$s"), from_utf8(format));
 }
 
-docstring GuiView::GuiViewPrivate::compileAndDestroy(Buffer const * orig, 
Buffer * buffer, string const & format)
-{
-   bool (Buffer::* mem_func)(std::string const &, bool, bool) const = 
::doExport;
-   return runAndDestroy(bind(mem_func, buffer, _1, true, _2), orig, 
buffer, format, "export");
-}
-
+#if 0
+/// Asynchronous export runs into problems with the  creation of
+/// dialogs from the export thread:
+/// http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg162502.html
 docstring GuiView::GuiViewPrivate::exportAndDestroy(Buffer const * orig, 
Buffer * buffer, string const & format)
 {
-   bool (Buffer::* mem_func)(std::string const &, bool, bool) const = 
::doExport;
-   return runAndDestroy(bind(mem_func, buffer, _1, false, _2), orig, 
buffer, format, "export");
-
+   bool const update_unincluded =
+   buffer->params().maintain_unincluded_children
+   && 
!buffer->params().getIncludedChildren().empty();
+   bool const success = buffer->doExport(format, false, update_unincluded);
+   delete buffer;
+   busyBuffers.remove(orig);
+   return success
+   ? bformat(_("Successful export to format: %1$s"), 
from_utf8(format))
+   : bformat(_("Error exporting to format: %1$s"), 
from_utf8(format));
 }
+#endif
 
 docstring GuiView::GuiViewPrivate::previewAndDestroy(Buffer const * orig, 
Buffer * buffer, string const & format)
 {
-   bool(Buffer::* mem_func)(std::string const &, bool) const = 
::preview;
-   return runAndDestroy(bind(mem_func, buffer, _1, _2), orig, buffer, 
format, "preview");
+   bool const update_unincluded =
+   buffer->params().maintain_unincluded_children
+   && 
!buffer->params().getIncludedChildren().empty();
+   bool const success = buffer->preview(format, update_unincluded);
+   delete buffer;
+   busyBuffers.remove(orig);
+   return success
+   ? bformat(_("Successful preview of format: %1$s"), 
from_utf8(format))
+   : bformat(_("Error previewing format: %1$s"), 
from_utf8(format));
 }
 #endif
 
@@ -2936,14 +2944,7 @@
dispatch(FuncRequest(LFUN_DIALOG_SHOW, 
"sendto"), dr);
break;
}
-#if 0

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Abdelrazak Younes]

On 20/10/2010 13:51, Richard Heck wrote:

On 10/20/2010 04:37 AM, 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 don't know enough about this to know if this is a silly idea or not, 
but I'll mention it anyway.


The dialogs we are discussing are all of the frontend::Alert variety. 
Indeed, unless I am mistaken, those are the only dialogs we create 
from the core. Is there any way we could encapsulate the needed logic 
there?


whenever in a thread frontend::Alert could send a signal that would be 
caught by GuiView in the main thread. Once sent the thread would sleep 
up until it receives a signal from GuiView. Upon reception of the 
signal, GuiView would execute the required Alert dialog and send a 
signal when done. Should be doable without much work...


Abdel.

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 04:24 PM, Abdelrazak Younes wrote:

On 20/10/2010 13:51, Richard Heck wrote:


I don't know enough about this to know if this is a silly idea or 
not, but I'll mention it anyway.


The dialogs we are discussing are all of the frontend::Alert variety. 
Indeed, unless I am mistaken, those are the only dialogs we create 
from the core. Is there any way we could encapsulate the needed logic 
there?


Whenever in a thread frontend::Alert could send a signal that would be 
caught by GuiView in the main thread. Once sent the thread would sleep 
up until it receives a signal from GuiView. Upon reception of the 
signal, GuiView would execute the required Alert dialog and send a 
signal when done. Should be doable without much work...


Well, perhaps someone can try to implement this kind of idea. I have no 
idea myself how to do any of it. Threads are beyond my level of 
competence, I'm afraid.


rh

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

> whenever in a thread frontend::Alert could send a signal that would be 
> caught by GuiView in the main thread. Once sent the thread would sleep 
> up until it receives a signal from GuiView. Upon reception of the 
> signal, GuiView would execute the required Alert dialog and send a 
> signal when done. Should be doable without much work...
> 
> Abdel.

I added a helper class to ensure a function (atm no-member only)
is called in the gui-thread.

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

On 20.10.2010 14:02, Richard Heck wrote:
> On 10/20/2010 05:44 AM, Pavel Sanda wrote:
>> Peter Kümmel wrote:
>>
 I agree. But this would mean that all dialog related code must be
 removed from the export functions... which would be a good thing in
 itself but is a bit more involved than what was originally thought.

>>> The "box" is open again ;)
>>>  
>> ouch. is there easy way to switch back or would it mean revert the whole
>> serie of patches?
>>
>>
> Some of the early ones were just cleanup, and export code itself is in 
> an #if 0 block,

Yes this if disables the old code, but the other multit hreaded code
would stay enabled.

But I hope we could use the new functionality.


> so it shouldn't be that bad. Maybe it would be worth reverting r35726. 
> To answer
> Peter's question, in the log, I'm not sure that is better. If we go back 

At least the patch removes the copy code.

> to before that,
> then it's fairly easy.
> 
> The attached patch should do it.
> 
> Richard
> 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/20/2010 08:33 PM, Peter Kümmel wrote:

On 20.10.2010 14:02, Richard Heck wrote:
   

On 10/20/2010 05:44 AM, Pavel Sanda wrote:
 

Peter Kümmel wrote:

   

I agree. But this would mean that all dialog related code must be
removed from the export functions... which would be a good thing in
itself but is a bit more involved than what was originally thought.

   

The "box" is open again ;)

 

ouch. is there easy way to switch back or would it mean revert the whole
serie of patches?


   

Some of the early ones were just cleanup, and export code itself is in
an #if 0 block,
 

Yes this if disables the old code, but the other multit hreaded code
would stay enabled.

But I hope we could use the new functionality.

   
Yes, that's what I had hoped to do. But perhaps your latest commit will 
enable us to evade the existing problem? Unfortunately, I do not really 
understand what it does. We are at the limit of what I understand about 
Qt, etc.



so it shouldn't be that bad. Maybe it would be worth reverting r35726.
To answer
Peter's question, in the log, I'm not sure that is better. If we go back
 

At least the patch removes the copy code.

   

Yes, I was trying to preserve that, for sure.

rh

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Dienstag, den 19.10.2010, 20:40 -0400 schrieb Richard Heck: 
> 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:

Could you check if it still crashes?

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Julien Rioux]

On 20/10/2010 8:16 PM, Peter Kümmel wrote:



whenever in a thread frontend::Alert could send a signal that would be
caught by GuiView in the main thread. Once sent the thread would sleep
up until it receives a signal from GuiView. Upon reception of the
signal, GuiView would execute the required Alert dialog and send a
signal when done. Should be doable without much work...

Abdel.


I added a helper class to ensure a function (atm no-member only)
is called in the gui-thread.

Peter



svn does not compile anymore for me under ubuntu with 
autogen/configure/make. Could it be that you have edited the wrong 
Makefile.am?


I get
make[5]: Entering directory `/svn/lyx-devel/src/support'
make[5]: *** No rule to make target `InGuiThread.o', needed by 
`liblyxsupport.a'.  Stop.


You have added
Asrc/frontends/qt4/InGuiThread.h
Asrc/frontends/qt4/InGuiThread.cpp

and modified
Usrc/support/Makefile.am

Regards,
Julien

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kuemmel]

> > 
> > 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

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kuemmel]

> You have added
> Asrc/frontends/qt4/InGuiThread.h
> Asrc/frontends/qt4/InGuiThread.cpp
> 
> and modified
> Usrc/support/Makefile.am
> 
> Regards,
> Julien
> 

You are right, I've not updated the .am files when moving the files.
It's fixed (but not tested)  now.

Peter
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Julien Rioux]

On 20/10/2010 9:17 PM, Peter Kuemmel wrote:

You are right, I've not updated the .am files when moving the files.
It's fixed (but not tested)  now.

Peter


It compiles, thanks!
--
Julien

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

On 19.10.2010 00:05, Uwe Stöhr wrote:
   OK, committed a fix, but it needs testing.
 
 Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide 
 to PDF (pdflatex).

Maybe the pdf is now in the temp folder. Because the only difference I see is a 
flag
in doExport.

 
 regards Uwe
 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

On 19.10.2010 08:42, Peter Kümmel wrote:
 On 19.10.2010 00:05, Uwe Stöhr wrote:
   OK, committed a fix, but it needs testing.

 Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide 
 to PDF (pdflatex).
 
 Maybe the pdf is now in the temp folder. Because the only difference I see is 
 a flag
 in doExport.
 

Yes, it's in lyx's temp folder. But shouldn't we ask where to write to the 
exported file?

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Peter Kümmel wrote:
 On 19.10.2010 08:42, Peter Kümmel wrote:
  On 19.10.2010 00:05, Uwe Stöhr wrote:
OK, committed a fix, but it needs testing.
 
  Now exporting is broken: I don't get a PDF when e.g. exporting the 
  UserGuide to PDF (pdflatex).
  
  Maybe the pdf is now in the temp folder. Because the only difference I see 
  is a flag
  in doExport.
  
 
 Yes, it's in lyx's temp folder. But shouldn't we ask where to write to the 
 exported file?

this is already enh request for commandline. but by default we should put the 
result next to the
original .lyx file as we do now.
pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/19/2010 09:12 AM, Pavel Sanda wrote:

Peter Kümmel wrote:
   

On 19.10.2010 08:42, Peter Kümmel wrote:
 

On 19.10.2010 00:05, Uwe Stöhr wrote:
   

OK, committed a fix, but it needs testing.

Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide to 
PDF (pdflatex).
 

Maybe the pdf is now in the temp folder. Because the only difference I see is a 
flag
in doExport.

   

Yes, it's in lyx's temp folder. But shouldn't we ask where to write to the 
exported file?
 
   
Please try it now, after r. This is cut and paste and so not as elegant 
as it could be, but perhaps someone else could use bind to make it work 
better. The main issue is that exportAndDestroy was calling:

buffer-doExport(format, true, update_unincluded);
The second argument is a boolean which means: Should we leave this is in 
the tempdir? So we need false there in the case of EXPORT.


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Uwe Stöhr]

When exporting I get now tons of this message in the LyX console:

QObject::startTimer: timers cannot be started from another thread
QApplication: Object event filter cannot be in a different thread.

When I first view a file (the Math manual) and then export it subsequently, I 
also get this:

QObject::setParent: Cannot set parent, new parent is in a different thread

regards Uwe

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/19/2010 04:32 PM, Uwe Stöhr wrote:

When exporting I get now tons of this message in the LyX console:

QObject::startTimer: timers cannot be started from another thread
QApplication: Object event filter cannot be in a different thread.

When I first view a file (the Math manual) and then export it 
subsequently, I also get this:


QObject::setParent: Cannot set parent, new parent is in a different 
thread


I know why this is, I think: LyX wants to ask you if it's OK to 
overwrite a file. I see no problems when exporting the first time, but 
these kinds of messages when exporting a second time. Seems like a 
fairly serious issue, and one I have no idea how to solve. Maybe someone 
else does.


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Dienstag, den 19.10.2010, 17:32 -0400 schrieb Richard Heck:
 On 10/19/2010 04:32 PM, Uwe Stöhr wrote:
  When exporting I get now tons of this message in the LyX console:
 
  QObject::startTimer: timers cannot be started from another thread
  QApplication: Object event filter cannot be in a different thread.
 
  When I first view a file (the Math manual) and then export it 
  subsequently, I also get this:
 
  QObject::setParent: Cannot set parent, new parent is in a different 
  thread
 
 I know why this is, I think: LyX wants to ask you if it's OK to 
 overwrite a file. I see no problems when exporting the first time, but 
 these kinds of messages when exporting a second time. Seems like a 
 fairly serious issue, and one I have no idea how to solve. Maybe someone 
 else does.

Exporting is now done in its own thread what is the reason for all the
warnings. 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/19/2010 07:08 PM, Peter Kümmel wrote:

Am Dienstag, den 19.10.2010, 17:32 -0400 schrieb Richard Heck:
   

On 10/19/2010 04:32 PM, Uwe Stöhr wrote:
 

When exporting I get now tons of this message in the LyX console:

QObject::startTimer: timers cannot be started from another thread
QApplication: Object event filter cannot be in a different thread.

When I first view a file (the Math manual) and then export it
subsequently, I also get this:

QObject::setParent: Cannot set parent, new parent is in a different
thread

   

I know why this is, I think: LyX wants to ask you if it's OK to
overwrite a file. I see no problems when exporting the first time, but
these kinds of messages when exporting a second time. Seems like a
fairly serious issue, and one I have no idea how to solve. Maybe someone
else does.
 

Exporting is now done in its own thread what is the reason for all the
warnings.

   
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:


0raiseraise.c640x003442e326c5
1abortabort.c920x003442e33ea5
2__assert_failassert.c810x003442e2b7b5
3??/usr/lib64/libX11.so.600x003444e4d02e
4_XReply/usr/lib64/libX11.so.600x003444e4d580
5XGetWindowProperty/usr/lib64/libX11.so.60
0x003444e2a437

6XGetWMHints/usr/lib64/libX11.so.600x003444e2954c
7QWidgetPrivate::setWindowIcon_sysqwidget_x11.cpp1511
0x00313be398fc

8QWidget::createqwidget.cpp13550x00313bdf77dc
9QWidget::setVisibleqwidget.cpp73790x00313bdfc636
10QDialog::setVisibleqdialog.cpp7320x00313c22d60c
11showqwidget.h4850x00313c22cb75
12QDialog::execqdialog.cpp5370x00313c22cb75
13lyx::frontend::Alert::promptGuiAlert.cpp171
0x009728f0


14checkOverwriteExporter.cpp510x0053460e
15lyx::copyFileExporter.cpp800x0053460e
16lyx::Buffer::doExportBuffer.cpp35120x00498770
17lyx::Buffer::doExportBuffer.cpp35350x00498e4d
18lyx::frontend::GuiView::GuiViewPrivate::exportAndDestroy
GuiView.cpp28370x0099f022
19QtConcurrent::StoredFunctorCall3std::basic_stringwchar_t, 
std::char_traitswchar_t, std::allocatorwchar_t , 
std::basic_stringwchar_t, std::char_traitswchar_t, 
std::allocatorwchar_t  (*)(lyx::Buffer const*, lyx::Buffer*, 
std::basic_stringchar, std::char_traitschar, std::allocatorchar  
const), lyx::Buffer const*, lyx::Buffer*, std::basic_stringchar, 
std::char_traitschar, std::allocatorchar  ::runFunctor()
00x009bce01
20QtConcurrent::RunFunctionTaskstd::basic_stringwchar_t, 
std::char_traitswchar_t, std::allocatorwchar_t  ::run()
00x009c2128
21QThreadPoolThread::runqthreadpool.cpp106
0x00313aa6822f
22QThreadPrivate::startqthread_unix.cpp248
0x00313aa711b5

23start_threadpthread_create.c2970x003443a06a3a
24cloneclone.S1120x003442ede77d
25??00x

I suppose we must need to pass this message back to the main thread somehow?

We are lucky not to have seen this already. There are calls to 
Alert::error() in doExport, too.


Richard



QObject::setParent: Cannot set parent, new parent is in a different thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPainter::begin: Paint device returned engine == 0, type: 2
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QObject: Cannot create children for a parent that is in a different thread.
(Parent is Oxygen::WidgetStateEngine(0x28b5170), parent's thread is 
QThread(0x280ccd0), current thread is QThread(0x3d57880)

QObject: Cannot create children for a parent that is in a different thread.
(Parent is Oxygen::WidgetStateEngine(0x28b5430), parent's thread is 
QThread(0x280ccd0), current thread is QThread(0x3d57880)

QObject: Cannot create children for a parent that is in a different thread.
(Parent is Oxygen::WidgetStateEngine(0x28b5430), parent's thread is 
QThread(0x280ccd0), current thread is QThread(0x3d57880)

QObject: Cannot create children 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

 
 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?

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

On 19.10.2010 00:05, Uwe Stöhr wrote:
>  > OK, committed a fix, but it needs testing.
> 
> Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide 
> to PDF (pdflatex).

Maybe the pdf is now in the temp folder. Because the only difference I see is a 
flag
in doExport.

> 
> regards Uwe
> 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

On 19.10.2010 08:42, Peter Kümmel wrote:
> On 19.10.2010 00:05, Uwe Stöhr wrote:
>>  > OK, committed a fix, but it needs testing.
>>
>> Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide 
>> to PDF (pdflatex).
> 
> Maybe the pdf is now in the temp folder. Because the only difference I see is 
> a flag
> in doExport.
> 

Yes, it's in lyx's temp folder. But shouldn't we ask where to write to the 
exported file?

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Peter Kümmel wrote:
> On 19.10.2010 08:42, Peter Kümmel wrote:
> > On 19.10.2010 00:05, Uwe Stöhr wrote:
> >>  > OK, committed a fix, but it needs testing.
> >>
> >> Now exporting is broken: I don't get a PDF when e.g. exporting the 
> >> UserGuide to PDF (pdflatex).
> > 
> > Maybe the pdf is now in the temp folder. Because the only difference I see 
> > is a flag
> > in doExport.
> > 
> 
> Yes, it's in lyx's temp folder. But shouldn't we ask where to write to the 
> exported file?

this is already enh request for commandline. but by default we should put the 
result next to the
original .lyx file as we do now.
pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/19/2010 09:12 AM, Pavel Sanda wrote:

Peter Kümmel wrote:
   

On 19.10.2010 08:42, Peter Kümmel wrote:
 

On 19.10.2010 00:05, Uwe Stöhr wrote:
   

  >  OK, committed a fix, but it needs testing.

Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide to 
PDF (pdflatex).
 

Maybe the pdf is now in the temp folder. Because the only difference I see is a 
flag
in doExport.

   

Yes, it's in lyx's temp folder. But shouldn't we ask where to write to the 
exported file?
 
   
Please try it now, after r. This is cut and paste and so not as elegant 
as it could be, but perhaps someone else could use bind to make it work 
better. The main issue is that exportAndDestroy was calling:

buffer->doExport(format, true, update_unincluded);
The second argument is a boolean which means: Should we leave this is in 
the tempdir? So we need false there in the case of EXPORT.


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Uwe Stöhr]

When exporting I get now tons of this message in the LyX console:

QObject::startTimer: timers cannot be started from another thread
QApplication: Object event filter cannot be in a different thread.

When I first view a file (the Math manual) and then export it subsequently, I 
also get this:

QObject::setParent: Cannot set parent, new parent is in a different thread

regards Uwe

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/19/2010 04:32 PM, Uwe Stöhr wrote:

When exporting I get now tons of this message in the LyX console:

QObject::startTimer: timers cannot be started from another thread
QApplication: Object event filter cannot be in a different thread.

When I first view a file (the Math manual) and then export it 
subsequently, I also get this:


QObject::setParent: Cannot set parent, new parent is in a different 
thread


I know why this is, I think: LyX wants to ask you if it's OK to 
overwrite a file. I see no problems when exporting the first time, but 
these kinds of messages when exporting a second time. Seems like a 
fairly serious issue, and one I have no idea how to solve. Maybe someone 
else does.


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Dienstag, den 19.10.2010, 17:32 -0400 schrieb Richard Heck:
> On 10/19/2010 04:32 PM, Uwe Stöhr wrote:
> > When exporting I get now tons of this message in the LyX console:
> >
> > QObject::startTimer: timers cannot be started from another thread
> > QApplication: Object event filter cannot be in a different thread.
> >
> > When I first view a file (the Math manual) and then export it 
> > subsequently, I also get this:
> >
> > QObject::setParent: Cannot set parent, new parent is in a different 
> > thread
> >
> I know why this is, I think: LyX wants to ask you if it's OK to 
> overwrite a file. I see no problems when exporting the first time, but 
> these kinds of messages when exporting a second time. Seems like a 
> fairly serious issue, and one I have no idea how to solve. Maybe someone 
> else does.

Exporting is now done in its own thread what is the reason for all the
warnings. 

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/19/2010 07:08 PM, Peter Kümmel wrote:

Am Dienstag, den 19.10.2010, 17:32 -0400 schrieb Richard Heck:
   

On 10/19/2010 04:32 PM, Uwe Stöhr wrote:
 

When exporting I get now tons of this message in the LyX console:

QObject::startTimer: timers cannot be started from another thread
QApplication: Object event filter cannot be in a different thread.

When I first view a file (the Math manual) and then export it
subsequently, I also get this:

QObject::setParent: Cannot set parent, new parent is in a different
thread

   

I know why this is, I think: LyX wants to ask you if it's OK to
overwrite a file. I see no problems when exporting the first time, but
these kinds of messages when exporting a second time. Seems like a
fairly serious issue, and one I have no idea how to solve. Maybe someone
else does.
 

Exporting is now done in its own thread what is the reason for all the
warnings.

   
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:


0raiseraise.c640x003442e326c5
1abortabort.c920x003442e33ea5
2__assert_failassert.c810x003442e2b7b5
3??/usr/lib64/libX11.so.600x003444e4d02e
4_XReply/usr/lib64/libX11.so.600x003444e4d580
5XGetWindowProperty/usr/lib64/libX11.so.60
0x003444e2a437

6XGetWMHints/usr/lib64/libX11.so.600x003444e2954c
7QWidgetPrivate::setWindowIcon_sysqwidget_x11.cpp1511
0x00313be398fc

8QWidget::createqwidget.cpp13550x00313bdf77dc
9QWidget::setVisibleqwidget.cpp73790x00313bdfc636
10QDialog::setVisibleqdialog.cpp7320x00313c22d60c
11showqwidget.h4850x00313c22cb75
12QDialog::execqdialog.cpp5370x00313c22cb75
13lyx::frontend::Alert::promptGuiAlert.cpp171
0x009728f0


14checkOverwriteExporter.cpp510x0053460e
15lyx::copyFileExporter.cpp800x0053460e
16lyx::Buffer::doExportBuffer.cpp35120x00498770
17lyx::Buffer::doExportBuffer.cpp35350x00498e4d
18lyx::frontend::GuiView::GuiViewPrivate::exportAndDestroy
GuiView.cpp28370x0099f022
19QtConcurrent::StoredFunctorCall3, 
std::basic_string (*)(lyx::Buffer const*, lyx::Buffer*, 
std::basic_string 
const&), lyx::Buffer const*, lyx::Buffer*, std::basic_string >::runFunctor()
00x009bce01
20QtConcurrent::RunFunctionTask >::run()
00x009c2128
21QThreadPoolThread::runqthreadpool.cpp106
0x00313aa6822f
22QThreadPrivate::startqthread_unix.cpp248
0x00313aa711b5

23start_threadpthread_create.c2970x003443a06a3a
24cloneclone.S1120x003442ede77d
25??00x

I suppose we must need to pass this message back to the main thread somehow?

We are lucky not to have seen this already. There are calls to 
Alert::error() in doExport, too.


Richard



QObject::setParent: Cannot set parent, new parent is in a different thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPainter::begin: Paint device returned engine == 0, type: 2
QPixmap: It is not safe to use pixmaps outside the GUI thread
QPixmap: It is not safe to use pixmaps outside the GUI thread
QObject: Cannot create children for a parent that is in a different thread.
(Parent is Oxygen::WidgetStateEngine(0x28b5170), parent's thread is 
QThread(0x280ccd0), current thread is QThread(0x3d57880)

QObject: Cannot create children for a parent that is in a different thread.
(Parent is Oxygen::WidgetStateEngine(0x28b5430), parent's thread is 
QThread(0x280ccd0), current thread is QThread(0x3d57880)

QObject: Cannot create children for a parent that is in a different thread.
(Parent is Oxygen::WidgetStateEngine(0x28b5430), parent's thread is 
QThread(0x280ccd0), current thread is QThread(0x3d57880)

QObject: Cannot create children for a parent that is in a different thread.

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

 
> 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?

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Sonntag, den 17.10.2010, 17:52 -0400 schrieb Richard Heck:
 On 10/17/2010 04:19 PM, Pavel Sanda wrote:
  Peter Kümmel wrote:
 
  #412: Opening the box of QProcess short before a release?
  I don't know if this is a good idea. We had so much problems
  when introducing unblocked texing, so I think we should
  postpone it.
   
  i thought that once we have it for viewing, it might be piece of cake
  to add export. if it means risking the same problems as with
  introducing it on view, then lets postpone it.
 
 
 I think it might be worth trying this.
 
 Viewing is a two step process:
 
 (i) Create the file and its friends in the temporary directory;
 (ii) Launch a viewer on that file.
 
 Exporting is also a two step process:
 
 (i) Create the file and its friends in the temporary directory;
 (ii) Copy the files to their ultimate location.
 
 I could be wrong, but it seems to me that the problems must have lay 
 mostly at (i). But (i) is the same both times.
 
 The fix should be as easy as doing the same thing in LFUN_BUFFER_EXPORT 
 as we do in LFUN_BUFFER_VIEW, in GuiView.cpp.
 
 Richard
 

OK, committed a fix, but it needs testing.

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Uwe Stöhr]

 OK, committed a fix, but it needs testing.

Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide to 
PDF (pdflatex).

regards Uwe

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Sonntag, den 17.10.2010, 17:52 -0400 schrieb Richard Heck:
> On 10/17/2010 04:19 PM, Pavel Sanda wrote:
> > Peter Kümmel wrote:
> >
> >> #412: Opening the box of QProcess short before a release?
> >> I don't know if this is a good idea. We had so much problems
> >> when introducing unblocked texing, so I think we should
> >> postpone it.
> >>  
> > i thought that once we have it for viewing, it might be piece of cake
> > to add export. if it means risking the same problems as with
> > introducing it on view, then lets postpone it.
> >
> >
> I think it might be worth trying this.
> 
> Viewing is a two step process:
> 
> (i) Create the file and its friends in the temporary directory;
> (ii) Launch a viewer on that file.
> 
> Exporting is also a two step process:
> 
> (i) Create the file and its friends in the temporary directory;
> (ii) Copy the files to their ultimate location.
> 
> I could be wrong, but it seems to me that the problems must have lay 
> mostly at (i). But (i) is the same both times.
> 
> The fix should be as easy as doing the same thing in LFUN_BUFFER_EXPORT 
> as we do in LFUN_BUFFER_VIEW, in GuiView.cpp.
> 
> Richard
> 

OK, committed a fix, but it needs testing.

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Uwe Stöhr]

> OK, committed a fix, but it needs testing.

Now exporting is broken: I don't get a PDF when e.g. exporting the UserGuide to 
PDF (pdflatex).

regards Uwe

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

kuem...@lyx.org wrote:
 Author: kuemmel
 Date: Sun Oct 17 12:44:53 2010
 New Revision: 35662
 URL: http://www.lyx.org/trac/changeset/35662
 
 Log:
 Use DispatchResult also in GuiView::dispatchVC to handle messages.
 Make it possible to suppress messages stored in DispatchResult objects.
 BUG: 6417

nice! while you are around, can you look on reopened bug #412?
it this easy target fo 2.0 or should we postpone?

thanks for the previous patch.
pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/17/2010 06:44 AM, kuem...@lyx.org wrote:

Author: kuemmel
Date: Sun Oct 17 12:44:53 2010
New Revision: 35662
URL: http://www.lyx.org/trac/changeset/35662

Log:
Use DispatchResult also in GuiView::dispatchVC to handle messages.
Make it possible to suppress messages stored in DispatchResult objects.
BUG: 6417

   

Thanks, Peter. Good work.

rh

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Sonntag, den 17.10.2010, 18:32 +0200 schrieb Pavel Sanda:
 kuem...@lyx.org wrote:
  Author: kuemmel
  Date: Sun Oct 17 12:44:53 2010
  New Revision: 35662
  URL: http://www.lyx.org/trac/changeset/35662
  
  Log:
  Use DispatchResult also in GuiView::dispatchVC to handle messages.
  Make it possible to suppress messages stored in DispatchResult objects.
  BUG: 6417
 
 nice! while you are around, can you look on reopened bug #412?
 it this easy target fo 2.0 or should we postpone?
 
 thanks for the previous patch.

I'm happy having removed a showstopper ;)

 pavel

#412: Opening the box of QProcess short before a release? 
I don't know if this is a good idea. We had so much problems
when introducing unblocked texing, so I think we should 
postpone it.

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Peter Kümmel wrote:
 #412: Opening the box of QProcess short before a release? 
 I don't know if this is a good idea. We had so much problems
 when introducing unblocked texing, so I think we should 
 postpone it.

i thought that once we have it for viewing, it might be piece of cake
to add export. if it means risking the same problems as with
introducing it on view, then lets postpone it.

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Sonntag, den 17.10.2010, 22:19 +0200 schrieb Pavel Sanda:
 Peter Kümmel wrote:
  #412: Opening the box of QProcess short before a release? 
  I don't know if this is a good idea. We had so much problems
  when introducing unblocked texing, so I think we should 
  postpone it.
 
 i thought that once we have it for viewing, it might be piece of cake
 to add export. if it means risking the same problems as with
 introducing it on view, then lets postpone it.
 
 pavel

I haven't tried it, but who knows...

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/17/2010 04:19 PM, Pavel Sanda wrote:

Peter Kümmel wrote:
   

#412: Opening the box of QProcess short before a release?
I don't know if this is a good idea. We had so much problems
when introducing unblocked texing, so I think we should
postpone it.
 

i thought that once we have it for viewing, it might be piece of cake
to add export. if it means risking the same problems as with
introducing it on view, then lets postpone it.

   

I think it might be worth trying this.

Viewing is a two step process:

(i) Create the file and its friends in the temporary directory;
(ii) Launch a viewer on that file.

Exporting is also a two step process:

(i) Create the file and its friends in the temporary directory;
(ii) Copy the files to their ultimate location.

I could be wrong, but it seems to me that the problems must have lay 
mostly at (i). But (i) is the same both times.


The fix should be as easy as doing the same thing in LFUN_BUFFER_EXPORT 
as we do in LFUN_BUFFER_VIEW, in GuiView.cpp.


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Richard Heck wrote:
 I could be wrong, but it seems to me that the problems must have lay mostly 
 at (i). But (i) is the same both times.

that was my naive view too, haven't seen the code. if its true we can try it,
but this must go soon to have some testing time.

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

kuem...@lyx.org wrote:
> Author: kuemmel
> Date: Sun Oct 17 12:44:53 2010
> New Revision: 35662
> URL: http://www.lyx.org/trac/changeset/35662
> 
> Log:
> Use DispatchResult also in GuiView::dispatchVC to handle messages.
> Make it possible to suppress messages stored in DispatchResult objects.
> BUG: 6417

nice! while you are around, can you look on reopened bug #412?
it this easy target fo 2.0 or should we postpone?

thanks for the previous patch.
pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/17/2010 06:44 AM, kuem...@lyx.org wrote:

Author: kuemmel
Date: Sun Oct 17 12:44:53 2010
New Revision: 35662
URL: http://www.lyx.org/trac/changeset/35662

Log:
Use DispatchResult also in GuiView::dispatchVC to handle messages.
Make it possible to suppress messages stored in DispatchResult objects.
BUG: 6417

   

Thanks, Peter. Good work.

rh

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Sonntag, den 17.10.2010, 18:32 +0200 schrieb Pavel Sanda:
> kuem...@lyx.org wrote:
> > Author: kuemmel
> > Date: Sun Oct 17 12:44:53 2010
> > New Revision: 35662
> > URL: http://www.lyx.org/trac/changeset/35662
> > 
> > Log:
> > Use DispatchResult also in GuiView::dispatchVC to handle messages.
> > Make it possible to suppress messages stored in DispatchResult objects.
> > BUG: 6417
> 
> nice! while you are around, can you look on reopened bug #412?
> it this easy target fo 2.0 or should we postpone?
> 
> thanks for the previous patch.

I'm happy having removed a showstopper ;)

> pavel

#412: Opening the box of QProcess short before a release? 
I don't know if this is a good idea. We had so much problems
when introducing unblocked texing, so I think we should 
postpone it.

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Peter Kümmel wrote:
> #412: Opening the box of QProcess short before a release? 
> I don't know if this is a good idea. We had so much problems
> when introducing unblocked texing, so I think we should 
> postpone it.

i thought that once we have it for viewing, it might be piece of cake
to add export. if it means risking the same problems as with
introducing it on view, then lets postpone it.

pavel

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Peter Kümmel]

Am Sonntag, den 17.10.2010, 22:19 +0200 schrieb Pavel Sanda:
> Peter Kümmel wrote:
> > #412: Opening the box of QProcess short before a release? 
> > I don't know if this is a good idea. We had so much problems
> > when introducing unblocked texing, so I think we should 
> > postpone it.
> 
> i thought that once we have it for viewing, it might be piece of cake
> to add export. if it means risking the same problems as with
> introducing it on view, then lets postpone it.
> 
> pavel

I haven't tried it, but who knows...

Peter

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Richard Heck]

On 10/17/2010 04:19 PM, Pavel Sanda wrote:

Peter Kümmel wrote:
   

#412: Opening the box of QProcess short before a release?
I don't know if this is a good idea. We had so much problems
when introducing unblocked texing, so I think we should
postpone it.
 

i thought that once we have it for viewing, it might be piece of cake
to add export. if it means risking the same problems as with
introducing it on view, then lets postpone it.

   

I think it might be worth trying this.

Viewing is a two step process:

(i) Create the file and its friends in the temporary directory;
(ii) Launch a viewer on that file.

Exporting is also a two step process:

(i) Create the file and its friends in the temporary directory;
(ii) Copy the files to their ultimate location.

I could be wrong, but it seems to me that the problems must have lay 
mostly at (i). But (i) is the same both times.


The fix should be as easy as doing the same thing in LFUN_BUFFER_EXPORT 
as we do in LFUN_BUFFER_VIEW, in GuiView.cpp.


Richard

Re: r35662 - in lyx-devel/trunk/src: . frontends/qt4

[Pavel Sanda]

Richard Heck wrote:
> I could be wrong, but it seems to me that the problems must have lay mostly 
> at (i). But (i) is the same both times.

that was my naive view too, haven't seen the code. if its true we can try it,
but this must go soon to have some testing time.

pavel