To our local Qt professionals:
Why do we need
[EMAIL PROTECTED]:/usr/src/lyx/lyx-devel/src grep -R processEve *
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:
Andre Poenitz wrote:
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:qApp-processEvents();
Asger Ottar Alstrup wrote:
Andre Poenitz wrote:
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:qApp-processEvents();
On Sat, May 07, 2005 at 09:21:20PM +0100, Angus Leeming wrote:
Andre Poenitz wrote:
[Actually, there seems to be some bad Qt GUI interaction involved as the
problem shows only up when having certain dialogs open. Otherwise, plain
full redraw seems to be fast enough...]
You reckon it's
On Sat, May 07, 2005 at 11:23:03PM +0200, Helge Hafting wrote:
Coarse screen updates when the cpu can't keep up is much better
than detailed but lagging updates.
And our real problem is that our updates do not serve only the
purpose of showing something on screen, but also to put
Andre Poenitz wrote:
I see. The coord cache must be updated, but I hope the actual drawing
can be skipped ??? when lyx knows that it is behind. That improves
performance in many cases, such as an overloaded machine or X over a
slow network.
The coord cache is filled in the drawing phase
Andre Poenitz wrote:
The coord cache is filled in the drawing phase (the metrics phase fills
the size part of the coord cache only). We _do_ have a 'null painter'
which only fills the cache, but if we did metrics + null painter
painting + real painting in every case, drawing might get slow. Just a
Am Samstag, 7. Mai 2005 21:35 schrieb Andre Poenitz:
Could anybody please make sure that 'his' code does not contain
unnecessary update() calls?
As a first approximation I'd classify any update() with exception
of the one in lyxfunc.C as 'unnecessary'.
Most notably the LFUN_INSET_MODIFY
Georg Baum wrote:
All update() calls in src/insets are unnecessary. They are all in
do_dispatch(), and LCursor-dispatch() makes sure that update is called.
It is the other way round: We need to call cur.noUpdate() if no update is
needed.
I did also call noUpdate() instead of undispatched() in
Asger Ottar Alstrup wrote:
Andre Poenitz wrote:
The coord cache is filled in the drawing phase (the metrics phase fills
the size part of the coord cache only). We _do_ have a 'null painter'
which only fills the cache, but if we did metrics + null painter
painting + real painting in every case,
Michael Schmitt wrote:
IMHO all this falls into category optimization. It's nice to think
about it but first the real problem has to be solved. My impression -
from a perspective of guy who knows nothing about the details - the
additional null painter step looks reasonable.
For sure it is an
Asger Ottar Alstrup wrote:
A better fix is to go to the root of the cause, and in this case, as
mentioned in another post, I believe the right fix is to either omit
or postpone the qApps-processEvent calls during update.
Of course, excessive update calls from other places, as found by
George,
Michael Schmitt wrote:
So the best solution would be:
1. Run metrics computation null painter as a single non-interruptable,
non-reentrant step
(There should be some assertions in the code that check that update
isn't executed twice simultaneously; this should be easily doable by the
Asger Ottar Alstrup wrote:
(There should be some assertions in the code that check that update
isn't executed twice simultaneously; this should be easily doable by
the introduction of a static variable that is incremented when
entering update and decrement when leaving update)
There already is
Am Sonntag, 8. Mai 2005 11:26 schrieb Asger Ottar Alstrup:
Maybe you could add some comments about what the protocol for
update/noupdate calls is? Add it to the BufferView::update method, or
wherever the main update call is.
There is already a comment in LCursor::dispatch. In fact I got my
Andre Poenitz wrote:
frontends/qt2/QDialogView.h: qApp-processEvents();
frontends/qt2/QDialogView.h: qApp-processEvents();
frontends/qt2/QDialogView.h: qApp-processEvents();
frontends/qt2/QDialogView.h: qApp-processEvents();
No idea why/if they are needed,
Andre Poenitz wrote:
On Sat, May 07, 2005 at 09:21:20PM +0100, Angus Leeming wrote:
Andre Poenitz wrote:
[Actually, there seems to be some bad Qt GUI interaction involved as
[the
problem shows only up when having certain dialogs open. Otherwise,
plain full redraw seems to be fast
Andre Poenitz wrote:
To our local Qt professionals:
Why do we need
[EMAIL PROTECTED]:/usr/src/lyx/lyx-devel/src grep -R processEve *
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:
Alfredo Braunstein wrote:
Andre Poenitz wrote:
To our local Qt professionals:
Why do we need
[EMAIL PROTECTED]:/usr/src/lyx/lyx-devel/src grep -R processEve *
frontends/qt2/QDialogView.h:qApp-processEvents();
frontends/qt2/QDialogView.h:qApp-processEvents();
Hello,
Uwe pointed out that gswin32 is a Postscript interpreter used on the
Windows platform. Though I don't have it on my machine, he's right.
I have created a small patch for 1.3, that extends the check of the
configure script. Angus, Jean-Marc, could you please commit it?
(Please note that
Michael Schmitt wrote:
Hello,
Uwe pointed out that gswin32 is a Postscript interpreter used on the
Windows platform. Though I don't have it on my machine, he's right.
I have created a small patch for 1.3, that extends the check of the
configure script. Angus, Jean-Marc, could you please
Hello,
could anybody please enlighten me? In lib/ui/stdmenus.ui, the following
entry is given for document
Item LaTeX Preamble...|P dialog-show preamble
But when I start LyX, there is no menu entry called LaTeX Preamble in
the LyX Document menu! Even more surprising, when I enter dialog-show
Michael Schmitt wrote:
Hello,
could anybody please enlighten me? In lib/ui/stdmenus.ui, the following
entry is given for document
Item LaTeX Preamble...|P dialog-show preamble
But when I start LyX, there is no menu entry called LaTeX Preamble in
the LyX Document menu! Even more
Michael Schmitt wrote:
Shouldn't we be using gswin32c, the command-line version that doesn't
pop
up a console window when it is invoked?
$ ls /mnt/windowsC/Program\ Files/Ghostscript\ 8.33/gs8.33/bin
gsdll32.dll gsdll32.lib gswin32c.exe gswin32.exe
If I'd know about gswin32c.exe I woulnd't
Angus Leeming wrote:
Shouldn't we be using gswin32c, the command-line version that doesn't pop
up a console window when it is invoked?
$ ls /mnt/windowsC/Program\ Files/Ghostscript\ 8.33/gs8.33/bin
gsdll32.dll gsdll32.lib gswin32c.exe gswin32.exe
If I'd know about gswin32c.exe I woulnd't have
On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
sync_events appears to be called on each and every blink of the cursor:
void LyXScreen::showCursor(BufferView bv)
{
// You are not expected to understand this. This forces Qt
// (the problem case) to deal with
Sorry,
I forgot to fix a few more occurrences of reference-goto. Please apply.
Thanks, Michael
Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.696
diff -u -p -r1.696 ChangeLog
--- ChangeLog
On Sun, May 08, 2005 at 01:35:10PM +0200, Juergen Spitzmueller wrote:
Andre Poenitz wrote:
frontends/qt2/QDialogView.h: qApp-processEvents();
frontends/qt2/QDialogView.h: qApp-processEvents();
frontends/qt2/QDialogView.h: qApp-processEvents();
frontends/qt2/QDialogView.h:
On Sun, May 08, 2005 at 10:53:08AM +0200, Michael Schmitt wrote:
Andre Poenitz wrote:
I see. The coord cache must be updated, but I hope the actual drawing
can be skipped ??? when lyx knows that it is behind. That improves
performance in many cases, such as an overloaded machine or X over
On Sun, May 08, 2005 at 10:57:04AM +0200, Georg Baum wrote:
I did also call noUpdate() instead of undispatched() in insetcommand.C. Is
that correct?
'undispatched' means: I, the doDispatch() method of InsetFoo, hereby
declare that I am not able to handle that request and trust my parent
will
On Sun, May 08, 2005 at 01:05:00PM +0200, Michael Schmitt wrote:
Asger Ottar Alstrup wrote:
(There should be some assertions in the code that check that update
isn't executed twice simultaneously; this should be easily doable by
the introduction of a static variable that is incremented
On Sun, May 08, 2005 at 12:05:50PM +0200, Michael Schmitt wrote:
Asger Ottar Alstrup wrote:
A better fix is to go to the root of the cause, and in this case, as
mentioned in another post, I believe the right fix is to either omit
or postpone the qApps-processEvent calls during update.
On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
sync_events appears to be called on each and every blink of the cursor:
void LyXScreen::showCursor(BufferView bv)
{
// You are not expected to understand this. This forces Qt
// (the problem case) to deal with its
On Sun, May 08, 2005 at 04:21:44PM +0200, Alfredo Braunstein wrote:
We could save some network traffic by restricting actual drawing to some
horizontal strip as we did in 1.3, but this would be new code, the old
logic does not fit anymore.
And then, we 1.3.x only saved redraws when typing
On Sun, May 08, 2005 at 12:16:27PM +0200, Asger Ottar Alstrup wrote:
Yes, something like this should work better. This can be done in steps:
First, just leave the excessive painting as it is, but fix the
re-entrancy problem. Then, as a second step, introduce the null-painter
as an
On Sun, May 08, 2005 at 07:56:47PM +0200, Andre Poenitz wrote:
On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
sync_events appears to be called on each and every blink of the cursor:
void LyXScreen::showCursor(BufferView bv)
{
// You are not expected to understand
On Sun, May 08, 2005 at 05:50:08PM +0100, John Levon wrote:
On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
sync_events appears to be called on each and every blink of the cursor:
void LyXScreen::showCursor(BufferView bv)
{
// You are not expected to understand
On Sun, May 08, 2005 at 10:37:33PM +0300, Martin Vermeer wrote:
But... isn't this cursor drawing and hiding an asynchronous process
taking place every 400 msec? What happens if a drawing activity takes
longer than 400 (800?) msec and the cursor comes back all of itself in
the middle of it?
On Sun, May 08, 2005 at 05:50:08PM +0100, John Levon wrote:
But I'm a bit confused as to why this is an issue: when I rewrote the
cursor handling, I'm pretty sure I made it so that showCursor is only
/ever/ called right at the end of an update (that is, after processing
an LFUN). So I don't
On Sun, May 08, 2005 at 05:50:08PM +0100, John Levon wrote:
The dialog ones are necessary because we want the dialogs to rebuild
their sizes etc. when we can't see the individual updates. If we had a
way to just update the dialog's events...
I do not really understand what you mean here. Maybe
On Sun, May 08, 2005 at 08:41:26PM +0100, John Levon wrote:
On Sun, May 08, 2005 at 10:37:33PM +0300, Martin Vermeer wrote:
But... isn't this cursor drawing and hiding an asynchronous process
taking place every 400 msec? What happens if a drawing activity takes
longer than 400 (800?) msec
Note the line marked with !!!. This workAreaKeyPress shows btw up in
the backtrace of a nested update call.
Why are we calling workAreaKeyPress() during an update?
I don't care how the dialog manage to rebuild there sizes if the core
crashes.
The core didn't used to crash in 1.3. You
On Sun, May 08, 2005 at 10:28:59PM +0200, Andre Poenitz wrote:
What about removing cursor and cursor blinking timer at the begin of
update and start a new timer with a shown cursorat the end of update?
Sounds very sensible to me.
regards
john
On Sun, May 08, 2005 at 09:33:55PM +0100, John Levon wrote:
On Sun, May 08, 2005 at 10:28:59PM +0200, Andre Poenitz wrote:
What about removing cursor and cursor blinking timer at the begin of
update and start a new timer with a shown cursorat the end of update?
Sounds very sensible to
On Sun, May 08, 2005 at 08:20:55PM +0200, Andre Poenitz wrote:
On Sun, May 08, 2005 at 05:50:08PM +0100, John Levon wrote:
...
void BufferView::Pimpl::workAreaKeyPress(LyXKeySymPtr key,
key_modifier::state state)
{
Angus Leeming wrote:
Can you find out from Uwe whether gswin32c exists on
his box and whether it 'feels' nicer to use it.
gswin32c.exe is part of all ghostscript win installations. It changes to
a gs prompt in the win console. In contrast gswin32.exe opens a new
window with a gs console.
Both
Angus Leeming wrote:
Both. You use Windows, I try not to. I learn vicariously through the
experience of others. Can you find out from Uwe whether gswin32c exists on
his box and whether it 'feels' nicer to use it.
Since Uwe has no objections, let's use gswin32c.
Angus, Jean-Marc, please apply
Hello,
this patch fixes the shortcuts for Cross-reference.
Please apply to LyX 1.4.
Thanks, Michael
Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.696
diff -u -p -r1.696 ChangeLog
--- ChangeLog
To our local Qt professionals:
Why do we need
[EMAIL PROTECTED]:/usr/src/lyx/lyx-devel/src > grep -R processEve *
frontends/qt2/QDialogView.h:qApp->processEvents();
frontends/qt2/QDialogView.h:qApp->processEvents();
frontends/qt2/QDialogView.h:
Andre Poenitz wrote:
frontends/qt2/QDialogView.h:qApp->processEvents();
frontends/qt2/QDialogView.h:qApp->processEvents();
frontends/qt2/QDialogView.h:qApp->processEvents();
frontends/qt2/QDialogView.h:qApp->processEvents();
Asger Ottar Alstrup wrote:
Andre Poenitz wrote:
frontends/qt2/QDialogView.h:qApp->processEvents();
frontends/qt2/QDialogView.h:qApp->processEvents();
frontends/qt2/QDialogView.h:qApp->processEvents();
frontends/qt2/QDialogView.h:qApp->processEvents();
On Sat, May 07, 2005 at 09:21:20PM +0100, Angus Leeming wrote:
> Andre Poenitz wrote:
> > [Actually, there seems to be some bad Qt GUI interaction involved as the
> > problem shows only up when having certain dialogs open. Otherwise, plain
> > full redraw seems to be fast enough...]
>
> You
On Sat, May 07, 2005 at 11:23:03PM +0200, Helge Hafting wrote:
> > > Coarse screen updates when the cpu can't keep up is much better
> > > than detailed but lagging updates.
> >
> > And our real problem is that our updates do not serve only the
> > purpose of showing something on screen, but
Andre Poenitz wrote:
I see. The coord cache must be updated, but I hope the actual drawing
can be skipped ??? when lyx knows that it is behind. That improves
performance in many cases, such as an overloaded machine or X over a
slow network.
The coord cache is filled in the drawing phase
Andre Poenitz wrote:
The coord cache is filled in the drawing phase (the metrics phase fills
the size part of the coord cache only). We _do_ have a 'null painter'
which only fills the cache, but if we did metrics + null painter
painting + real painting in every case, drawing might get slow. Just a
Am Samstag, 7. Mai 2005 21:35 schrieb Andre Poenitz:
>
> Could anybody please make sure that 'his' code does not contain
> unnecessary update() calls?
>
> As a first approximation I'd classify any update() with exception
> of the one in lyxfunc.C as 'unnecessary'.
>
> Most notably the
Georg Baum wrote:
All update() calls in src/insets are unnecessary. They are all in
do_dispatch(), and LCursor->dispatch() makes sure that update is called.
It is the other way round: We need to call cur.noUpdate() if no update is
needed.
I did also call noUpdate() instead of undispatched() in
Asger Ottar Alstrup wrote:
Andre Poenitz wrote:
The coord cache is filled in the drawing phase (the metrics phase fills
the size part of the coord cache only). We _do_ have a 'null painter'
which only fills the cache, but if we did metrics + null painter
painting + real painting in every case,
Michael Schmitt wrote:
IMHO all this falls into category "optimization". It's nice to think
about it but first the real problem has to be solved. My impression -
from a perspective of guy who knows nothing about the details - the
additional null painter step looks reasonable.
For sure it is an
Asger Ottar Alstrup wrote:
A better fix is to go to the root of the cause, and in this case, as
mentioned in another post, I believe the right fix is to either omit
or postpone the qApps->processEvent calls during update.
Of course, excessive update calls from other places, as found by
George,
Michael Schmitt wrote:
So the "best" solution would be:
1. Run metrics computation & null painter as a single non-interruptable,
non-reentrant step
(There should be some assertions in the code that check that update
isn't executed twice simultaneously; this should be easily doable by the
Asger Ottar Alstrup wrote:
(There should be some assertions in the code that check that update
isn't executed twice simultaneously; this should be easily doable by
the introduction of a static variable that is incremented when
entering update and decrement when leaving update)
There already is
Am Sonntag, 8. Mai 2005 11:26 schrieb Asger Ottar Alstrup:
> Maybe you could add some comments about what the protocol for
> update/noupdate calls is? Add it to the BufferView::update method, or
> wherever the main update call is.
There is already a comment in LCursor::dispatch. In fact I got
Andre Poenitz wrote:
> frontends/qt2/QDialogView.h: qApp->processEvents();
> frontends/qt2/QDialogView.h: qApp->processEvents();
> frontends/qt2/QDialogView.h: qApp->processEvents();
> frontends/qt2/QDialogView.h: qApp->processEvents();
No idea why/if they are
Andre Poenitz wrote:
> On Sat, May 07, 2005 at 09:21:20PM +0100, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> > [Actually, there seems to be some bad Qt GUI interaction involved as
>> > [the
>> > problem shows only up when having certain dialogs open. Otherwise,
>> > plain full redraw seems to
Andre Poenitz wrote:
>
>
> To our local Qt professionals:
>
> Why do we need
>
> [EMAIL PROTECTED]:/usr/src/lyx/lyx-devel/src > grep -R processEve *
> frontends/qt2/QDialogView.h:qApp->processEvents();
> frontends/qt2/QDialogView.h:qApp->processEvents();
> frontends/qt2/QDialogView.h:
Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
>>
>>
>> To our local Qt professionals:
>>
>> Why do we need
>>
>> [EMAIL PROTECTED]:/usr/src/lyx/lyx-devel/src > grep -R processEve *
>> frontends/qt2/QDialogView.h:qApp->processEvents();
>> frontends/qt2/QDialogView.h:
Hello,
Uwe pointed out that gswin32 is a Postscript interpreter used on the
Windows platform. Though I don't have it on my machine, he's right.
I have created a small patch for 1.3, that extends the check of the
configure script. Angus, Jean-Marc, could you please commit it?
(Please note that
Michael Schmitt wrote:
> Hello,
>
> Uwe pointed out that gswin32 is a Postscript interpreter used on the
> Windows platform. Though I don't have it on my machine, he's right.
>
> I have created a small patch for 1.3, that extends the check of the
> configure script. Angus, Jean-Marc, could you
Hello,
could anybody please enlighten me? In lib/ui/stdmenus.ui, the following
entry is given for "document"
Item "LaTeX Preamble...|P" "dialog-show preamble"
But when I start LyX, there is no menu entry called "LaTeX Preamble" in
the LyX Document menu! Even more surprising, when I enter
Michael Schmitt wrote:
> Hello,
>
> could anybody please enlighten me? In lib/ui/stdmenus.ui, the following
> entry is given for "document"
>
> Item "LaTeX Preamble...|P" "dialog-show preamble"
>
> But when I start LyX, there is no menu entry called "LaTeX Preamble" in
> the LyX Document
Michael Schmitt wrote:
>> Shouldn't we be using gswin32c, the command-line version that doesn't
>> pop
>>
>>up a console window when it is invoked?
>>
>>$ ls /mnt/windowsC/Program\ Files/Ghostscript\ 8.33/gs8.33/bin
>>gsdll32.dll gsdll32.lib gswin32c.exe gswin32.exe
>>
>>If I'd know about
Angus Leeming wrote:
Shouldn't we be using gswin32c, the command-line version that doesn't pop
up a console window when it is invoked?
$ ls /mnt/windowsC/Program\ Files/Ghostscript\ 8.33/gs8.33/bin
gsdll32.dll gsdll32.lib gswin32c.exe gswin32.exe
If I'd know about gswin32c.exe I woulnd't have
On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
> sync_events appears to be called on each and every blink of the cursor:
> void LyXScreen::showCursor(BufferView & bv)
> {
> // You are not expected to understand this. This forces Qt
> // (the problem case) to deal
Sorry,
I forgot to fix a few more occurrences of "reference-goto". Please apply.
Thanks, Michael
Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.696
diff -u -p -r1.696 ChangeLog
--- ChangeLog
On Sun, May 08, 2005 at 01:35:10PM +0200, Juergen Spitzmueller wrote:
> Andre Poenitz wrote:
> > frontends/qt2/QDialogView.h: qApp->processEvents();
> > frontends/qt2/QDialogView.h: qApp->processEvents();
> > frontends/qt2/QDialogView.h: qApp->processEvents();
> > frontends/qt2/QDialogView.h:
On Sun, May 08, 2005 at 10:53:08AM +0200, Michael Schmitt wrote:
> Andre Poenitz wrote:
>
> >>I see. The coord cache must be updated, but I hope the actual drawing
> >>can be skipped ??? when lyx knows that it is behind. That improves
> >>performance in many cases, such as an overloaded machine
On Sun, May 08, 2005 at 10:57:04AM +0200, Georg Baum wrote:
> I did also call noUpdate() instead of undispatched() in insetcommand.C. Is
> that correct?
'undispatched' means: I, the doDispatch() method of InsetFoo, hereby
declare that I am not able to handle that request and trust my parent
will
On Sun, May 08, 2005 at 01:05:00PM +0200, Michael Schmitt wrote:
> Asger Ottar Alstrup wrote:
>
> >> (There should be some assertions in the code that check that update
> >>isn't executed twice simultaneously; this should be easily doable by
> >>the introduction of a static variable that is
On Sun, May 08, 2005 at 12:05:50PM +0200, Michael Schmitt wrote:
> Asger Ottar Alstrup wrote:
>
> >A better fix is to go to the root of the cause, and in this case, as
> >mentioned in another post, I believe the right fix is to either omit
> >or postpone the qApps->processEvent calls during
On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
> sync_events appears to be called on each and every blink of the cursor:
> void LyXScreen::showCursor(BufferView & bv)
> {
> // You are not expected to understand this. This forces Qt
> // (the problem case) to deal
On Sun, May 08, 2005 at 04:21:44PM +0200, Alfredo Braunstein wrote:
> > We could save some network traffic by restricting actual drawing to some
> > horizontal strip as we did in 1.3, but this would be new code, the old
> > logic does not fit anymore.
>
> And then, we 1.3.x only saved redraws
On Sun, May 08, 2005 at 12:16:27PM +0200, Asger Ottar Alstrup wrote:
> Yes, something like this should work better. This can be done in steps:
>
> First, just leave the excessive painting as it is, but fix the
> re-entrancy problem. Then, as a second step, introduce the null-painter
> as an
On Sun, May 08, 2005 at 07:56:47PM +0200, Andre Poenitz wrote:
> On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
> > sync_events appears to be called on each and every blink of the cursor:
> > void LyXScreen::showCursor(BufferView & bv)
> > {
> > // You are not expected to
On Sun, May 08, 2005 at 05:50:08PM +0100, John Levon wrote:
> On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
>
> > sync_events appears to be called on each and every blink of the cursor:
> > void LyXScreen::showCursor(BufferView & bv)
> > {
> > // You are not expected to
On Sun, May 08, 2005 at 10:37:33PM +0300, Martin Vermeer wrote:
> But... isn't this cursor drawing and hiding an asynchronous process
> taking place every 400 msec? What happens if a drawing activity takes
> longer than 400 (800?) msec and the cursor comes back all of itself in
> the middle of
On Sun, May 08, 2005 at 05:50:08PM +0100, John Levon wrote:
> But I'm a bit confused as to why this is an issue: when I rewrote the
> cursor handling, I'm pretty sure I made it so that showCursor is only
> /ever/ called right at the end of an update (that is, after processing
> an LFUN). So I
On Sun, May 08, 2005 at 05:50:08PM +0100, John Levon wrote:
> The dialog ones are necessary because we want the dialogs to rebuild
> their sizes etc. when we can't see the individual updates. If we had a
> way to just update the dialog's events...
I do not really understand what you mean here.
On Sun, May 08, 2005 at 08:41:26PM +0100, John Levon wrote:
> On Sun, May 08, 2005 at 10:37:33PM +0300, Martin Vermeer wrote:
>
> > But... isn't this cursor drawing and hiding an asynchronous process
> > taking place every 400 msec? What happens if a drawing activity takes
> > longer than 400
> Note the line marked with !!!. This workAreaKeyPress shows btw up in
> the backtrace of a nested update call.
Why are we calling workAreaKeyPress() during an update?
> I don't care how the dialog manage to rebuild there sizes if the core
> crashes.
The core didn't used to crash in 1.3. You
On Sun, May 08, 2005 at 10:28:59PM +0200, Andre Poenitz wrote:
> What about removing cursor and cursor blinking timer at the begin of
> update and start a new timer with a shown cursorat the end of update?
Sounds very sensible to me.
regards
john
On Sun, May 08, 2005 at 09:33:55PM +0100, John Levon wrote:
> On Sun, May 08, 2005 at 10:28:59PM +0200, Andre Poenitz wrote:
>
> > What about removing cursor and cursor blinking timer at the begin of
> > update and start a new timer with a shown cursorat the end of update?
>
> Sounds very
On Sun, May 08, 2005 at 08:20:55PM +0200, Andre Poenitz wrote:
> On Sun, May 08, 2005 at 05:50:08PM +0100, John Levon wrote:
...
> void BufferView::Pimpl::workAreaKeyPress(LyXKeySymPtr key,
>key_modifier::state state)
> {
>
Angus Leeming wrote:
Can you find out from Uwe whether gswin32c exists on
his box and whether it 'feels' nicer to use it.
gswin32c.exe is part of all ghostscript win installations. It changes to
a gs prompt in the win console. In contrast gswin32.exe opens a new
window with a gs console.
Both
Angus Leeming wrote:
Both. You use Windows, I try not to. I learn vicariously through the
experience of others. Can you find out from Uwe whether gswin32c exists on
his box and whether it 'feels' nicer to use it.
Since Uwe has no objections, let's use gswin32c.
Angus, Jean-Marc, please apply
Hello,
this patch fixes the shortcuts for "Cross-reference".
Please apply to LyX 1.4.
Thanks, Michael
Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.696
diff -u -p -r1.696 ChangeLog
---
96 matches
Mail list logo
