Richard Heck wrote:
> Enrico Forestieri wrote:
>> Another option would be the following. When the user enters
>> \mathbf{x\alpha y}, we could output the following latex code:
>> \mathbf{x\boldsymbol{\alpha}y}.
>>
>>
> Surely this far and away the best option. The user in this case does not
> ca
Richard Heck wrote:
>(Note, by the way, that the depth is still set to
> 3, although there is nothing in the TOC. This is itself a problem.)
hopefully fixed in http://www.lyx.org/trac/changeset/26360
pavel
Vincent van Ravesteijn wrote:
Well, for me it was much easier to reproduce. I can hardly use the
outliner without an endless 100% CPU loop.
PS I'm on 64-bit, maybe that makes it worse overhere.
Me too. I'm not sure why I didn't get it right away. But once I did get
it, I just kept right on ge
rgheck wrote:
I've fixed at least part of this at r26356. A pair of uninitialized
variables was causing the size of the TOC slider to be set to huge
values in certain cases.
I've also fixed the other issue I mentioned in a different post, which
is that the size of the slider didn't get reset wh
Vincent van Ravesteijn wrote:
rgheck wrote:
I've fixed at least part of this at r26356. A pair of uninitialized
variables was causing the size of the TOC slider to be set to huge
values in certain cases.
I've also fixed the other issue I mentioned in a different post, which
is that the size of
rgheck wrote:
I've fixed at least part of this at r26356. A pair of uninitialized
variables was causing the size of the TOC slider to be set to huge
values in certain cases.
I've also fixed the other issue I mentioned in a different post, which
is that the size of the slider didn't get reset wh
I've fixed at least part of this at r26356. A pair of uninitialized
variables was causing the size of the TOC slider to be set to huge
values in certain cases.
I've also fixed the other issue I mentioned in a different post, which
is that the size of the slider didn't get reset when you clos
rgheck wrote:
Vincent van Ravesteijn wrote:
I think the problem is in the following lines :
src/frontends/qt4/TocWidget.cpp: 259--261
depthSL->setMaximum(gui_view_.tocModels().depth(current_type_));
depthSL->setValue(depth_);
setTreeDepth(depth_);
Adding this to the code:
LYXERR( Debug::GUI,
Jean-Marc Lasgouttes wrote:
> "Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> > Removing the first solves the problem and it works
> > perfectly.
> >
> > Can anyone tell me why this term is needed or did I just solve the bug ?
> > (Or I might to have to look somewhere else?)
> >
Vincent van Ravesteijn wrote:
I think the problem is in the following lines :
src/frontends/qt4/TocWidget.cpp: 259--261
depthSL->setMaximum(gui_view_.tocModels().depth(current_type_));
depthSL->setValue(depth_);
setTreeDepth(depth_);
Adding this to the code:
LYXERR( Debug::GUI, "DEPTH : " <<
Andre Poenitz wrote:
On Thu, Sep 11, 2008 at 12:01:37PM +0200, Helge Hafting wrote:
> Pavel Sanda wrote:
>> the best would be if you can run lyx under gdb, ctrl+c in the moment
>> of freeze in gdb window and send the output of bt command.
>>
>>
> The delay happened when I started LyX so it cam
Andre Poenitz wrote:
On Thu, Sep 11, 2008 at 09:11:49AM +0200, Abdelrazak Younes wrote:
Richard Heck wrote:
Andre Poenitz wrote:
I admit we haven't discussed it for a few years, mainly because last
time we reached consensus that it would be Real Kool(tm) to have but
nobody i
On Thu, Sep 11, 2008 at 12:01:37PM +0200, Helge Hafting wrote:
> Pavel Sanda wrote:
>> the best would be if you can run lyx under gdb, ctrl+c in the moment
>> of freeze in gdb window and send the output of bt command.
>>
>>
> The delay happened when I started LyX so it came up with the outliner
On Thu, Sep 11, 2008 at 09:11:49AM +0200, Abdelrazak Younes wrote:
> Richard Heck wrote:
>> Andre Poenitz wrote:
>>
>>> I admit we haven't discussed it for a few years, mainly because last
>>> time we reached consensus that it would be Real Kool(tm) to have but
>>> nobody implemented it.
>>>
>> Did
On Thu, Sep 11, 2008 at 09:11:49AM +0200, Abdelrazak Younes wrote:
> Richard Heck wrote:
> > Andre Poenitz wrote:
> >
> >> I admit we haven't discussed it for a few years, mainly because last
> >> time we reached consensus that it would be Real Kool(tm) to have but
> >> nobody implemented it.
> >>
Abdelrazak Younes wrote:
OK, this seems like a recursive painting problem between the outliner
widget and the main work area (one pushing the other to get drawn).
Weird that it does not show on Windows...
Differences in the underlying windowing systems that qt doesn't mask
completely?
Why
Helge Hafting wrote:
> Pavel Sanda wrote:
>> the best would be if you can run lyx under gdb, ctrl+c in the moment
>> of freeze in gdb window and send the output of bt command.
>>
>>
> The delay happened when I started LyX so it came up with the outliner open,
> and then did "File->new". LyX fro
Helge Hafting wrote:
Pavel Sanda wrote:
the best would be if you can run lyx under gdb, ctrl+c in the moment
of freeze in gdb window and send the output of bt command.
The delay happened when I started LyX so it came up with the outliner
open,
and then did "File->new". LyX froze with 100% cpu
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> After solving these two minor issues (I will send a patch when I'm
> finished with this stuff), I did not have problems with the bug I
> mentioned before, so don't spend time on it.
Thanks for the explanations.
JMarc
Pavel Sanda wrote:
the best would be if you can run lyx under gdb, ctrl+c in the moment
of freeze in gdb window and send the output of bt command.
The delay happened when I started LyX so it came up with the outliner open,
and then did "File->new". LyX froze with 100% cpu trying to display
> needsUpdate returns true when the status of the selection has
> changed (turned on or turned off). While your patch is indeed
> the right solution for table movement,
Well, actually it wasn't the right solution as I realized later that the
expected behaviour is that after the first keystrok
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> Removing the first solves the problem and it works
> perfectly.
>
> Can anyone tell me why this term is needed or did I just solve the bug ?
> (Or I might to have to look somewhere else?)
>
> PS. The description of cur.selHandle(..
> Could you restate again what the bug is?
>
> Jmarc
The bug _was_ that when making a selection, cur.selection() is true even
if the selection is still empty. In cs 26146 we removed such an empty
selection when the cursor is released. But, before releasing the mouse,
the 'problem' might still be
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> For the moment, forget this cur.setSelection() part. It is still not
> correct probably. Although I don't encounter the problem anymore, it
> might not be correct to call it in cur.setSelection(...). Maybe it
> breaks down something else.
Richard Heck wrote:
Andre Poenitz wrote:
I admit we haven't discussed it for a few years, mainly because last
time we reached consensus that it would be Real Kool(tm) to have but
nobody implemented it.
Did anyone try?
I played a bit with the drawing side once. Should not be terribly difficu
25 matches
Mail list logo
