On Mon, Jul 14, 2003 at 09:01:52PM +0200, Alfredo Braunstein wrote:
> Effectively, it seems there's no need for a difference. The attached patch
> seems to work fine (will test it a little more though).
Good boy ;-)
Just commit if you are finished with testing.
Andre', wondering whether the sky
Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
>>> Random question: Is there an intended difference between
>>> "rowlist_.clear(); init(bv)" and "init(bv, true)"? Both are used, but
>>> are slightly different.
>>
>> None that I've understood so far. Which, of course, doesn't mean there
>> wa
On Mon, Jul 14, 2003 at 02:56:27PM +0100, John Levon wrote:
> > Feels like it, I can't reproduce it in 1.3.3cvs.
>
> Can you give me a simple testcase to follow please ? I'll file it on
> bugzilla
New doc
a b c
click behind the displayed formula.
d
-> formula row is not properly redrawn. Phys
On Mon, Jul 14, 2003 at 02:55:32PM +0100, John Levon wrote:
> On Mon, Jul 14, 2003 at 03:06:19PM +0200, Andre Poenitz wrote:
>
> > Patch attached. I see no difference compared to current CVS.
>
> My quick testing agrees with you, the change seems to be OK. But where
> are you going with this ?
T
On Mon, Jul 14, 2003 at 03:42:05PM +0200, Andre Poenitz wrote:
> > > Note, however, that updating a row containing a displayed formula is
> > > broken if the cursor is in the 'dummy position' behind the formula.
> > > (with and without the patch).
>
> Feels like it, I can't reproduce it in 1.3.3c
On Mon, Jul 14, 2003 at 03:06:19PM +0200, Andre Poenitz wrote:
> Patch attached. I see no difference compared to current CVS.
My quick testing agrees with you, the change seems to be OK. But where
are you going with this ?
regards
john
On Mon, Jul 14, 2003 at 02:29:23PM +0100, John Levon wrote:
> On Mon, Jul 14, 2003 at 03:06:19PM +0200, Andre Poenitz wrote:
>
> > Patch attached. I see no difference compared to current CVS.
>
> I'll try it now.
>
> > Note, however, that updating a row containing a displayed formula is
> > brok
On Mon, Jul 14, 2003 at 03:06:19PM +0200, Andre Poenitz wrote:
> Patch attached. I see no difference compared to current CVS.
I'll try it now.
> Note, however, that updating a row containing a displayed formula is
> broken if the cursor is in the 'dummy position' behind the formula.
> (with and
On Mon, Jul 14, 2003 at 03:15:21PM +0200, Andre Poenitz wrote:
> If so, wouldn't it be sufficient just to _draw_ the cursor there instead
> of physically placing it there?
Maybe. I don't understand it myself, sorry
john
On Mon, Jul 14, 2003 at 01:58:18PM +0100, John Levon wrote:
> It's to maintain the cursor position at a more useful place when it's
> right in front of a full-row inset (not just one that happens to take up
> a full row though).
You mean that 'dummy position' in front of a big inset where typing
s
On Mon, Jul 14, 2003 at 01:58:18PM +0100, John Levon wrote:
> I suggest removing the setting and seeing for yourself :) (I think I
> tried this some time ago)
Patch attached. I see no difference compared to current CVS.
Note, however, that updating a row containing a displayed formula is
broken i
On Mon, Jul 14, 2003 at 11:11:08AM +0200, Andre Poenitz wrote:
> In the mean time I'd still glad to see any explanation for the
> existence of the LyXCursor::irow member.
>
> Anybody an idea?
It's to maintain the cursor position at a more useful place when it's
right in front of a full-row inse
On Mon, Jul 14, 2003 at 11:42:07AM +0200, Alfredo Braunstein wrote:
> A proposal: how about making the draws step order explicit? I mean to keep
> the 'current step' in some variable and abort (or complain) if a given
> operation is not allowed on this step (like getting the cursor row or y
> posit
Andre Poenitz wrote:
>> Random question: Is there an intended difference between
>> "rowlist_.clear(); init(bv)" and "init(bv, true)"? Both are used, but are
>> slightly different.
>
> None that I've understood so far. Which, of course, doesn't mean there
> wasn't a reason.
The only difference I
On Mon, Jul 14, 2003 at 10:54:53AM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Thu, Jul 10, 2003 at 03:50:27PM +0200, Alfredo Braunstein wrote:
> >> I can reproduce it reliably: resize to the minimum, then enlarge to
> >> maximum -> bang.
> >
>
>
> Busted (anchor_row_ was n
Andre Poenitz wrote:
> On Thu, Jul 10, 2003 at 03:50:27PM +0200, Alfredo Braunstein wrote:
>> I can reproduce it reliably: resize to the minimum, then enlarge to
>> maximum -> bang.
>
Busted (anchor_row_ was not initialized on init). Can I apply this?
Random question: Is there an intended diff
Andre Poenitz wrote:
> On Thu, Jul 10, 2003 at 03:50:27PM +0200, Alfredo Braunstein wrote:
>> I can reproduce it reliably: resize to the minimum, then enlarge to
>> maximum -> bang.
>
> Not here.
Well, it may be because you are using the xforms frontend (and xforms
doesn't let you resize to a sm
Andre Poenitz wrote:
> Hm... how bad is it generally, say compared to the remaining undo
> crashes?
It's not really a problem for me. It seems to be related somehow with small
sizes, so not a real case situation. But 100% reproduceable here.
> I'll leave in about an hour for the weekend and I c
On Thu, Jul 10, 2003 at 03:50:27PM +0200, Alfredo Braunstein wrote:
> I can reproduce it reliably: resize to the minimum, then enlarge to maximum
> -> bang.
Hm... how bad is it generally, say compared to the remaining undo
crashes?
I'll leave in about an hour for the weekend and I could either ba
On Thu, Jul 10, 2003 at 03:50:27PM +0200, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> > Changing the width randomly and widly I get a crash. Actually got two
> > different backtraces:
>
> I can reproduce it reliably: resize to the minimum, then enlarge to maximum
> -> bang.
Not her
Alfredo Braunstein wrote:
> Changing the width randomly and widly I get a crash. Actually got two
> different backtraces:
I can reproduce it reliably: resize to the minimum, then enlarge to maximum
-> bang.
Regards, Alfredo
On Thu, Jul 10, 2003 at 03:38:44PM +0200, Alfredo Braunstein wrote:
> Changing the width randomly and widly I get a crash.
How 'randomly and wildly'?
> Actually got two different backtraces:
>
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1089852768 (LWP 7261)
Changing the width randomly and widly I get a crash. Actually got two
different backtraces:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1089852768 (LWP 7261)]
0x0810fe82 in Paragraph::size() const (this=0x8) at paragraph_pimpl.h:29
29 lyx::pos_type size(
23 matches
Mail list logo
