Am Tuesday 22 December 2009 schrieb Peter Kümmel:
> Kornel Benko wrote:
> > /usr/src/lyx/lyx-devel/src/frontends/qt4/GuiView.cpp:278: error:
> > ‘preview_watcher_’ was not
>
> Could you try it again?
>
> Peter
>
>
Perfect. No compile-problems now.
Kornel
signature.asc
Description:
Kornel Benko wrote:
> /usr/src/lyx/lyx-devel/src/frontends/qt4/GuiView.cpp:278: error:
> ‘preview_watcher_’ was not
Could you try it again?
Peter
Peter Kümmel wrote:
> Pavel Sanda wrote:
> > Peter Kümmel wrote:
> >> But I've removed the dialog, because ATM we don't have to
> >> show anything interesting. Latex is running in batch mode.
> >
> > i hoped we could duplicate the terminal output into this dock widget
> > and i even intended to ad
Pavel Sanda wrote:
> Peter Kümmel wrote:
>> But I've removed the dialog, because ATM we don't have to
>> show anything interesting. Latex is running in batch mode.
>
> i hoped we could duplicate the terminal output into this dock widget
> and i even intended to add more capabilities for debug outp
Am Tuesday 22 December 2009 schrieb Peter Kümmel:
> Kornel Benko wrote:
> > Am Monday 21 December 2009 schrieb BH:
> >> On Mon, Dec 21, 2009 at 10:08 AM, Vincent van Ravesteijn - TNW
> >> wrote:
> >> Right now I can't compile:
> >>
> > Can you compile now ?
> Not quite. (I should
Kornel Benko wrote:
> Am Monday 21 December 2009 schrieb BH:
>> On Mon, Dec 21, 2009 at 10:08 AM, Vincent van Ravesteijn - TNW
>> wrote:
>> Right now I can't compile:
>>
> Can you compile now ?
Not quite. (I should have run make -k before.)
>>> And now ?
>> Perfect -- thanks!
Am Monday 21 December 2009 schrieb BH:
> On Mon, Dec 21, 2009 at 10:08 AM, Vincent van Ravesteijn - TNW
> wrote:
> >
> Right now I can't compile:
>
> >>>
> >>> Can you compile now ?
> >>
> >>Not quite. (I should have run make -k before.)
> >>
> >
> > And now ?
>
> Perfect -- thanks!
>
>
Peter Kümmel wrote:
> But I've removed the dialog, because ATM we don't have to
> show anything interesting. Latex is running in batch mode.
i hoped we could duplicate the terminal output into this dock widget
and i even intended to add more capabilities for debug output
fine tuning. could we ree
> > And then continuous update on each buffer change.
> >
>
> I tried that on linux and it is bearable but crashy... This is on a 2
> year old laptop running Ubuntu 9.10.
Isn't that bad on Linux with attached patch. We have to drop updates
when the update is still busy.
>
> On Windows, forg
Peter Kümmel wrote:
Am Montag, den 21.12.2009, 14:54 +0100 schrieb Abdelrazak Younes:
Excellent. Now we can also move LFUN_BUFFER_EXPORT to thread. We just
need a new argument to exportAndDestroy() AFAIR. I mean... if you want
to do some more work on this ;-)
And then continuous updat
Peter Kümmel wrote:
Am Montag, den 21.12.2009, 14:54 +0100 schrieb Abdelrazak Younes:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
2) Use the same signal/slot mechanism for Buffer::message().
Done,
http://www.lyx.org/trac/changeset/32606/lyx-devel/trunk
Am Montag, den 21.12.2009, 14:54 +0100 schrieb Abdelrazak Younes:
> Excellent. Now we can also move LFUN_BUFFER_EXPORT to thread. We just
> need a new argument to exportAndDestroy() AFAIR. I mean... if you want
> to do some more work on this ;-)
And then continuous update on each buffer change.
Am Montag, den 21.12.2009, 14:54 +0100 schrieb Abdelrazak Younes:
> Peter Kümmel wrote:
> > Abdelrazak Younes wrote:
> >
> >> 2) Use the same signal/slot mechanism for Buffer::message().
> >>
> >
> > Done,
> > http://www.lyx.org/trac/changeset/32606/lyx-devel/trunk
> >
>
> Excellent. No
On Mon, Dec 21, 2009 at 10:08 AM, Vincent van Ravesteijn - TNW
wrote:
>
Right now I can't compile:
>>>
>>> Can you compile now ?
>>
>>Not quite. (I should have run make -k before.)
>>
>
> And now ?
Perfect -- thanks!
BH
>>>Right now I can't compile:
>>>
>>
>> Can you compile now ?
>
>Not quite. (I should have run make -k before.)
>
And now ?
Vincent
On Mon, Dec 21, 2009 at 9:55 AM, Vincent van Ravesteijn - TNW
wrote:
>>Right now I can't compile:
>>
>
> Can you compile now ?
Not quite. (I should have run make -k before.)
Here's one more:
GuiView.cpp: In member function ‘virtual bool
lyx::frontend::GuiView::dispatch(const lyx::FuncRequest&)’
>Right now I can't compile:
>
Can you compile now ?
Vincent
On Mon, Dec 21, 2009 at 6:56 AM, Peter Kümmel wrote:
> Statusbar is now updated ehith the progress information.
> But I've removed the dialog, because ATM we don't have to
> show anything interesting. Latex is running in batch mode.
Right now I can't compile:
GuiProgress.cpp: In member function
Peter Kümmel wrote:
Abdelrazak Younes wrote:
2) Use the same signal/slot mechanism for Buffer::message().
Done,
http://www.lyx.org/trac/changeset/32606/lyx-devel/trunk
Excellent. Now we can also move LFUN_BUFFER_EXPORT to thread. We just
need a new argument to exportAndDestroy()
Abdelrazak Younes wrote:
> 2) Use the same signal/slot mechanism for Buffer::message().
Done,
http://www.lyx.org/trac/changeset/32606/lyx-devel/trunk
Peter
Abdelrazak Younes wrote:
> On 20/12/2009 17:34, Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>
>>> 1) Replace all call to Alert::warning() related to some Buffer action
>>> with a new Buffer::warning() method that will use the GuiDelegate to
>>> send the warning to the GUI even when we are
BH wrote:
> On Sun, Dec 20, 2009 at 11:23 AM, Peter Kümmel wrote:
>> Peter Kümmel wrote:
>>> Pavel Sanda wrote:
Peter Kümmel wrote:
> If it's really needed I could move it to trunk, would not be very
> complicated.
yes it would be nice to have it. i even imagine line of checkbox
On Sun, Dec 20, 2009 at 11:23 AM, Peter Kümmel wrote:
> Peter Kümmel wrote:
>> Pavel Sanda wrote:
>>> Peter Kümmel wrote:
If it's really needed I could move it to trunk, would not be very
complicated.
>>> yes it would be nice to have it. i even imagine line of checkboxes on the
>>> top
On 20/12/2009 17:34, Peter Kümmel wrote:
Abdelrazak Younes wrote:
1) Replace all call to Alert::warning() related to some Buffer action
with a new Buffer::warning() method that will use the GuiDelegate to
send the warning to the GUI even when we are in another thread. This is
because new wid
Abdelrazak Younes wrote:
> 1) Replace all call to Alert::warning() related to some Buffer action
> with a new Buffer::warning() method that will use the GuiDelegate to
> send the warning to the GUI even when we are in another thread. This is
> because new widget cannot be created from another th
Peter Kümmel wrote:
> Pavel Sanda wrote:
>> Peter Kümmel wrote:
>>> If it's really needed I could move it to trunk, would not be very
>>> complicated.
>> yes it would be nice to have it. i even imagine line of checkboxes on the top
>> each for one debug level to toggle - that would be quite useful
Pavel Sanda wrote:
> Peter Kümmel wrote:
>> If it's really needed I could move it to trunk, would not be very
>> complicated.
>
> yes it would be nice to have it. i even imagine line of checkboxes on the top
> each for one debug level to toggle - that would be quite useful for debugging
> purpose
Abdelrazak Younes wrote:
> On 19/12/2009 12:43, Peter Kümmel wrote:
>>> I implemented that approach now in trunk. But by cloning the Buffer as
>>> this was the cleanest approach and less intrusive approach. It works
>>> well except for the lack of feedback on the background processing.
>>>
>>> Abde
Vincent van Ravesteijn wrote:
>> When I change the function parameter for format from docstring to
>> std:string I get linker errors with mavc, because of missing
>> previewAndDestroy and exportAndDestroy, stange.
>> Thereforethe from_utf8 function.
>>
>> Peter
>>
>>
> I can just change the form
Abdelrazak Younes wrote:
>> No not here. Would this patch be OK?
>>
>
> Yes, my bad.
Any ideas why
static docstring exportAndDestroy(Buffer * buffer, std::string const & format)
does not work? Qt without stl support?
Peter
When I change the function parameter for format from docstring to
std:string I get linker errors with mavc, because of missing
previewAndDestroy and exportAndDestroy, stange.
Thereforethe from_utf8 function.
Peter
I can just change the format type to string without any problems (msvc
as we
On 19/12/2009 20:31, Peter Kümmel wrote:
Vincent van Ravesteijn wrote:
But preview is still broken under Windows.
Peter
I didn't fix it ?
Vincent
No not here. Would this patch be OK?
Yes, my bad.
Abdel.
Vincent van Ravesteijn wrote:
>> But preview is still broken under Windows.
>>
>> Peter
>>
>
> I didn't fix it ?
>
> Vincent
>
No not here. Would this patch be OK?
Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/
But preview is still broken under Windows.
Peter
I didn't fix it ?
Vincent
Peter Kümmel wrote:
> If it's really needed I could move it to trunk, would not be very complicated.
yes it would be nice to have it. i even imagine line of checkboxes on the top
each for one debug level to toggle - that would be quite useful for debugging
purposes. also user reports could be more
Pavel Sanda wrote:
> Abdelrazak Younes wrote:
>> 2) Use the same signal/slot mechanism for Buffer::message().
>
> btw in the old process branch there was implemnted new output window for
> console
> messages. how hard it would be to make it work the current trunk? it would be
> good
> to have th
On Sat, Dec 19, 2009 at 02:53:05PM +0100, Pavel Sanda wrote:
> Abdelrazak Younes wrote:
> > On 19/12/2009 12:54, Abdelrazak Younes wrote:
> >> Menu -> view or update (pdflatex or dvi) works fine here (as well as
> >> Ctrl+D or T)
> >
> > Hum, it does not work anymore... latex complain about an em
Abdelrazak Younes schreef:
On 19/12/2009 14:53, Pavel Sanda wrote:
Abdelrazak Younes wrote:
On 19/12/2009 12:54, Abdelrazak Younes wrote:
Menu -> view or update (pdflatex or dvi) works fine here (as well as
Ctrl+D or T)
Hum, it does not work anymore... latex complain about an
On 19/12/2009 14:53, Pavel Sanda wrote:
Abdelrazak Younes wrote:
On 19/12/2009 12:54, Abdelrazak Younes wrote:
Menu -> view or update (pdflatex or dvi) works fine here (as well as
Ctrl+D or T)
Hum, it does not work anymore... latex complain about an empty file...
weird... It
Abdelrazak Younes wrote:
> On 19/12/2009 12:54, Abdelrazak Younes wrote:
>> Menu -> view or update (pdflatex or dvi) works fine here (as well as
>> Ctrl+D or T)
>
> Hum, it does not work anymore... latex complain about an empty file...
> weird... It was working just fine yesterday before I commit
On 19/12/2009 14:18, Abdelrazak Younes wrote:
On 19/12/2009 12:54, Abdelrazak Younes wrote:
Menu -> view or update (pdflatex or dvi) works fine here (as well as
Ctrl+D or T)
Hum, it does not work anymore... latex complain about an empty file...
weird... It was working just fine yesterday befo
On 19/12/2009 12:54, Abdelrazak Younes wrote:
Menu -> view or update (pdflatex or dvi) works fine here (as well as
Ctrl+D or T)
Hum, it does not work anymore... latex complain about an empty file...
weird... It was working just fine yesterday before I commit.
Abdel.
Abdelrazak Younes wrote:
> 2) Use the same signal/slot mechanism for Buffer::message().
btw in the old process branch there was implemnted new output window for console
messages. how hard it would be to make it work the current trunk? it would be
good
to have this for latex output in background a
On 19/12/2009 12:43, Peter Kümmel wrote:
I implemented that approach now in trunk. But by cloning the Buffer as
this was the cleanest approach and less intrusive approach. It works
well except for the lack of feedback on the background processing.
Abdel.
Great, if it works we could remove
> I implemented that approach now in trunk. But by cloning the Buffer as
> this was the cleanest approach and less intrusive approach. It works
> well except for the lack of feedback on the background processing.
>
> Abdel.
Great, if it works we could remove
QCoreApplication::processEvents(QEve
On 10/12/2009 15:43, Abdelrazak Younes wrote:
Pavel Sanda wrote:
Jean-Marc Lasgouttes wrote:
the real work
on our buffer structure can be fast enough IMO.
it is not? pavel
It is, and that is not the problem. The LateX export can happen in
the main thread. The problem is elsewhere in that we
On Fri, Dec 11, 2009 at 10:56 AM, rgheck wrote:
> On 12/11/2009 10:17 AM, Abdelrazak Younes wrote:
>>
>> As far as I understand LaTeX people want to see the context around the
>> current paragraph so the single paragraph mode is not good for them. Maybe
>> we need at least to show one or two paragr
On Fri, Dec 11, 2009 at 03:57:59PM +0100, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes writes:
> > Or maybe our handmade syntax highlighter... Disabling it will for sure
> > make a difference. Also we ask the text edit to reload a big file at
> > each keystroke while we merely paint the current
On Fri, Dec 11, 2009 at 03:24:53PM +0100, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes writes:
> >> One instance where .tex generation does cause a slowdown is with "View
> >> Source" open. While editing a large document with "Complete Source"
> >> checked, LyX can't keep up with my typing sp
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
I just tried without it and it still is slow. So the real bottleneck
seems to be QTextDocument indeed. But as I said, we do a full reload
at each keystroke...
What about QPlainTextEdit instead (qt >= 4.4)?
I just tried, the pe
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
I just tried without it and it still is slow. So the real bottleneck
seems to be QTextDocument indeed. But as I said, we do a full reload
at each keystroke...
What about QPlainTextEdit instead (qt >= 4.4)?
Good idea. Apparentl
Abdelrazak Younes writes:
> I just tried without it and it still is slow. So the real bottleneck
> seems to be QTextDocument indeed. But as I said, we do a full reload
> at each keystroke...
What about QPlainTextEdit instead (qt >= 4.4)?
JMarc
On 12/11/2009 10:17 AM, Abdelrazak Younes wrote:
Pavel Sanda wrote:
Abdelrazak Younes wrote:
a difference. Also we ask the text edit to reload a big file at each
keystroke while we merely paint the current line; not a fair
comparison :-)
i think that it doesn't make sense to have checked ful
Pavel Sanda wrote:
Abdelrazak Younes wrote:
a difference. Also we ask the text edit to reload a big file at each
keystroke while we merely paint the current line; not a fair comparison :-)
i think that it doesn't make sense to have checked full source listing
unless you want to look on
Abdelrazak Younes wrote:
> a difference. Also we ask the text edit to reload a big file at each
> keystroke while we merely paint the current line; not a fair comparison :-)
i think that it doesn't make sense to have checked full source listing
unless you want to look on something in preamble. ha
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
Or maybe our handmade syntax highlighter... Disabling it will for sure
make a difference. Also we ask the text edit to reload a big file at
each keystroke while we merely paint the current line; not a fair
comparison :-)
I have to
Vincent van Ravesteijn - TNW wrote:
This is indeed a good argument in favour of cloning the Buffer.
Nope. I just profiled with sysprof what happens when
typing in UserGuide with LaTeX source shown (with full
source). Conclusions are
* it is painfully slow :)
* 69% of time is spent
>> This is indeed a good argument in favour of cloning the Buffer.
>
>Nope. I just profiled with sysprof what happens when
>typing in UserGuide with LaTeX source shown (with full
>source). Conclusions are
>
> * it is painfully slow :)
>
> * 69% of time is spent in libQtGui itself
>
> * 4.3% of ti
Abdelrazak Younes writes:
> Or maybe our handmade syntax highlighter... Disabling it will for sure
> make a difference. Also we ask the text edit to reload a big file at
> each keystroke while we merely paint the current line; not a fair
> comparison :-)
I have to admit also that this is qt 4.2.
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
One instance where .tex generation does cause a slowdown is with "View
Source" open. While editing a large document with "Complete Source"
checked, LyX can't keep up with my typing speed. This issue is
insidious because the user may no
Abdelrazak Younes writes:
>> One instance where .tex generation does cause a slowdown is with "View
>> Source" open. While editing a large document with "Complete Source"
>> checked, LyX can't keep up with my typing speed. This issue is
>> insidious because the user may not realize that the "Vi
Ben M. wrote:
On Thu, Dec 10, 2009 at 9:45 AM, Jean-Marc Lasgouttes wrote:
Pavel Sanda writes:
Jean-Marc Lasgouttes wrote:
the real work
on our buffer structure can be fast enough IMO.
it is not? pavel
I thought people implied that it was not, but I may be mist
On 2009-12-10, Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Pavel Sanda wrote:
>>> Jean-Marc Lasgouttes wrote:
the real work
on our buffer structure can be fast enough IMO.
>>> it is not? pavel
>> It is, and that is not the problem. The LateX export can happen in
>> the ma
On Thu, Dec 10, 2009 at 9:45 AM, Jean-Marc Lasgouttes wrote:
> Pavel Sanda writes:
>> Jean-Marc Lasgouttes wrote:
>>> the real work
>>> on our buffer structure can be fast enough IMO.
>>
>> it is not? pavel
>
> I thought people implied that it was not, but I may be mistaken.
>
> JMarc
Usually .tex
Abdelrazak Younes wrote:
Pavel Sanda wrote:
Jean-Marc Lasgouttes wrote:
the real work
on our buffer structure can be fast enough IMO.
it is not? pavel
It is, and that is not the problem. The LateX export can happen in
the main thread. The problem is elsewhere in that we need finer
Jean-Marc Lasgouttes wrote:
> >> the real work
> >> on our buffer structure can be fast enough IMO.
> >
> > it is not? pavel
>
> I thought people implied that it was not, but I may be mistaken.
no i dont think this is the root of the problems reported.
pavel
Pavel Sanda writes:
> Jean-Marc Lasgouttes wrote:
>> the real work
>> on our buffer structure can be fast enough IMO.
>
> it is not? pavel
I thought people implied that it was not, but I may be mistaken.
JMarc
Pavel Sanda wrote:
Jean-Marc Lasgouttes wrote:
the real work
on our buffer structure can be fast enough IMO.
it is not? pavel
It is, and that is not the problem. The LateX export can happen in the
main thread. The problem is elsewhere in that we need finer control of
the 5 or 6 p
Jean-Marc Lasgouttes wrote:
> the real work
> on our buffer structure can be fast enough IMO.
it is not? pavel
rgheck writes:
> In thinking about this it occurred to me: If we're generating LaTeX in
> a separate thread, what if the Buffer changes in the meantime? This
> suggests to me that the Buffer has to be locked, which means that
> Abdel's "clone the Buffer" strategy is the only one that really works
Richard Heck wrote:
>>> In thinking about this it occurred to me: If we're generating LaTeX in a
>>> separate thread, what if the Buffer changes in the meantime?
>>>
>> Nothing, once the temporary *.tex file is written.
>> Error-insets on the wrong place, maybe? (However, they tend to be
>> s
On 12/10/2009 08:22 AM, Guenter Milde wrote:
On 2009-12-10, rgheck wrote:
In thinking about this it occurred to me: If we're generating LaTeX in a
separate thread, what if the Buffer changes in the meantime?
Nothing, once the temporary *.tex file is written.
Error-insets on the wrong
On 2009-12-10, rgheck wrote:
> In thinking about this it occurred to me: If we're generating LaTeX in a
> separate thread, what if the Buffer changes in the meantime?
Nothing, once the temporary *.tex file is written.
Error-insets on the wrong place, maybe? (However, they tend to be
somewhat of
In thinking about this it occurred to me: If we're generating LaTeX in a
separate thread, what if the Buffer changes in the meantime? This
suggests to me that the Buffer has to be locked, which means that
Abdel's "clone the Buffer" strategy is the only one that really works.
rh
74 matches
Mail list logo
