Re: top_y() is killing us

[Juergen Vigna]

Andre Poenitz wrote:
So what about the two-stage drawing?

Give the insets a small cache of width/ascent/descent (you could steal from
math_diminset I suppose), fill the cache of an inset in the first stage
according to the size of the contents of the inset, and do all the drawing
in the second stage...
But we do this already we calculate all the matrices for drawing and
in the draw function we (most of the time) do just drawing and that
is pretty fast!) or what do you think do we use the LyXText inside
the InsetText for?
  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: Fun with updating

[Juergen Vigna]

John Levon wrote:
Juergen, can you help ? What would you say if I suggest ripping the font
paramter from inset-update ?
I would say this could be a good idea. Just define a default font
for an empty CellInset and pass that one instead. IMO this is the best
solution and you're able to rip out the LyXFont parameter.
Would that be an option?

   Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: top_y() is killing us

[Andre Poenitz]

On Wed, Mar 19, 2003 at 05:12:56PM +, John Levon wrote:
  Give the insets a small cache of width/ascent/descent (you could steal from
  math_diminset I suppose), fill the cache of an inset in the first stage
  according to the size of the contents of the inset, and do all the drawing
  in the second stage...
 
 I'm not sure the actual drawing is slowest, it's not showing up big time
 in the profiles. Things like singleWidth() are.

I am not suggesting otherwise. But by clearly separating metrics computation
and actual drawing we make sure that things like singleWitdh() are called
only once per redraw.

 I'm not really sure how I'd implement what you're suggesting anyway. We
 already have inset-width() ...

Look at what mathed does: At a very high level (i.e InsetFormula::draw) the
work is split. The first call to width() calls metrics()  [ok, this is
messy, but currently the easiest way to make sure that metrics() is called
after loading of a buffer, too]. Afterwards, the real draw part is done, by
calling the nested inset's draw() [which do not contain metrics
computations anymore]

We should move this separation to a higher level. I.e. whatever calls
InsetFormula::draw() should first call InsetFormula::metrics() and the only
the drawing part. At this point probably all insets need the separation of
their individual draw() functions into metrics() and [real] draw(). 

 And I seriously doubt I have enough understanding to do it. I have never
 worked out what the hell Inset::scroll() does, for example.
 Or the exact semantics of InsetCollapsable::need_update.

Neither have I...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: Fun with updating

[Juergen Vigna]

John Levon wrote:
HA ! That's a bloody joke. This doesn't work. I have absolutely no idea
why, of course. This update stuff is entirely beyond understanding. Just
dealing with the bv-updateInset() vs. bv-update() vs. bv-update(blah)
vs. inset-update() vs. inset-updateInsetInInset() vs lyxtext-update()
vs. lyxtext-updateInset() [1] isn't too bad, but the semi-recursive
nature and delayed insettext state update thing makes it impossible.
I've spent 2 solid hours trying to work out the correct way of forcing
an update of a minipage, no go. Pretty pissed off ...
I would have been *really* surprised if you would have figured out a
better way in one day, do you know how long I worked on this stuff to
make it work as it is now.
The only way I see to fix the whole lot is that we would have to update
the deepest insets first. I'm pretty sure there is a good algoritmus for
this and if one goes and concentrates on the problem I'm pretty sure we
come up with something working. As I told you we have to update the
deepest insets first and then from there come up. Obviously at each level
we can have more then just 1 inset and that is what complicates all of
it, but as I said I'm pretty confident that there is a better way to
solve this as the actual one which (I admit it) is pretty hard to
understand and far away from the best way to do it.
I've done this anyway, since it doesn't make things worse. I'm
committing the lot below tomorrow.
Ok you did it as I expected. Defined a fixed font for the empty tabular
cell font.
What I don't like in all this is the removal of the mark_dirty flag
how do you do now to set the dirty flag on the buffer? (I admit I had
only a fast look at your patch).
   Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: [PATCH] move need_update handling into insetert

[Juergen Vigna]

John Levon wrote:
This fixes a long-standing bug, for some reason (namely, switch from
closed to inlined did not correctly recalculate the width), but does not
fix an *existing* bug that is new to 1.4.0cvs (bug 965). Jug, if you're
listening: why doesn't the insettext-update() correctly deal with the
cursor positioning changing ?
But really this is a matter of a start of cleanup, only insetert uses
the insetcollapsable need_update handling, so it should go there.
It also doesn't yet fix bug 966, which is old.

OK ?
IMO this is ok if this need_update is only used in InsetERT then this
surely is wrong.
 Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: inset_apply bug

[Andre Poenitz]

On Wed, Mar 19, 2003 at 05:35:09PM +, John Levon wrote:
 LFUN_INSET_MODIFY needs to do an updateInset() on the given inset,
 it may change shape (e.g. minipage). This requires moving updateInset()
 into InsetBase I guess ...

No problem.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: [PATCH] more ert stuff

[Juergen Vigna]

John Levon wrote:
This is a more recent version, that also fixes bug 966. We were not
checking for size(text)  size(button) in the ERT draw. This was fixed
by merging  the duplicated code.
IMO this should be pretty safe to apply.

  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: top_y() is killing us

[Juergen Vigna]

Andre Poenitz wrote:
Look at what mathed does: At a very high level (i.e InsetFormula::draw) the
work is split. The first call to width() calls metrics()  [ok, this is
messy, but currently the easiest way to make sure that metrics() is called
after loading of a buffer, too]. Afterwards, the real draw part is done, by
calling the nested inset's draw() [which do not contain metrics
computations anymore]
I told you this already a lot of times, the redraw of mathed is really
easy to do. You have all fixed width insets and the don't do a rebreak or
resize themselfs to their environment. You cannot compare this to the
complexity of InsetText you may compare this to a inset like lets say
a InsetTabular if we wouldn't have the posibility of autobreaking rows
(as it was in the first draft of the inset).
  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: Fun with updating

[Andre Poenitz]

On Wed, Mar 19, 2003 at 09:35:15PM +, John Levon wrote:
 So it's looking very much like Andre's two-stage thingy at this point,
 just to solve a tiny bit of this :(

Alejandro's two-stage thingy.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: Fun with updating

[Andre Poenitz]

On Thu, Mar 20, 2003 at 03:06:48AM +, John Levon wrote:
 On Wed, Mar 19, 2003 at 09:35:15PM +, John Levon wrote:
 
  This is fun. Insets like InsetMinipage and InsetERT can have e.g.
  INSET_MODIFY applied to them. This can actually alter its size. It
  actually needs to tell its contained InsetText to -update(reinit ==
  true);
 
 HA ! That's a bloody joke. This doesn't work. I have absolutely no idea
 why, of course. This update stuff is entirely beyond understanding.

But a two-stage approach is, isn't it?

Andre'


-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 09:36:38AM +0100, Juergen Vigna wrote:
 I told you this already a lot of times, the redraw of mathed is really
 easy to do. You have all fixed width insets and the don't do a rebreak or
 resize themselfs to their environment. You cannot compare this to the
 complexity of InsetText you may compare this to a inset like lets say
 a InsetTabular if we wouldn't have the posibility of autobreaking rows
 (as it was in the first draft of the inset).

And I still do not believe that this makes a big difference.

Btw, this is not exactly true: Whenever you change a macro definition, the
size of the macro's expansions change, too.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

[patch] fix bug 964

[Alfredo Braunstein]

Duh! Please apply.

Alfredo
Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/ChangeLog,v
retrieving revision 1.1136
diff -u -p -u -r1.1136 ChangeLog
--- ChangeLog	2003/03/19 18:43:55	1.1136
+++ ChangeLog	2003/03/20 08:53:34
@@ -1,3 +1,7 @@
+2003-03-20  Alfredo Braunstein  [EMAIL PROTECTED]
+
+	* text2.C (removeRow): fix bug 964
+
 2003-03-19  John Levon  [EMAIL PROTECTED]
 
 	* lyxfunc.C: only fitcursor/markDirty if available()
Index: text2.C
===
RCS file: /cvs/lyx/lyx-devel/src/text2.C,v
retrieving revision 1.295
diff -u -p -u -r1.295 text2.C
--- text2.C	2003/03/19 14:45:15	1.295
+++ text2.C	2003/03/20 08:53:37
@@ -334,7 +334,7 @@ void LyXText::removeRow(Row * row)
 	if (anchor_row_ == row) {
 		if (row_prev) {
 			anchor_row_ = row_prev;
-			anchor_row_offset_ = 0;
+			anchor_row_offset_ += row_prev-height();
 		} else {
 			anchor_row_ = row-next();
 			anchor_row_offset_ -= row-height();

Re: Crash recipe

[Lars Gullik Bjønnes]

Garst R. Reese [EMAIL PROTECTED] writes:

| Open newfile
| enter Ctrl space
| hit enter
| hit backspace
| boom
| current 1.4CVS

Crash or assert?
(it is an assert if it says abort instead of segfault...)

-- 
Lgb

Re: top_y() is killing us

[Juergen Vigna]

Andre Poenitz wrote:
And I still do not believe that this makes a big difference.
Well this is up to you

 Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

lyx 1.3.2cvs qt backtrace of crash when closing external inset.

[Helge Hafting]

Closing an external inset in lyx-1.3.1 or 1.3.2cvs may crash. It is 
reproducible
with one of my files, the backtrace is at the end of this message.

I'm using gcc/g++ 3.2 and qt3 from debian unstable.
The crash is reproduced like this:
Start lyx, open file
scroll to the external inset
bring up the external inset dialog.
change something, such as the parameter to the external converter
Press the close button, and lyx dies and do the emergency save.
The backtrace is for lyx-1.3.2cvs, updated ten minutes before sending this.

Helge Hafting

#0  0x407a2a51 in kill () from /lib/libc.so.6
#1  0x407a2872 in raise () from /lib/libc.so.6
#2  0x407a3986 in abort () from /lib/libc.so.6
#3  0x082b66df in lyx::abort() () at abort.C:9
#4  0x081d0e9e in ControlInsetInsetExternal, 
InsetExternal::Params::params()
(this=0x84c3ef8) at ../../../src/support/LAssert.h:24
#5  0x081dce4b in QExternal::apply() (this=0x84c3f90) at QExternal.C:84
#6  0x081cfea6 in ControlInsetInsetExternal, 
InsetExternal::Params::apply() (
this=0x84c3ef8) at 
../../../src/frontends/controllers/ControlInset.tmpl:127
#7  0x08211f68 in ControlButtons::ApplyButton() (this=0x84c3ef8)
at ControlButtons.C:31
#8  0x081fade0 in Qt2Base::slotApply() (this=0x84c3f90)
at ../../../src/frontends/controllers/ViewBase.h:56
#9  0x082064df in Qt2Base::qt_invoke(int, QUObject*) (this=0x84c3f90, 
_id=5,
_o=0xb2e0) at Qt2Base_moc.C:95
#10 0x402591ce in QObject::activate_signal(QConnectionList*, QUObject*) ()
   from /usr/lib/libqt-mt.so.3
#11 0x4025910f in QObject::activate_signal(int) () from 
/usr/lib/libqt-mt.so.3
#12 0x404c6024 in QButton::clicked() () from /usr/lib/libqt-mt.so.3
#13 0x402cd5d4 in QButton::mouseReleaseEvent(QMouseEvent*) ()
   from /usr/lib/libqt-mt.so.3
#14 0x402865d3 in QWidget::event(QEvent*) () from /usr/lib/libqt-mt.so.3
#15 0x40205206 in QApplication::internalNotify(QObject*, QEvent*) ()
   from /usr/lib/libqt-mt.so.3
#16 0x40204abe in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/libqt-mt.so.3
#17 0x401b3afa in QETWidget::translateMouseEvent(_XEvent const*) ()
   from /usr/lib/libqt-mt.so.3
#18 0x401b193b in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/libqt-mt.so.3
#19 0x401c46cd in QEventLoop::processEvents(unsigned) ()
   from /usr/lib/libqt-mt.so.3
#20 0x402167c7 in QEventLoop::enterLoop() () from /usr/lib/libqt-mt.so.3
#21 0x40216684 in QEventLoop::exec() () from /usr/lib/libqt-mt.so.3
#22 0x40205400 in QApplication::exec() () from /usr/lib/libqt-mt.so.3
#23 0x081d2b01 in lyx_gui::start(std::string const, 
std::vectorstd::string, std::allocatorstd::string  const) 
([EMAIL PROTECTED], [EMAIL PROTECTED])
at lyx_gui.C:169
#24 0x080d5656 in LyX (this=0xbca0, [EMAIL PROTECTED], argv=0xbd54)
at ../src/lyx_main.C:166
#25 0x081045f5 in main (argc=1, argv=0xbd54) at ../src/main.C:31

quote behaviour in Lyx Code environment

[Christian Ridderström]

Hi

I'm confused by the behavour of quotes... First there is the 
difference in behaviour when comparing a Standard environment to the 
Lyx-Code envionment. Here's how it works for me:

Environment Key Lyx Xdvi
 Standard   a  - ``astart dbl. quoteaend dbl. quote
 Lyx-Code   a  - ''a''   start dbl. quoteastart dbl.quote

I can see the point of having a different behaviour in Lyx-Code, but
there I would really prefer this behaviour:
 Lyx-Code   a  - a a
... especially for writing code snippets.

Is it possible to have different key bindings depending on what layout you 
are using? Then you could solve this by mapping '' to different 
LFUN's...

Another aspect of this is how the UI works. The setting
(Layout-Document-Language-Quote style) only affects the behaviour of 
quotes that you add after changing the setting...

I was actually expecting all quotes to change when I changed this setting 
since it was under the Laout-Document... AFAIK, all the other settings 
affects the entire document, and not just stuff that you add.

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: What does this error statement mean?

[Kuba Ober]

On czwartek 06 marzec 2003 12:10 am, [EMAIL PROTECTED] wrote:
 Hello,

 With CJK-LyX-1.3.0, lyx crashes while loading a long lyx file created with
 CJK-LyX-1.2.1. Sometimes lyx loads the file, but still it crashes during
 scrolling down or up inside the file. No backtrace debug statements,except

 Couldn't get registers: No such process.

Probably that by the time gdb was being used to try to attach to the dying 
LyX, the process had vanished.

It's not an error in LyX per se, it's an error during the 
backtrace/registers/stack recovery of a dead LyX.

Or that's what I make of it ;-)

Cheers, Kuba Ober

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote:

 But we do this already we calculate all the matrices for drawing and
 in the draw function we (most of the time) do just drawing and that
 is pretty fast!) or what do you think do we use the LyXText inside
 the InsetText for?

If this was true, CHANGED_IN_DRAW would not exist.

regards
john

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 09:17:12AM +0100, Andre Poenitz wrote:

 the drawing part. At this point probably all insets need the separation of
 their individual draw() functions into metrics() and [real] draw(). 

Net effect: the insettexts run through all the calculations entirely
twice. Doesn't sound like a great idea ...

regards
john

Re: Fun with updating

[John Levon]

On Thu, Mar 20, 2003 at 09:27:59AM +0100, Juergen Vigna wrote:

 I would have been *really* surprised if you would have figured out a
 better way in one day, do you know how long I worked on this stuff to
 make it work as it is now.

heh :))

At this stage I just want to understand the basics first.

 The only way I see to fix the whole lot is that we would have to update
 the deepest insets first. I'm pretty sure there is a good algoritmus for

Well, can you explain why calling insettext-update(reinit == true)
inside the insetminipage thing doesn't work ? That's alll I want to know
and after about 50 printf's, I'm still stuck.

 What I don't like in all this is the removal of the mark_dirty flag
 how do you do now to set the dirty flag on the buffer? (I admit I had
 only a fast look at your patch).

This is the final part of an earlier patch - we look at the lfun
definition and decide from that whether we modified the buffer

regards,
john

Re: Fun with updating

[John Levon]

On Thu, Mar 20, 2003 at 09:32:01AM +0100, Andre Poenitz wrote:

  HA ! That's a bloody joke. This doesn't work. I have absolutely no idea
  why, of course. This update stuff is entirely beyond understanding.
 
 But a two-stage approach is, isn't it?

Andre, how do you possibly expect me to be able to do this when I can't
make head or tail of the existing code ? This is not something you can
just hack around in, as you'd discover if you tried it ...

regards
john

Re: inset_apply bug

[John Levon]

On Thu, Mar 20, 2003 at 09:24:20AM +0100, Andre Poenitz wrote:

 On Wed, Mar 19, 2003 at 05:35:09PM +, John Levon wrote:
  LFUN_INSET_MODIFY needs to do an updateInset() on the given inset,
  it may change shape (e.g. minipage). This requires moving updateInset()
  into InsetBase I guess ...
 
 No problem.

Ahh, if only 'twere that simple :)

john

Re: [PATCH] more ert stuff

[John Levon]

On Thu, Mar 20, 2003 at 09:33:29AM +0100, Juergen Vigna wrote:

 IMO this should be pretty safe to apply.

OK thanks. (Review from someone who follows the code is very helpful to
me :))

regards
john

Re: lyx 1.3.2cvs qt backtrace of crash when closing external inset.

[John Levon]

On Thu, Mar 20, 2003 at 11:01:23AM +0100, Helge Hafting wrote:

 Closing an external inset in lyx-1.3.1 or 1.3.2cvs may crash. It is 
 reproducible
 with one of my files, the backtrace is at the end of this message.

Damnit, how the hell did this happen :(

I'll look into it - time to build 1.3 with qt ...

john

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 01:51:50PM +, John Levon wrote:
  the drawing part. At this point probably all insets need the separation of
  their individual draw() functions into metrics() and [real] draw(). 
 
 Net effect: the insettexts run through all the calculations entirely
 twice. Doesn't sound like a great idea ...

First of all, twice might be better than what we have now. 

Secondly, why should it do the calculation twice?
The draw step consists only of put string 'foo' at position 'pos'

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 03:02:55PM +0100, Andre Poenitz wrote:

 First of all, twice might be better than what we have now. 

This is (incorrectly) assuming that just splitting the thing into two
doesn't mean we don't need to do things multiple times still. It's all
very well to talk about some hypothetical code base at some point in the
future, but that is not what we have now, and not what I have will have
to make working.

 Secondly, why should it do the calculation twice?
 The draw step consists only of put string 'foo' at position 'pos'

And where do these positions come from ? Cached ? AIUI that's not what
mathed does. So, you end up doing all the metrics again during the draw.
Or you cache it and have some *very* fragile semantics of when a cache
should be cleared or not.

regards
john

Re: quote behaviour in Lyx Code environment

[Helge Hafting]

Christian Ridderström wrote:
Hi

I'm confused by the behavour of quotes... First there is the 
difference in behaviour when comparing a Standard environment to the 
Lyx-Code envionment. Here's how it works for me:

Another aspect of this is how the UI works. The setting
(Layout-Document-Language-Quote style) only affects the behaviour of 
quotes that you add after changing the setting...
[...]
I was actually expecting all quotes to change when I changed this setting 
since it was under the Laout-Document... AFAIK, all the other settings 
affects the entire document, and not just stuff that you add.
If it changed all, how would you write a document with different
quoting styles?  The typical example here is several
quotes nested inside each other, the second level is usually
typeset with a different style.
Or you could have a text quoting a dialog, using
different quotes for the two persons.
Helge Hafting

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 02:23:17PM +, John Levon wrote:
 This is (incorrectly) assuming that just splitting the thing into two
 doesn't mean we don't need to do things multiple times still.

Not more than once per redraw.

  Secondly, why should it do the calculation twice?
  The draw step consists only of put string 'foo' at position 'pos'
 
 And where do these positions come from ? Cached ?

Cached from the previous metrics() run.

 AIUI that's not what mathed does. So, you end up doing all the metrics
 again during the draw.

draw() 
{
metrics();
  real_draw(); 
}

 Or you cache it and have some *very* fragile
 semantics of when a cache should be cleared or not.

Maybe cache is the wrong word. It was originally intended as a cache but
as it turned out fast enough I decided not to try real caching and
instead re-calculate on each draw(). However, using it as a cache is
possible, and I had it running at some point of time, the problem was the
macro folding.

This is similar to line rebreaks in the outer world, so yes, real caching
might be difficult to achieve, but as one shot cache it just works fine.

Maybe I really should not call it 'cache'.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 03:47:01PM +0100, Andre Poenitz wrote:

  This is (incorrectly) assuming that just splitting the thing into two
  doesn't mean we don't need to do things multiple times still.
 
 Not more than once per redraw.

OK,  what is your magical solution to the inset update problem. With
details please ...

 This is similar to line rebreaks in the outer world, so yes, real caching
 might be difficult to achieve, but as one shot cache it just works fine.
 
 Maybe I really should not call it 'cache'.

Well, I think I follow you a bit better now. In fact,  that is what I am
trying to do ! Basically make sure all inset updates have been done by
the time we actually call draw. But it is beyond my ken (I cannot even
get one small part of this to work, in fact).

We could queue inset updates and do them all after an lfun etc, but I
don't see how to get the sensible ordering of innermost-outermost.

john

Re: top_y() is killing us

[Juergen Vigna]

John Levon wrote:
On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote:


But we do this already we calculate all the matrices for drawing and
in the draw function we (most of the time) do just drawing and that
is pretty fast!) or what do you think do we use the LyXText inside
the InsetText for?


If this was true, CHANGED_IN_DRAW would not exist.
I said most of the times, didn't I? This means we need to redo
the calculations if at the time we get to the draw routine the
drawing tells us we don't have all the space we thought we had.
The problem is that we have this information for now only when the
draw function is really called :(
  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: top_y() is killing us

[Juergen Vigna]

John Levon wrote:
Well, I think I follow you a bit better now. In fact,  that is what I am
trying to do ! Basically make sure all inset updates have been done by
the time we actually call draw. But it is beyond my ken (I cannot even
get one small part of this to work, in fact).
As I told you in my earlier mail some informations you have only when
you are in the real draw function, well actually we are interested for
a test-rebreak only in the x position as if this changes it means we
have to rebreak the whole text inside the inset.
This is also the difference between an InsetText and a InsetMath as
mathed does not care how large it will become and this assumption takes
out the whole complexitiy!
We could queue inset updates and do them all after an lfun etc, but I
don't see how to get the sensible ordering of innermost-outermost.
That's the problem!

  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 04:07:25PM +0100, Juergen Vigna wrote:

 I said most of the times, didn't I?

Ooops, so you did !

 This means we need to redo
 the calculations if at the time we get to the draw routine the
 drawing tells us we don't have all the space we thought we had.

Are you aware how rare this actually is ? In my tests, I had trouble
finding a situation where the width changed in draw() and we hadn't
previously called update() with the new width already set...

 The problem is that we have this information for now only when the
 draw function is really called :(

Can you describe an exact circumstance ? I'll add some printf's and a
getMaxWidth()  thingy in update() to see when it does actually happen.

In the meantime, a  solution to the FIXME in insetminipage.C would be
greatly welcomed :)

thanks,
john

easy lyx crash

[Jos van den Oever]

Hello lyx developers,

I just crashed lyx 1.3.1. The recipe is easy:
- open lyx
- press Alt-F to open the File menu
- press i (for import, which is not acivated and the cause of the problem)
- press right arrow
crash

I've tested on SuSE 8.0 and RedHat phoebe-3 (latest beta).

Good luck with further development!

Jos

Re: Fun with updating

[Juergen Vigna]

John Levon wrote:
Well, can you explain why calling insettext-update(reinit == true)
inside the insetminipage thing doesn't work ? That's alll I want to know
and after about 50 printf's, I'm still stuck.
Because you do it at the wrong spot! Try to printf x() and then after
it drawed it wrong (or inside the draw function) also the x(), you will
see they changed. I explained this in the earlier mails.
This is the final part of an earlier patch - we look at the lfun
definition and decide from that whether we modified the buffer
Good! Seems a nice way to do it!

 Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: Fun with updating

[John Levon]

On Thu, Mar 20, 2003 at 04:19:02PM +0100, Juergen Vigna wrote:

 Well, can you explain why calling insettext-update(reinit == true)
 inside the insetminipage thing doesn't work ? That's alll I want to know
 and after about 50 printf's, I'm still stuck.
 
 Because you do it at the wrong spot!

Why is it the wrong spot ? Can you explain in simple terms ?

 Try to printf x() and then after
 it drawed it wrong (or inside the draw function) also the x(), you will
 see they changed.

Dude, I spent *hours* doing this, and could not see where or why it
didn't work. This is lots of printfs in various update() functions etc.

 I explained this in the earlier mails.

Where ?

 This is the final part of an earlier patch - we look at the lfun
 definition and decide from that whether we modified the buffer
 
 Good! Seems a nice way to do it!

It cleaned up things quite a bit actually ...

regards,
john

[PATCH] remove changed-in-draw

[John Levon]

Well Juergen I've given this some testing, and I haven't triggered
Darn, CID yet. Do you have, by any chance, some suggestions for
operations that might cause the CHANGED_IN_DRAW to happen ?

I'm going to commit this (maybe with an abort on CID ?) in a bit, and if
nothing happens after people like Garst et al trying it, remove
CID altogether. Though I guess that's dependent on fixing minipage/ert
...

regards,
john


Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.361
diff -u -p -r1.361 insettext.C
--- insets/insettext.C  20 Mar 2003 14:13:48 -  1.361
+++ insets/insettext.C  20 Mar 2003 16:15:10 -
@@ -360,6 +360,8 @@ void InsetText::draw(BufferView * bv, Ly
topx_set = true;
int nw = getMaxWidth(bv, this);
if (nw  0  old_max_width != nw) {
+   lyxerr  Darn, CID !  endl;
+   lyxerr  New is   nw   old is   old_max_width  
endl;
need_update = INIT;
old_max_width = nw;
bv-text-postChangedInDraw();
@@ -495,6 +497,7 @@ void InsetText::update(BufferView * bv, 
return;
}
in_update = true;
+
if (reinit || need_update == INIT) {
need_update = FULL;
// we should put this call where we set need_update to INIT!
@@ -502,6 +505,13 @@ void InsetText::update(BufferView * bv, 
if (owner())
owner()-update(bv, true);
in_update = false;
+   int nw = getMaxWidth(bv, this);
+   if (nw  0  old_max_width != nw) {
+   need_update |= INIT;
+   lyxerr  width changed in update  endl;
+   lyxerr  New is   nw   old is   old_max_width  
endl;
+   old_max_width = nw;
+   }
return;
}
 
@@ -529,6 +539,14 @@ void InsetText::update(BufferView * bv, 
if (clear)
lt = 0;
in_update = false;
+
+   int nw = getMaxWidth(bv, this);
+   if (nw  0  old_max_width != nw) {
+   need_update |= INIT;
+   lyxerr  width changed in update  endl;
+   lyxerr  New is   nw   old is   old_max_width  endl;
+   old_max_width = nw;
+   }
 }
 
 
Index: insets/updatableinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/updatableinset.C,v
retrieving revision 1.6
diff -u -p -r1.6 updatableinset.C
--- insets/updatableinset.C 19 Mar 2003 14:45:22 -  1.6
+++ insets/updatableinset.C 20 Mar 2003 16:15:11 -
@@ -179,7 +179,8 @@ int UpdatableInset::getMaxWidth(BufferVi
// this is needed as otherwise we might have a too large inset if
// its top_x afterwards changes to LeftMargin so we try to put at
// least the default margin as top_x
-   w -= 20;
+   #warning FIXME
+   //  w -= 20;
}
if (w  10) {
w = 10;

Re: Fun with updating

[Juergen Vigna]

John Levon wrote:
Why is it the wrong spot ? Can you explain in simple terms ?
I explained below, the x position is changing during draw and if that
happens we have to recalculate all!
Dude, I spent *hours* doing this, and could not see where or why it
didn't work. This is lots of printfs in various update() functions etc.
Only hours come on that's nothing in confront to how many time I spent
to make it work ;)
Where ?
Draw + x()!

  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: Fun with updating

[John Levon]

On Thu, Mar 20, 2003 at 05:30:23PM +0100, Juergen Vigna wrote:

 Draw + x()!

Ohh, Inset::x() ! Right ... which types of insettext actually care about
their x() position ? As I mentioned in my other mail + patch, a simple
test of a few scenarios couldn't cause any trouble

 Only hours come on that's nothing in confront to how many time I spent
 to make it work ;)

heh :)

john

Re: lyx 1.3.2cvs qt backtrace of crash when closing external inset.

[John Levon]

On Thu, Mar 20, 2003 at 11:01:23AM +0100, Helge Hafting wrote:

 Closing an external inset in lyx-1.3.1 or 1.3.2cvs may crash. It is 
 reproducible

Sheesh, well I'm a genius  I made a wrong patch,  fixed it, then
applied the wrong patch anyway and didn't notice. Great !

Expect a fix soon

thanks
john

Re: easy lyx crash

[John Levon]

On Thu, Mar 20, 2003 at 04:13:23PM +0100, Jos van den Oever wrote:

 I just crashed lyx 1.3.1. The recipe is easy:

xforms frontend ?

 - open lyx
 - press Alt-F to open the File menu
 - press i (for import, which is not acivated and the cause of the problem)

Why isn't the menu activated ?

It is for me as it should be.

john

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 02:59:04PM +, John Levon wrote:
  Not more than once per redraw.
 
 OK,  what is your magical solution to the inset update problem. With
 details please ...

Simple: There is no inset update problem as there won't be an inset update.

Handling an LFUN just changes the structure of the doc, the postion of the
cursor, whatever. It does not care about visual appearance at all.

If the handling is finished, we do a full redraw. [Later we might be a bit
more clever, but not now]. The full redraw consists of two phases. In
each phase the document tree is traversed in full and each phase carries
some information object containing objects like current font, current
textwidth etc.

The first phase is the metrics calculation. Each container (inset,
main text,...) adjusts the information object according to its needs (i.e.
a minipage would change the textwidth) and calls metrics() with this
information object on each of its children recursively. If this is
finished, the sizes of the children are known and the container itself can
compute its own size. Row breaking etc. would happen here. Afterwards it
saves this newly computed size in its local cache.

Example:

void MathFracInset::metrics(MathMetricsInfo  mi) const
{
// this locally changes fontsize, clean up on destruction of dummy
MathFracChanger dummy(mi.base);
// determine size of two children (numerator and denominator)
cell(0).metrics(mi);
cell(1).metrics(mi);
// compute our own size
dim_.w = max(cell(0).width(), cell(1).width()) + 2;
dim_.a = cell(0).height() + 2 + 5;
dim_.d = cell(1).height() + 2 - 5;
}

In the second phase, we go down the tree again passing another information
object around, containing an actual painter object and a position. Again,
apply local changes. Using the precomputed sizes we are able to tell the
childeren where to start their drawing. Tell them to do so. Then do our own
drawing. Undo local changes to the information object. Return.

Example:

void MathFracInset::draw(MathPainterInfo  pi, int x, int y) const
{
int m = x + width() / 2;
// this locally changes fontsize, clean up on destruction of dummy
MathFracChanger dummy(pi.base);
cell(0).draw(pi, m - cell(0).width() / 2, y - cell(0).descent() - 2 - 
5);
cell(1).draw(pi, m - cell(1).width() / 2, y + cell(1).ascent()  + 2 - 
5);
if (!atop_)
pi.pain.line(x + 1, y - 5, x + width() - 2, y - 5, 
LColor::math);
}



Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 04:14:38PM +0100, Juergen Vigna wrote:
 As I told you in my earlier mail some informations you have only when
 you are in the real draw function,

At the top most draw function, we would split drawing in two phases. So the
first phase knows everything already.

 This is also the difference between an InsetText and a InsetMath as
 mathed does not care how large it will become and this assumption takes
 out the whole complexitiy!

But it could take this into account easily.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 05:50:05PM +0100, Andre Poenitz wrote:

 Handling an LFUN just changes the structure of the doc, the postion of the
 cursor, whatever. It does not care about visual appearance at all.
 
 If the handling is finished, we do a full redraw. [Later we might be a bit
 more clever, but not now]. The full redraw consists of two phases. In
 each phase the document tree is traversed in full and each phase carries
 some information object containing objects like current font, current
 textwidth etc.
 
 The first phase is the metrics calculation. Each container (inset,
 main text,...) adjusts the information object according to its needs (i.e.
 a minipage would change the textwidth) and calls metrics() with this
 information object on each of its children recursively. If this is
 finished, the sizes of the children are known and the container itself can
 compute its own size. Row breaking etc. would happen here. Afterwards it

And how does it alter its *parent* when needed ? And its parent's parent ?

This sounds tremendously like what already exists Andre, except you
called update metrics instead,  and you do a full redraw of the
screen. It is doing this update/metrics traversal that is the
complicated bit !

regards,
john

Re: [PATCH] remove changed-in-draw

[John Levon]

On Thu, Mar 20, 2003 at 04:21:55PM +, John Levon wrote:

 Well Juergen I've given this some testing, and I haven't triggered
 Darn, CID yet. Do you have, by any chance, some suggestions for
 operations that might cause the CHANGED_IN_DRAW to happen ?

D'oh, didn't try too hard did I ...

minipage inside float will do it ... let me experiment further

john

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote:
 And how does it alter its *parent* when needed ?

Nothing knows about its parent except what it gets passed in the info
structure. 

By returning something in the info structure. When the parent starts doing
its calculations, the sizes of the children are fixed.

 This sounds tremendously like what already exists Andre, except you
 called update metrics instead,  and you do a full redraw of the
 screen. It is doing this update/metrics traversal that is the
 complicated bit !

It is a simple depth first tree traversal...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote:
 And how does it alter its *parent* when needed ? And its parent's parent ?

Ok, maybe I am realling missing the point:

In what circumstances does an inset have to alter its parent [that can't be
handled in the two-phase, parent-after-children approach]?

Juergen bases all his statements on the same theory that such a thing is
necessary, but I really can't see an example.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: easy lyx crash

[Dan Armak]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 20 March 2003 18:45, John Levon wrote:
 On Thu, Mar 20, 2003 at 04:13:23PM +0100, Jos van den Oever wrote:
 
  I just crashed lyx 1.3.1. The recipe is easy:
 
 xforms frontend ?
 
  - open lyx
  - press Alt-F to open the File menu
  - press i (for import, which is not acivated and the cause of the problem)
 
 Why isn't the menu activated ?
 
 It is for me as it should be.

Well, I can reproduce it too (incl. the menu shortcut not working - the menu 
item selection indicator just disappears). QT frontend (qt 3.1.2).

It says:
[EMAIL PROTECTED] danarmak $ lyx -dbg all
Setting debug level to all

I reproduce the crash
lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting instructions 
in Help-Introduction and send us a bug report, if necessary. Thanks !
Bye.
Aborted

No time to do more testing right now, but it does happen.

- -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+efm0UI2RQ41fiVERAobDAJ0Z2rfyBiyq5Rx/3htd4krUXIjT/QCfUkOA
vGI5PVfFjfnW2bPIaI3/+xU=
=WHco
-END PGP SIGNATURE-

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 06:08:44PM +0100, Andre Poenitz wrote:

  And how does it alter its *parent* when needed ? And its parent's parent ?
 
 Ok, maybe I am realling missing the point:
 
 In what circumstances does an inset have to alter its parent [that can't be
 handled in the two-phase, parent-after-children approach]?

minipage is 45% of column width. Minipage is inside a table column that
we have just altered to have a fixed width of 2 inches. The width of
this column dictates the minipage width which dictates the breaking of
the cell which dictates the height of the minipage's row which dictates
the height of the table which dictates the height of the float which
contains the table which dictates the height of the outermost row.

Things like that...

Simpler example: inlined ERT. Its contents (changed when you type a
character) need to size to the contents. Now you're about to say : well
the parent should enquire its child for its size in the first phase ?
That is essentially what is happening now !

regards
john

Re: quote behaviour in Lyx Code environment

[Christian Ridderström]

On Thu, 20 Mar 2003, Helge Hafting wrote:

  I was actually expecting all quotes to change when I changed this setting 
  since it was under the Laout-Document... AFAIK, all the other settings 
  affects the entire document, and not just stuff that you add.
 
 If it changed all, how would you write a document with different
 quoting styles?

Here's one way you could do it:
You add a generic quote type, where the style used in the output 
depends on the setting in Layout-Document...  But you will still be able 
to insert quotes of a specific style. Then, only the generic quotes 
will change in the output when you change the Layout-Document setting.

A remaining question is of course how you choose between inserting 
generic quotes rather than specific quotes. Today, this is 
what is controlled by the setting in Layout-Document.

I find it confusing/unintuitive that all other settings in Layout-Document 
work on the entire document. So I guess I'm really complaining about the 
placement of this setting. I feel it doesn't belong where it is, maybe 
it'd be better of as:

Layout-Quote mode

So I guess this basically boils down to me thinking that this setting 
should be moved.

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

[PATCH] changed-in-draw killing #2

[John Levon]

People are encouraged to try this one !

Note the horrible hack in updateableinset.C. I have to admit I can't
convince myself of why this works, but it does ... and it has to be
better than all the CID code (which  this patch does *not* remove - the
CID code totals at least another 80 lines)

OK ?

john


Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.361
diff -u -p -r1.361 insettext.C
--- insets/insettext.C  20 Mar 2003 14:13:48 -  1.361
+++ insets/insettext.C  20 Mar 2003 19:41:36 -
@@ -360,6 +360,8 @@ void InsetText::draw(BufferView * bv, Ly
topx_set = true;
int nw = getMaxWidth(bv, this);
if (nw  0  old_max_width != nw) {
+   lyxerr  Darn, CID !  endl;
+   lyxerr  New is   nw   old is   old_max_width  
endl;
need_update = INIT;
old_max_width = nw;
bv-text-postChangedInDraw();
@@ -495,6 +497,7 @@ void InsetText::update(BufferView * bv, 
return;
}
in_update = true;
+
if (reinit || need_update == INIT) {
need_update = FULL;
// we should put this call where we set need_update to INIT!
@@ -502,6 +505,13 @@ void InsetText::update(BufferView * bv, 
if (owner())
owner()-update(bv, true);
in_update = false;
+   int nw = getMaxWidth(bv, this);
+   if (nw  0  old_max_width != nw) {
+   need_update |= INIT;
+   lyxerr  width changed in update  endl;
+   lyxerr  New is   nw   old is   old_max_width  
endl;
+   old_max_width = nw;
+   }
return;
}
 
@@ -529,6 +539,14 @@ void InsetText::update(BufferView * bv, 
if (clear)
lt = 0;
in_update = false;
+
+   int nw = getMaxWidth(bv, this);
+   if (nw  0  old_max_width != nw) {
+   need_update |= INIT;
+   lyxerr  width changed in update  endl;
+   lyxerr  New is   nw   old is   old_max_width  endl;
+   old_max_width = nw;
+   }
 }
 
 
Index: insets/updatableinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/updatableinset.C,v
retrieving revision 1.6
diff -u -p -r1.6 updatableinset.C
--- insets/updatableinset.C 19 Mar 2003 14:45:22 -  1.6
+++ insets/updatableinset.C 20 Mar 2003 19:41:36 -
@@ -160,9 +160,9 @@ Inset::RESULT UpdatableInset::localDispa
 int UpdatableInset::getMaxWidth(BufferView * bv, UpdatableInset const *) const
 {
int w;
+
if (owner()) {
-   w = static_castUpdatableInset*
-   (owner())-getMaxWidth(bv, this);
+   w = static_castUpdatableInset* (owner())-getMaxWidth(bv, this);
} else {
w = bv-text-workWidth(const_castUpdatableInset *(this));
}
@@ -172,6 +172,14 @@ int UpdatableInset::getMaxWidth(BufferVi
// check for margins left/right and extra right margin const 5
if ((w - ((2 * TEXT_TO_INSET_OFFSET) + 5)) = 0)
w -= (2 * TEXT_TO_INSET_OFFSET) + 5;
+
+   // Deep magic. I don't understand this either.
+   if (owner()  owner()-owner()) {
+   // add the right paper margin
+   w -= 40;
+   }
+
+#if 0
if (topx_set  owner()) {
w -= top_x;
w += owner()-x();
@@ -181,6 +189,7 @@ int UpdatableInset::getMaxWidth(BufferVi
// least the default margin as top_x
w -= 20;
}
+#endif
if (w  10) {
w = 10;
}

lyxtexts insettext

[John Levon]

Can somebody give me a brief summary of how/why this works ?

Especially, why can't we reinitLyXText when lt is non-null ?

thanks
john

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 05:38:44PM +, John Levon wrote:
 minipage is 45% of column width. Minipage is inside a table column that
 we have just altered to have a fixed width of 2 inches. The width of
 this column dictates the minipage width which dictates the breaking of
 the cell which dictates the height of the minipage's row which dictates
 the height of the table which dictates the height of the float which
 contains the table which dictates the height of the outermost row.

So we'd just change the width.

Once the next redraw starts, the table column tells its child in the
metrics() phase that \textwidth is 2 inches. Minipage adjusts accordingly
and stores a width of 2 inches and whatever height it just determined. The
table column can figure out its height from that. The enclosing float
determines its size from the table.

There is no need whatsoever for the minipage to know that it is enclosed by
something, it will be told in due time about restrictions in the
environment it lives it (i.e. by saying textwidth=2 inches in the metrics
phase)

 Simpler example: inlined ERT. Its contents (changed when you type a
 character) need to size to the contents. Now you're about to say : well
 the parent should enquire its child for its size in the first phase ?
 That is essentially what is happening now !

So why do we see several updates per redraw?

Why does an inset communicate explicitly with its parent?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[Juergen Vigna]

Andre Poenitz wrote:
So what about the two-stage drawing?

Give the insets a small cache of width/ascent/descent (you could steal from
math_diminset I suppose), fill the cache of an inset in the first stage
according to the size of the contents of the inset, and do all the drawing
in the second stage...
But we do this already we calculate all the matrices for drawing and
in the draw function we (most of the time) do just drawing and that
is pretty fast!) or what do you think do we use the "LyXText" inside
the InsetText for?
  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: Fun with updating

[Juergen Vigna]

John Levon wrote:
Juergen, can you help ? What would you say if I suggest ripping the font
paramter from inset->update ?
I would say this could be a good idea. Just define a "default" font
for an empty CellInset and pass that one instead. IMO this is the best
solution and you're able to rip out the LyXFont parameter.
Would that be an option?

   Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: top_y() is killing us

[Andre Poenitz]

On Wed, Mar 19, 2003 at 05:12:56PM +, John Levon wrote:
> > Give the insets a small cache of width/ascent/descent (you could steal from
> > math_diminset I suppose), fill the cache of an inset in the first stage
> > according to the size of the contents of the inset, and do all the drawing
> > in the second stage...
> 
> I'm not sure the actual drawing is slowest, it's not showing up big time
> in the profiles. Things like singleWidth() are.

I am not suggesting otherwise. But by clearly separating metrics computation
and actual drawing we make sure that "things like singleWitdh()" are called
only once per redraw.

> I'm not really sure how I'd implement what you're suggesting anyway. We
> already have inset->width() ...

Look at what mathed does: At a very high level (i.e InsetFormula::draw) the
work is split. The first call to width() calls metrics()  [ok, this is
messy, but currently the easiest way to make sure that metrics() is called
after loading of a buffer, too]. Afterwards, the real draw part is done, by
calling the nested inset's draw() [which do not contain metrics
computations anymore]

We should move this separation to a higher level. I.e. whatever calls
InsetFormula::draw() should first call InsetFormula::metrics() and the only
the drawing part. At this point probably all insets need the separation of
their individual draw() functions into metrics() and [real] draw(). 

> And I seriously doubt I have enough understanding to do it. I have never
> worked out what the hell Inset::scroll() does, for example.
> Or the exact semantics of InsetCollapsable::need_update.

Neither have I...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: Fun with updating

[Juergen Vigna]

John Levon wrote:
HA ! That's a bloody joke. This doesn't work. I have absolutely no idea
why, of course. This update stuff is entirely beyond understanding. Just
dealing with the bv->updateInset() vs. bv->update() vs. bv->update(blah)
vs. inset->update() vs. inset->updateInsetInInset() vs lyxtext->update()
vs. lyxtext->updateInset() [1] isn't too bad, but the semi-recursive
nature and delayed insettext state update thing makes it impossible.
I've spent 2 solid hours trying to work out the correct way of forcing
an update of a minipage, no go. Pretty pissed off ...
I would have been *really* surprised if you would have figured out a
better way in one day, do you know how long I worked on this stuff to
make it work as it is now.
The only way I see to fix the whole lot is that we would have to update
the deepest insets first. I'm pretty sure there is a good algoritmus for
this and if one goes and concentrates on the problem I'm pretty sure we
come up with something working. As I told you we have to update the
deepest insets first and then from there come up. Obviously at each level
we can have more then just 1 inset and that is what complicates all of
it, but as I said I'm pretty confident that there is a better way to
solve this as the actual one which (I admit it) is pretty hard to
understand and far away from the best way to do it.
I've done this anyway, since it doesn't make things worse. I'm
committing the lot below tomorrow.
Ok you did it as I expected. Defined a fixed font for the empty tabular
cell font.
What I don't like in all this is the removal of the "mark_dirty" flag
how do you do now to set the dirty flag on the buffer? (I admit I had
only a fast look at your patch).
   Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: [PATCH] move need_update handling into insetert

[Juergen Vigna]

John Levon wrote:
This fixes a long-standing bug, for some reason (namely, switch from
closed to inlined did not correctly recalculate the width), but does not
fix an *existing* bug that is new to 1.4.0cvs (bug 965). Jug, if you're
listening: why doesn't the insettext->update() correctly deal with the
cursor positioning changing ?
But really this is a matter of a start of cleanup, only insetert uses
the insetcollapsable need_update handling, so it should go there.
It also doesn't yet fix bug 966, which is old.

OK ?
IMO this is ok if this need_update is only used in InsetERT then this
surely is wrong.
 Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: inset_apply bug

[Andre Poenitz]

On Wed, Mar 19, 2003 at 05:35:09PM +, John Levon wrote:
> LFUN_INSET_MODIFY needs to do an updateInset() on the given inset,
> it may change shape (e.g. minipage). This requires moving updateInset()
> into InsetBase I guess ...

No problem.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: [PATCH] more ert stuff

[Juergen Vigna]

John Levon wrote:
This is a more recent version, that also fixes bug 966. We were not
checking for size(text) < size(button) in the ERT draw. This was fixed
by merging  the duplicated code.
IMO this should be pretty safe to apply.

  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: top_y() is killing us

[Juergen Vigna]

Andre Poenitz wrote:
Look at what mathed does: At a very high level (i.e InsetFormula::draw) the
work is split. The first call to width() calls metrics()  [ok, this is
messy, but currently the easiest way to make sure that metrics() is called
after loading of a buffer, too]. Afterwards, the real draw part is done, by
calling the nested inset's draw() [which do not contain metrics
computations anymore]
I told you this already a lot of times, the redraw of mathed is "really"
easy to do. You have all fixed width insets and the don't do a rebreak or
resize themselfs to their environment. You cannot compare this to the
complexity of InsetText you may compare this to a inset like lets say
a InsetTabular if we wouldn't have the posibility of autobreaking rows
(as it was in the first draft of the inset).
  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: Fun with updating

[Andre Poenitz]

On Wed, Mar 19, 2003 at 09:35:15PM +, John Levon wrote:
> So it's looking very much like Andre's two-stage thingy at this point,
> just to solve a tiny bit of this :(

"Alejandro's two-stage thingy".

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: Fun with updating

[Andre Poenitz]

On Thu, Mar 20, 2003 at 03:06:48AM +, John Levon wrote:
> On Wed, Mar 19, 2003 at 09:35:15PM +, John Levon wrote:
> 
> > This is fun. Insets like InsetMinipage and InsetERT can have e.g.
> > INSET_MODIFY applied to them. This can actually alter its size. It
> > actually needs to tell its contained InsetText to ->update(reinit ==
> > true);
> 
> HA ! That's a bloody joke. This doesn't work. I have absolutely no idea
> why, of course. This update stuff is entirely beyond understanding.

But a two-stage approach is, isn't it?

Andre'


-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 09:36:38AM +0100, Juergen Vigna wrote:
> I told you this already a lot of times, the redraw of mathed is "really"
> easy to do. You have all fixed width insets and the don't do a rebreak or
> resize themselfs to their environment. You cannot compare this to the
> complexity of InsetText you may compare this to a inset like lets say
> a InsetTabular if we wouldn't have the posibility of autobreaking rows
> (as it was in the first draft of the inset).

And I still do not believe that this makes a big difference.

Btw, this is not exactly true: Whenever you change a macro definition, the
size of the macro's expansions change, too.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

[patch] fix bug 964

[Alfredo Braunstein]

Duh! Please apply.

Alfredo
Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/ChangeLog,v
retrieving revision 1.1136
diff -u -p -u -r1.1136 ChangeLog
--- ChangeLog	2003/03/19 18:43:55	1.1136
+++ ChangeLog	2003/03/20 08:53:34
@@ -1,3 +1,7 @@
+2003-03-20  Alfredo Braunstein  <[EMAIL PROTECTED]>
+
+	* text2.C (removeRow): fix bug 964
+
 2003-03-19  John Levon  <[EMAIL PROTECTED]>
 
 	* lyxfunc.C: only fitcursor/markDirty if available()
Index: text2.C
===
RCS file: /cvs/lyx/lyx-devel/src/text2.C,v
retrieving revision 1.295
diff -u -p -u -r1.295 text2.C
--- text2.C	2003/03/19 14:45:15	1.295
+++ text2.C	2003/03/20 08:53:37
@@ -334,7 +334,7 @@ void LyXText::removeRow(Row * row)
 	if (anchor_row_ == row) {
 		if (row_prev) {
 			anchor_row_ = row_prev;
-			anchor_row_offset_ = 0;
+			anchor_row_offset_ += row_prev->height();
 		} else {
 			anchor_row_ = row->next();
 			anchor_row_offset_ -= row->height();

Re: Crash recipe

[Lars Gullik Bjønnes]

"Garst R. Reese" <[EMAIL PROTECTED]> writes:

| Open newfile
| enter Ctrl space
| hit enter
| hit backspace
| boom
| current 1.4CVS

Crash or assert?
(it is an assert if it says "abort" instead of segfault...)

-- 
Lgb

Re: top_y() is killing us

[Juergen Vigna]

Andre Poenitz wrote:
And I still do not believe that this makes a big difference.
Well this is up to you

 Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

lyx 1.3.2cvs qt backtrace of crash when closing external inset.

[Helge Hafting]

Closing an external inset in lyx-1.3.1 or 1.3.2cvs may crash. It is 
reproducible
with one of my files, the backtrace is at the end of this message.

I'm using gcc/g++ 3.2 and qt3 from debian unstable.
The crash is reproduced like this:
Start lyx, open file
scroll to the external inset
bring up the external inset dialog.
change something, such as the parameter to the external converter
Press the close button, and lyx dies and do the emergency save.
The backtrace is for lyx-1.3.2cvs, updated ten minutes before sending this.

Helge Hafting

#0  0x407a2a51 in kill () from /lib/libc.so.6
#1  0x407a2872 in raise () from /lib/libc.so.6
#2  0x407a3986 in abort () from /lib/libc.so.6
#3  0x082b66df in lyx::abort() () at abort.C:9
#4  0x081d0e9e in ControlInset::params()
(this=0x84c3ef8) at ../../../src/support/LAssert.h:24
#5  0x081dce4b in QExternal::apply() (this=0x84c3f90) at QExternal.C:84
#6  0x081cfea6 in ControlInset::apply() (
this=0x84c3ef8) at 
../../../src/frontends/controllers/ControlInset.tmpl:127
#7  0x08211f68 in ControlButtons::ApplyButton() (this=0x84c3ef8)
at ControlButtons.C:31
#8  0x081fade0 in Qt2Base::slotApply() (this=0x84c3f90)
at ../../../src/frontends/controllers/ViewBase.h:56
#9  0x082064df in Qt2Base::qt_invoke(int, QUObject*) (this=0x84c3f90, 
_id=5,
_o=0xb2e0) at Qt2Base_moc.C:95
#10 0x402591ce in QObject::activate_signal(QConnectionList*, QUObject*) ()
   from /usr/lib/libqt-mt.so.3
#11 0x4025910f in QObject::activate_signal(int) () from 
/usr/lib/libqt-mt.so.3
#12 0x404c6024 in QButton::clicked() () from /usr/lib/libqt-mt.so.3
#13 0x402cd5d4 in QButton::mouseReleaseEvent(QMouseEvent*) ()
   from /usr/lib/libqt-mt.so.3
#14 0x402865d3 in QWidget::event(QEvent*) () from /usr/lib/libqt-mt.so.3
#15 0x40205206 in QApplication::internalNotify(QObject*, QEvent*) ()
   from /usr/lib/libqt-mt.so.3
#16 0x40204abe in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/libqt-mt.so.3
#17 0x401b3afa in QETWidget::translateMouseEvent(_XEvent const*) ()
   from /usr/lib/libqt-mt.so.3
#18 0x401b193b in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/libqt-mt.so.3
#19 0x401c46cd in QEventLoop::processEvents(unsigned) ()
   from /usr/lib/libqt-mt.so.3
#20 0x402167c7 in QEventLoop::enterLoop() () from /usr/lib/libqt-mt.so.3
#21 0x40216684 in QEventLoop::exec() () from /usr/lib/libqt-mt.so.3
#22 0x40205400 in QApplication::exec() () from /usr/lib/libqt-mt.so.3
#23 0x081d2b01 in lyx_gui::start(std::string const&, 
std::vector const&) 
([EMAIL PROTECTED], [EMAIL PROTECTED])
at lyx_gui.C:169
#24 0x080d5656 in LyX (this=0xbca0, [EMAIL PROTECTED], argv=0xbd54)
at ../src/lyx_main.C:166
#25 0x081045f5 in main (argc=1, argv=0xbd54) at ../src/main.C:31

quote behaviour in Lyx Code environment

[Christian Ridderström]

Hi

I'm confused by the behavour of quotes... First there is the 
difference in behaviour when comparing a Standard environment to the 
Lyx-Code envionment. Here's how it works for me:

Environment Key Lyx Xdvi
 Standard   "a"  -> ``a"a
 Lyx-Code   "a"  -> ''a''   a

I can see the point of having a different behaviour in Lyx-Code, but
there I would really prefer this behaviour:
 Lyx-Code   "a"  -> "a" "a"
... especially for writing code snippets.

Is it possible to have different key bindings depending on what layout you 
are using? Then you could solve this by mapping '"' to different 
LFUN's...

Another aspect of this is how the UI works. The setting
(Layout->Document->Language->Quote style) only affects the behaviour of 
quotes that you add after changing the setting...

I was actually expecting all quotes to change when I changed this setting 
since it was under the Laout->Document... AFAIK, all the other settings 
affects the entire document, and not just stuff that you add.

/Christian

-- 
Christian Ridderström   http://www.md.kth.se/~chr

Re: What does this error statement mean?

[Kuba Ober]

On czwartek 06 marzec 2003 12:10 am, [EMAIL PROTECTED] wrote:
> Hello,
>
> With CJK-LyX-1.3.0, lyx crashes while loading a long lyx file created with
> CJK-LyX-1.2.1. Sometimes lyx loads the file, but still it crashes during
> scrolling down or up inside the file. No backtrace debug statements,except
>
> "Couldn't get registers: No such process."

Probably that by the time gdb was being used to try to attach to the dying 
LyX, the process had vanished.

It's not an error in LyX per se, it's an error during the 
backtrace/registers/stack recovery of a dead LyX.

Or that's what I make of it ;-)

Cheers, Kuba Ober

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote:

> But we do this already we calculate all the matrices for drawing and
> in the draw function we (most of the time) do just drawing and that
> is pretty fast!) or what do you think do we use the "LyXText" inside
> the InsetText for?

If this was true, CHANGED_IN_DRAW would not exist.

regards
john

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 09:17:12AM +0100, Andre Poenitz wrote:

> the drawing part. At this point probably all insets need the separation of
> their individual draw() functions into metrics() and [real] draw(). 

Net effect: the insettexts run through all the calculations entirely
twice. Doesn't sound like a great idea ...

regards
john

Re: Fun with updating

[John Levon]

On Thu, Mar 20, 2003 at 09:27:59AM +0100, Juergen Vigna wrote:

> I would have been *really* surprised if you would have figured out a
> better way in one day, do you know how long I worked on this stuff to
> make it work as it is now.

heh :))

At this stage I just want to understand the basics first.

> The only way I see to fix the whole lot is that we would have to update
> the deepest insets first. I'm pretty sure there is a good algoritmus for

Well, can you explain why calling insettext->update(reinit == true)
inside the insetminipage thing doesn't work ? That's alll I want to know
and after about 50 printf's, I'm still stuck.

> What I don't like in all this is the removal of the "mark_dirty" flag
> how do you do now to set the dirty flag on the buffer? (I admit I had
> only a fast look at your patch).

This is the final part of an earlier patch - we look at the lfun
definition and decide from that whether we modified the buffer

regards,
john

Re: Fun with updating

[John Levon]

On Thu, Mar 20, 2003 at 09:32:01AM +0100, Andre Poenitz wrote:

> > HA ! That's a bloody joke. This doesn't work. I have absolutely no idea
> > why, of course. This update stuff is entirely beyond understanding.
> 
> But a two-stage approach is, isn't it?

Andre, how do you possibly expect me to be able to do this when I can't
make head or tail of the existing code ? This is not something you can
just "hack around in", as you'd discover if you tried it ...

regards
john

Re: inset_apply bug

[John Levon]

On Thu, Mar 20, 2003 at 09:24:20AM +0100, Andre Poenitz wrote:

> On Wed, Mar 19, 2003 at 05:35:09PM +, John Levon wrote:
> > LFUN_INSET_MODIFY needs to do an updateInset() on the given inset,
> > it may change shape (e.g. minipage). This requires moving updateInset()
> > into InsetBase I guess ...
> 
> No problem.

Ahh, if only 'twere that simple :)

john

Re: [PATCH] more ert stuff

[John Levon]

On Thu, Mar 20, 2003 at 09:33:29AM +0100, Juergen Vigna wrote:

> IMO this should be pretty safe to apply.

OK thanks. (Review from someone who follows the code is very helpful to
me :))

regards
john

Re: lyx 1.3.2cvs qt backtrace of crash when closing external inset.

[John Levon]

On Thu, Mar 20, 2003 at 11:01:23AM +0100, Helge Hafting wrote:

> Closing an external inset in lyx-1.3.1 or 1.3.2cvs may crash. It is 
> reproducible
> with one of my files, the backtrace is at the end of this message.

Damnit, how the hell did this happen :(

I'll look into it - time to build 1.3 with qt ...

john

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 01:51:50PM +, John Levon wrote:
> > the drawing part. At this point probably all insets need the separation of
> > their individual draw() functions into metrics() and [real] draw(). 
> 
> Net effect: the insettexts run through all the calculations entirely
> twice. Doesn't sound like a great idea ...

First of all, "twice" might be better than what we have now. 

Secondly, why should it do the calculation twice?
The draw step consists only of "put string 'foo' at position 'pos'"

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 03:02:55PM +0100, Andre Poenitz wrote:

> First of all, "twice" might be better than what we have now. 

This is (incorrectly) assuming that just splitting the thing into two
doesn't mean we don't need to do things multiple times still. It's all
very well to talk about some hypothetical code base at some point in the
future, but that is not what we have now, and not what I have will have
to make working.

> Secondly, why should it do the calculation twice?
> The draw step consists only of "put string 'foo' at position 'pos'"

And where do these positions come from ? Cached ? AIUI that's not what
mathed does. So, you end up doing all the metrics again during the draw.
Or you cache it and have some *very* fragile semantics of when a cache
should be cleared or not.

regards
john

Re: quote behaviour in Lyx Code environment

[Helge Hafting]

Christian Ridderström wrote:
Hi

I'm confused by the behavour of quotes... First there is the 
difference in behaviour when comparing a Standard environment to the 
Lyx-Code envionment. Here's how it works for me:

Another aspect of this is how the UI works. The setting
(Layout->Document->Language->Quote style) only affects the behaviour of 
quotes that you add after changing the setting...
[...]
I was actually expecting all quotes to change when I changed this setting 
since it was under the Laout->Document... AFAIK, all the other settings 
affects the entire document, and not just stuff that you add.
If it changed all, how would you write a document with different
quoting styles?  The typical example here is several
quotes nested inside each other, the second level is usually
typeset with a different style.
Or you could have a text quoting a dialog, using
different quotes for the two persons.
Helge Hafting

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 02:23:17PM +, John Levon wrote:
> This is (incorrectly) assuming that just splitting the thing into two
> doesn't mean we don't need to do things multiple times still.

Not more than once per redraw.

> > Secondly, why should it do the calculation twice?
> > The draw step consists only of "put string 'foo' at position 'pos'"
> 
> And where do these positions come from ? Cached ?

Cached from the previous metrics() run.

> AIUI that's not what mathed does. So, you end up doing all the metrics
> again during the draw.

draw() 
{
metrics();
  real_draw(); 
}

> Or you cache it and have some *very* fragile
> semantics of when a cache should be cleared or not.

Maybe "cache" is the wrong word. It was originally intended as a cache but
as it turned out fast enough I decided not to try "real caching" and
instead re-calculate on each draw(). However, using it as a cache is
possible, and I had it running at some point of time, the problem was the
"macro folding".

This is similar to line rebreaks in the outer world, so yes, real caching
might be difficult to achieve, but as "one shot cache" it just works fine.

Maybe I really should not call it 'cache'.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 03:47:01PM +0100, Andre Poenitz wrote:

> > This is (incorrectly) assuming that just splitting the thing into two
> > doesn't mean we don't need to do things multiple times still.
> 
> Not more than once per redraw.

OK,  what is your magical solution to the inset update problem. With
details please ...

> This is similar to line rebreaks in the outer world, so yes, real caching
> might be difficult to achieve, but as "one shot cache" it just works fine.
> 
> Maybe I really should not call it 'cache'.

Well, I think I follow you a bit better now. In fact,  that is what I am
trying to do ! Basically make sure all inset updates have been done by
the time we actually call draw. But it is beyond my ken (I cannot even
get one small part of this to work, in fact).

We could queue inset updates and do them all after an lfun etc, but I
don't see how to get the sensible ordering of innermost->outermost.

john

Re: top_y() is killing us

[Juergen Vigna]

John Levon wrote:
On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote:


But we do this already we calculate all the matrices for drawing and
in the draw function we (most of the time) do just drawing and that
is pretty fast!) or what do you think do we use the "LyXText" inside
the InsetText for?


If this was true, CHANGED_IN_DRAW would not exist.
I said "most of the times", didn't I? This means we need to redo
the calculations if at the time we get to the draw routine the
drawing tells us we don't have all the space we thought we had.
The problem is that we have this information for now only when the
draw function is really called :(
  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: top_y() is killing us

[Juergen Vigna]

John Levon wrote:
Well, I think I follow you a bit better now. In fact,  that is what I am
trying to do ! Basically make sure all inset updates have been done by
the time we actually call draw. But it is beyond my ken (I cannot even
get one small part of this to work, in fact).
As I told you in my earlier mail some informations you have only when
you are in the real draw function, well actually we are interested for
a "test-rebreak" only in the "x" position as if this changes it means we
have to rebreak the whole text inside the inset.
This is also the difference between an InsetText and a InsetMath as
mathed does not care how large it will become and this assumption takes
out the whole complexitiy!
We could queue inset updates and do them all after an lfun etc, but I
don't see how to get the sensible ordering of innermost->outermost.
That's the problem!

  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 04:07:25PM +0100, Juergen Vigna wrote:

> I said "most of the times", didn't I?

Ooops, so you did !

> This means we need to redo
> the calculations if at the time we get to the draw routine the
> drawing tells us we don't have all the space we thought we had.

Are you aware how rare this actually is ? In my tests, I had trouble
finding a situation where the width changed in draw() and we hadn't
previously called update() with the new width already set...

> The problem is that we have this information for now only when the
> draw function is really called :(

Can you describe an exact circumstance ? I'll add some printf's and a
getMaxWidth()  thingy in update() to see when it does actually happen.

In the meantime, a  solution to the FIXME in insetminipage.C would be
greatly welcomed :)

thanks,
john

easy lyx crash

[Jos van den Oever]

Hello lyx developers,

I just crashed lyx 1.3.1. The recipe is easy:
- open lyx
- press Alt-F to open the File menu
- press i (for import, which is not acivated and the cause of the problem)
- press right arrow
crash

I've tested on SuSE 8.0 and RedHat phoebe-3 (latest beta).

Good luck with further development!

Jos

Re: Fun with updating

[Juergen Vigna]

John Levon wrote:
Well, can you explain why calling insettext->update(reinit == true)
inside the insetminipage thing doesn't work ? That's alll I want to know
and after about 50 printf's, I'm still stuck.
Because you do it at the wrong spot! Try to "printf x()" and then after
it drawed it wrong (or inside the draw function) also the x(), you will
see they changed. I explained this in the earlier mails.
This is the final part of an earlier patch - we look at the lfun
definition and decide from that whether we modified the buffer
Good! Seems a nice way to do it!

 Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: Fun with updating

[John Levon]

On Thu, Mar 20, 2003 at 04:19:02PM +0100, Juergen Vigna wrote:

> >Well, can you explain why calling insettext->update(reinit == true)
> >inside the insetminipage thing doesn't work ? That's alll I want to know
> >and after about 50 printf's, I'm still stuck.
> 
> Because you do it at the wrong spot!

Why is it the wrong spot ? Can you explain in simple terms ?

> Try to "printf x()" and then after
> it drawed it wrong (or inside the draw function) also the x(), you will
> see they changed.

Dude, I spent *hours* doing this, and could not see where or why it
didn't work. This is lots of printfs in various update() functions etc.

> I explained this in the earlier mails.

Where ?

> >This is the final part of an earlier patch - we look at the lfun
> >definition and decide from that whether we modified the buffer
> 
> Good! Seems a nice way to do it!

It cleaned up things quite a bit actually ...

regards,
john

[PATCH] remove changed-in-draw

[John Levon]

Well Juergen I've given this some testing, and I haven't triggered
"Darn, CID" yet. Do you have, by any chance, some suggestions for
operations that might cause the CHANGED_IN_DRAW to happen ?

I'm going to commit this (maybe with an abort on CID ?) in a bit, and if
nothing happens after people like Garst et al trying it, remove
CID altogether. Though I guess that's dependent on fixing minipage/ert
...

regards,
john


Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.361
diff -u -p -r1.361 insettext.C
--- insets/insettext.C  20 Mar 2003 14:13:48 -  1.361
+++ insets/insettext.C  20 Mar 2003 16:15:10 -
@@ -360,6 +360,8 @@ void InsetText::draw(BufferView * bv, Ly
topx_set = true;
int nw = getMaxWidth(bv, this);
if (nw > 0 && old_max_width != nw) {
+   lyxerr << "Darn, CID !" << endl;
+   lyxerr << "New is " << nw << " old is " << old_max_width << 
endl;
need_update = INIT;
old_max_width = nw;
bv->text->postChangedInDraw();
@@ -495,6 +497,7 @@ void InsetText::update(BufferView * bv, 
return;
}
in_update = true;
+
if (reinit || need_update == INIT) {
need_update = FULL;
// we should put this call where we set need_update to INIT!
@@ -502,6 +505,13 @@ void InsetText::update(BufferView * bv, 
if (owner())
owner()->update(bv, true);
in_update = false;
+   int nw = getMaxWidth(bv, this);
+   if (nw > 0 && old_max_width != nw) {
+   need_update |= INIT;
+   lyxerr << "width changed in update" << endl;
+   lyxerr << "New is " << nw << " old is " << old_max_width << 
endl;
+   old_max_width = nw;
+   }
return;
}
 
@@ -529,6 +539,14 @@ void InsetText::update(BufferView * bv, 
if (clear)
lt = 0;
in_update = false;
+
+   int nw = getMaxWidth(bv, this);
+   if (nw > 0 && old_max_width != nw) {
+   need_update |= INIT;
+   lyxerr << "width changed in update" << endl;
+   lyxerr << "New is " << nw << " old is " << old_max_width << endl;
+   old_max_width = nw;
+   }
 }
 
 
Index: insets/updatableinset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/updatableinset.C,v
retrieving revision 1.6
diff -u -p -r1.6 updatableinset.C
--- insets/updatableinset.C 19 Mar 2003 14:45:22 -  1.6
+++ insets/updatableinset.C 20 Mar 2003 16:15:11 -
@@ -179,7 +179,8 @@ int UpdatableInset::getMaxWidth(BufferVi
// this is needed as otherwise we might have a too large inset if
// its top_x afterwards changes to LeftMargin so we try to put at
// least the default margin as top_x
-   w -= 20;
+   #warning FIXME
+   //  w -= 20;
}
if (w < 10) {
w = 10;

Re: Fun with updating

[Juergen Vigna]

John Levon wrote:
Why is it the wrong spot ? Can you explain in simple terms ?
I explained below, the x position is changing during draw and if that
happens we have to "recalculate all"!
Dude, I spent *hours* doing this, and could not see where or why it
didn't work. This is lots of printfs in various update() functions etc.
Only hours come on that's nothing in confront to how many time I spent
to make it work ;)
Where ?
Draw + x()!

  Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: Fun with updating

[John Levon]

On Thu, Mar 20, 2003 at 05:30:23PM +0100, Juergen Vigna wrote:

> Draw + x()!

Ohh, Inset::x() ! Right ... which types of insettext actually care about
their x() position ? As I mentioned in my other mail + patch, a simple
test of a few scenarios couldn't cause any "trouble"

> Only hours come on that's nothing in confront to how many time I spent
> to make it work ;)

heh :)

john

Re: lyx 1.3.2cvs qt backtrace of crash when closing external inset.

[John Levon]

On Thu, Mar 20, 2003 at 11:01:23AM +0100, Helge Hafting wrote:

> Closing an external inset in lyx-1.3.1 or 1.3.2cvs may crash. It is 
> reproducible

Sheesh, well I'm a genius  I made a wrong patch,  fixed it, then
applied the wrong patch anyway and didn't notice. Great !

Expect a fix soon

thanks
john

Re: easy lyx crash

[John Levon]

On Thu, Mar 20, 2003 at 04:13:23PM +0100, Jos van den Oever wrote:

> I just crashed lyx 1.3.1. The recipe is easy:

xforms frontend ?

> - open lyx
> - press Alt-F to open the File menu
> - press i (for import, which is not acivated and the cause of the problem)

Why isn't the menu activated ?

It is for me as it should be.

john

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 02:59:04PM +, John Levon wrote:
> > Not more than once per redraw.
> 
> OK,  what is your magical solution to the inset update problem. With
> details please ...

Simple: There is no inset update problem as there won't be an inset update.

Handling an LFUN just changes the structure of the doc, the postion of the
cursor, whatever. It does not care about visual appearance at all.

If the handling is finished, we do a full redraw. [Later we might be a bit
more clever, but not now]. The full redraw consists of two phases. In
each phase the document tree is traversed in full and each phase carries
some "information object" containing objects like current font, current
textwidth etc.

The first phase is the "metrics calculation". Each container (inset,
main text,...) adjusts the information object according to its needs (i.e.
a minipage would change the textwidth) and calls metrics() with this
information object on each of its children recursively. If this is
finished, the sizes of the children are known and the container itself can
compute its own size. Row breaking etc. would happen here. Afterwards it
saves this newly computed size in its local "cache".

Example:

void MathFracInset::metrics(MathMetricsInfo & mi) const
{
// this locally changes fontsize, clean up on destruction of dummy
MathFracChanger dummy(mi.base);
// determine size of two children (numerator and denominator)
cell(0).metrics(mi);
cell(1).metrics(mi);
// compute our own size
dim_.w = max(cell(0).width(), cell(1).width()) + 2;
dim_.a = cell(0).height() + 2 + 5;
dim_.d = cell(1).height() + 2 - 5;
}

In the second phase, we go down the tree again passing another "information
object" around, containing an actual painter object and a position. Again,
apply local changes. Using the precomputed sizes we are able to tell the
childeren where to start their drawing. Tell them to do so. Then do our own
drawing. Undo local changes to the information object. Return.

Example:

void MathFracInset::draw(MathPainterInfo & pi, int x, int y) const
{
int m = x + width() / 2;
// this locally changes fontsize, clean up on destruction of dummy
MathFracChanger dummy(pi.base);
cell(0).draw(pi, m - cell(0).width() / 2, y - cell(0).descent() - 2 - 
5);
cell(1).draw(pi, m - cell(1).width() / 2, y + cell(1).ascent()  + 2 - 
5);
if (!atop_)
pi.pain.line(x + 1, y - 5, x + width() - 2, y - 5, 
LColor::math);
}



Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 04:14:38PM +0100, Juergen Vigna wrote:
> As I told you in my earlier mail some informations you have only when
> you are in the real draw function,

At the top most draw function, we would split drawing in two phases. So the
first phase knows "everything" already.

> This is also the difference between an InsetText and a InsetMath as
> mathed does not care how large it will become and this assumption takes
> out the whole complexitiy!

But it could take this into account easily.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 05:50:05PM +0100, Andre Poenitz wrote:

> Handling an LFUN just changes the structure of the doc, the postion of the
> cursor, whatever. It does not care about visual appearance at all.
> 
> If the handling is finished, we do a full redraw. [Later we might be a bit
> more clever, but not now]. The full redraw consists of two phases. In
> each phase the document tree is traversed in full and each phase carries
> some "information object" containing objects like current font, current
> textwidth etc.
> 
> The first phase is the "metrics calculation". Each container (inset,
> main text,...) adjusts the information object according to its needs (i.e.
> a minipage would change the textwidth) and calls metrics() with this
> information object on each of its children recursively. If this is
> finished, the sizes of the children are known and the container itself can
> compute its own size. Row breaking etc. would happen here. Afterwards it

And how does it alter its *parent* when needed ? And its parent's parent ?

This sounds tremendously like what already exists Andre, except you
called "update" "metrics" instead,  and you do a full redraw of the
screen. It is doing this update/metrics traversal that is the
complicated bit !

regards,
john

Re: [PATCH] remove changed-in-draw

[John Levon]

On Thu, Mar 20, 2003 at 04:21:55PM +, John Levon wrote:

> Well Juergen I've given this some testing, and I haven't triggered
> "Darn, CID" yet. Do you have, by any chance, some suggestions for
> operations that might cause the CHANGED_IN_DRAW to happen ?

D'oh, didn't try too hard did I ...

minipage inside float will do it ... let me experiment further

john

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote:
> And how does it alter its *parent* when needed ?

Nothing knows about its parent except what it gets passed in the info
structure. 

By returning something in the info structure. When the parent starts doing
its calculations, the sizes of the children are fixed.

> This sounds tremendously like what already exists Andre, except you
> called "update" "metrics" instead,  and you do a full redraw of the
> screen. It is doing this update/metrics traversal that is the
> complicated bit !

It is a simple depth first tree traversal...

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: top_y() is killing us

[Andre Poenitz]

On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote:
> And how does it alter its *parent* when needed ? And its parent's parent ?

Ok, maybe I am realling missing the point:

In what circumstances does an inset have to alter its parent [that can't be
handled in the two-phase, parent-after-children approach]?

Juergen bases all his statements on the same theory that such a thing is
necessary, but I really can't see an example.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Re: easy lyx crash

[Dan Armak]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday 20 March 2003 18:45, John Levon wrote:
> On Thu, Mar 20, 2003 at 04:13:23PM +0100, Jos van den Oever wrote:
> 
> > I just crashed lyx 1.3.1. The recipe is easy:
> 
> xforms frontend ?
> 
> > - open lyx
> > - press Alt-F to open the File menu
> > - press i (for import, which is not acivated and the cause of the problem)
> 
> Why isn't the menu activated ?
> 
> It is for me as it should be.

Well, I can reproduce it too (incl. the menu shortcut not working - the menu 
item selection indicator just disappears). QT frontend (qt 3.1.2).

It says:
[EMAIL PROTECTED] danarmak $ lyx -dbg all
Setting debug level to all


lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting instructions 
in Help->Introduction and send us a bug report, if necessary. Thanks !
Bye.
Aborted

No time to do more testing right now, but it does happen.

- -- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+efm0UI2RQ41fiVERAobDAJ0Z2rfyBiyq5Rx/3htd4krUXIjT/QCfUkOA
vGI5PVfFjfnW2bPIaI3/+xU=
=WHco
-END PGP SIGNATURE-

Re: top_y() is killing us

[John Levon]

On Thu, Mar 20, 2003 at 06:08:44PM +0100, Andre Poenitz wrote:

> > And how does it alter its *parent* when needed ? And its parent's parent ?
> 
> Ok, maybe I am realling missing the point:
> 
> In what circumstances does an inset have to alter its parent [that can't be
> handled in the two-phase, parent-after-children approach]?

minipage is 45% of column width. Minipage is inside a table column that
we have just altered to have a fixed width of 2 inches. The width of
this column dictates the minipage width which dictates the breaking of
the cell which dictates the height of the minipage's row which dictates
the height of the table which dictates the height of the float which
contains the table which dictates the height of the outermost row.

Things like that...

Simpler example: inlined ERT. Its contents (changed when you type a
character) need to size to the contents. Now you're about to say : "well
the parent should enquire its child for its size in the first phase" ?
That is essentially what is happening now !

regards
john