Andre Poenitz wrote:
So why do we see several updates per redraw?
Why does an inset communicate explicitly with its parent?
I think discussing helps thinking ;)
The problem we have is that we do updating of the text in rows.
so if the inset is embedded in a row and it changes it may be that
we
On Fri, Mar 21, 2003 at 10:34:13AM +0100, Juergen Vigna wrote:
Andre Poenitz wrote:
So why do we see several updates per redraw?
Why does an inset communicate explicitly with its parent?
I think discussing helps thinking ;)
[Pretty unconventional approach nowadays. It seems that solving
On Fri, Mar 21, 2003 at 10:34:13AM +0100, Juergen Vigna wrote:
I don't see any easy solution for this as we cannot update first
all insets and then the text, as we then don't know the exact x
position of the inset and this gives us the width of the inset.
I still do not understand what the x
On Fri, Mar 21, 2003 at 01:50:23PM +, John Levon wrote:
I don't see any easy solution for this as we cannot update first
all insets and then the text, as we then don't know the exact x
position of the inset and this gives us the width of the inset.
I still do not understand what the x
On Fri, Mar 21, 2003 at 08:16:17AM +0100, Andre Poenitz wrote:
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
On Fri, Mar 21, 2003 at 10:47:29AM +0100, Andre Poenitz wrote:
Hah! The point is, the first phase fixes only the _size_, not the position.
The position is not relevant for the computation of the size of the parent.
Not true: think about a non-special-cased insetnewline. Its position
directly
On Fri, Mar 21, 2003 at 01:52:27PM +, John Levon wrote:
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
On Fri, Mar 21, 2003 at 01:55:13PM +, John Levon wrote:
If you're willing to give things a go you can count on as much support +
patches as I can muster :)
Ok. I have an hour or so left now. I'll create the metricsinfo stuff rigth
now.
Andre'
--
Those who desire to give up Freedom in
On Fri, Mar 21, 2003 at 02:48:13PM +0100, Andre Poenitz wrote:
Yes. But as there are a few other things that need to be passed along,
better use a struct for all parameters. This way the interface stays
optically leaner, you can forward-declare the struct and adding a new
parameter later is
Andre Poenitz wrote:
So why do we see several updates per redraw?
Why does an inset communicate explicitly with its parent?
I think discussing helps thinking ;)
The problem we have is that we do "updating" of the text in "rows".
so if the "inset" is embedded in a row and it changes it may be
On Fri, Mar 21, 2003 at 10:34:13AM +0100, Juergen Vigna wrote:
> Andre Poenitz wrote:
> >So why do we see several updates per redraw?
> >
> >Why does an inset communicate explicitly with its parent?
>
> I think discussing helps thinking ;)
[Pretty unconventional approach nowadays. It seems that
On Fri, Mar 21, 2003 at 10:34:13AM +0100, Juergen Vigna wrote:
> I don't see any easy solution for this as we cannot "update" first
> all insets and then the text, as we then don't know the exact "x"
> position of the inset and this gives us the "width" of the inset.
I still do not understand
On Fri, Mar 21, 2003 at 01:50:23PM +, John Levon wrote:
> > I don't see any easy solution for this as we cannot "update" first
> > all insets and then the text, as we then don't know the exact "x"
> > position of the inset and this gives us the "width" of the inset.
>
> I still do not
On Fri, Mar 21, 2003 at 08:16:17AM +0100, Andre Poenitz wrote:
> 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
On Fri, Mar 21, 2003 at 10:47:29AM +0100, Andre Poenitz wrote:
> Hah! The point is, the first phase fixes only the _size_, not the position.
> The position is not relevant for the computation of the size of the parent.
Not true: think about a non-special-cased insetnewline. Its position
directly
On Fri, Mar 21, 2003 at 01:52:27PM +, John Levon wrote:
> > 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
> >
On Fri, Mar 21, 2003 at 01:55:13PM +, John Levon wrote:
> If you're willing to give things a go you can count on as much support +
> patches as I can muster :)
Ok. I have an hour or so left now. I'll create the metricsinfo stuff rigth
now.
Andre'
--
Those who desire to give up Freedom in
On Fri, Mar 21, 2003 at 02:48:13PM +0100, Andre Poenitz wrote:
> Yes. But as there are a few other things that need to be passed along,
> better use a struct for all parameters. This way the interface stays
> optically leaner, you can forward-declare the struct and adding a new
> parameter later
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
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
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
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
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:
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
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
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
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
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
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.
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
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
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
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
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
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
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
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,
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,
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
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
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
> >
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
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
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:
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?
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
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.
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
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
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
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
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
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
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
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
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
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
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,
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
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
John == John Levon [EMAIL PROTECTED] writes:
John The iteration through all the rows ...
John Why doesn't a row know its position ?
Because we would have to update all the positions when inserting a new
row?
When is top_y() called?
JMarc
On Wed, Mar 19, 2003 at 02:58:37PM +0100, Jean-Marc Lasgouttes wrote:
Because we would have to update all the positions when inserting a new
row?
That's a lot less common than getRowNearY(), top_y(), etc.
When is top_y() called?
Every cursor movement, click, motion ...
this is new stuff
John == John Levon [EMAIL PROTECTED] writes:
When is top_y() called?
John Every cursor movement, click, motion ...
John this is new stuff though
So presumably some of the clever but annoying stuff we had was
useful? ;)
JMarc
On Wed, Mar 19, 2003 at 03:09:03PM +0100, Jean-Marc Lasgouttes wrote:
So presumably some of the clever but annoying stuff we had was
useful? ;)
No, this is entirely related to Alfredo's work, which is orthogonal to
the stuff I've been ripping out.
regards
john
John Levon wrote:
The iteration through all the rows ...
Are you sure it's significative? We can always try the 'old way' with a four
line change like I did before. I've never detected a slowdown.
Why doesn't a row know its position ?
I'll bet that this will be easy to do. When does row
On Wed, Mar 19, 2003 at 03:37:16PM +0100, Alfredo Braunstein wrote:
Are you sure it's significative? We can always try the 'old way' with a four
line change like I did before. I've never detected a slowdown.
It towers over everything else in the profiles.
I'll bet that this will be easy to
On Wed, Mar 19, 2003 at 03:37:16PM +0100, Alfredo Braunstein wrote:
I'll bet that this will be easy to do. When does row positions can be
updated? On rowpaint and row insert/delete I presume?
Actually, also whenever a row-height() can change, e.g. set font
john
John Levon wrote:
Actually, also whenever a row-height() can change, e.g. set font
on LyXText::setHeightOfRow() would suffice?
Alfredo
On Wed, Mar 19, 2003 at 03:49:10PM +0100, Alfredo Braunstein wrote:
Actually, also whenever a row-height() can change, e.g. set font
on LyXText::setHeightOfRow() would suffice?
plus removeRow, I guess ... dunno.
john
John Levon wrote:
on LyXText::setHeightOfRow() would suffice?
plus removeRow, I guess ... dunno.
I'll make a try. Alfredo
On Wed, Mar 19, 2003 at 03:52:52PM +0100, Alfredo Braunstein wrote:
I'll make a try. Alfredo
Great !
john
I don't really read all of the mails arriving right now (there is just
too much traffic), but I overscan all of them fast.
Now I'm a bit worried about the actual state of the lyx developement
are you all sure we will not end up as in the old development tree?
I hope you try to hold on yourself and
On Wed, Mar 19, 2003 at 05:14:49PM +0100, Juergen Vigna wrote:
I don't really read all of the mails arriving right now (there is just
too much traffic), but I overscan all of them fast.
Now I'm a bit worried about the actual state of the lyx developement
are you all sure we will not end up
John Levon wrote:
o slowdown of top_y()
o anchor row setting on doc shorter than the workarea is not ideal
These two are my bad but are pretty isolated and can be 'eliminated' by
adding four lines to the existing code
Btw, what's the problem with the second?
Alfredo
On Wed, Mar 19, 2003 at 05:20:41PM +0100, Alfredo Braunstein wrote:
Btw, what's the problem with the second?
Create a new document, type a few rows/pars of text, add afootnote, then
close the footnote. The top row becomes the row containing the
footnote, but it should be firstrow.
regards
On Wed, Mar 19, 2003 at 04:22:57PM +, John Levon wrote:
We currently have :
o the assert (bugs always there)
o a new DEPM crash
o some new drawing problems
o slowdown of top_y()
o anchor row setting on doc shorter than the workarea is not ideal
That's as much as I'm really aware of.
On Wed, Mar 19, 2003 at 05:23:17PM +0100, Andre Poenitz wrote:
That's as much as I'm really aware of.
My bibkey breaking...
Oh yeah. and use_amsmath :))
john
On Wed, Mar 19, 2003 at 05:23:17PM +0100, Andre Poenitz wrote:
My bibkey breaking...
I'm going to stop now, btw. I hacked out the direct updates (below)
and it breaks everything so badly that there is no point attempting
(ever) cleaning this up.
john
Index: BufferView_pimpl.C
On Wed, Mar 19, 2003 at 04:37:39PM +, John Levon wrote:
I'm going to stop now, btw. I hacked out the direct updates (below)
and it breaks everything so badly that there is no point attempting
(ever) cleaning this up.
So what about the two-stage drawing?
Give the insets a small cache of
On Wed, Mar 19, 2003 at 05:34:54PM +0100, 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
John Levon wrote:
Create a new document, type a few rows/pars of text, add afootnote, then
close the footnote. The top row becomes the row containing the
footnote, but it should be firstrow.
I cannot reproduce this. Can you be more explicit?
Alfredo
On Wed, Mar 19, 2003 at 10:26:20PM +0100, Alfredo Braunstein wrote:
I cannot reproduce this. Can you be more explicit?
Load the attached, cut the footnote, paste the footnote (with control-v)
at the end of the document.
We scroll to a position that doesn't seem natural to me (and also, it
John Levon wrote:
Load the attached, cut the footnote, paste the footnote (with control-v)
Be serious and attach something then. ;)
Alfredo
On Wed, Mar 19, 2003 at 10:34:39PM +0100, Alfredo Braunstein wrote:
Be serious and attach something then. ;)
oops
john
#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 223
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
John Levon [EMAIL PROTECTED] writes:
| On Wed, Mar 19, 2003 at 10:26:20PM +0100, Alfredo Braunstein wrote:
|
| I cannot reproduce this. Can you be more explicit?
|
| Load the attached, cut the footnote, paste the footnote (with control-v)
| at the end of the document.
Is paste working?
On Wed, Mar 19, 2003 at 11:54:19PM +0100, Lars Gullik Bj?nnes wrote:
| Load the attached, cut the footnote, paste the footnote (with control-v)
| at the end of the document.
Is paste working?
In this circumstance, at least.
john
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> The iteration through all the rows ...
John> Why doesn't a row know its position ?
Because we would have to update all the positions when inserting a new
row?
When is top_y() called?
JMarc
On Wed, Mar 19, 2003 at 02:58:37PM +0100, Jean-Marc Lasgouttes wrote:
> Because we would have to update all the positions when inserting a new
> row?
That's a lot less common than getRowNearY(), top_y(), etc.
> When is top_y() called?
Every cursor movement, click, motion ...
this is new
> "John" == John Levon <[EMAIL PROTECTED]> writes:
>> When is top_y() called?
John> Every cursor movement, click, motion ...
John> this is new stuff though
So presumably some of the "clever but annoying" stuff we had was
useful? ;)
JMarc
On Wed, Mar 19, 2003 at 03:09:03PM +0100, Jean-Marc Lasgouttes wrote:
> So presumably some of the "clever but annoying" stuff we had was
> useful? ;)
No, this is entirely related to Alfredo's work, which is orthogonal to
the stuff I've been ripping out.
regards
john
John Levon wrote:
> The iteration through all the rows ...
Are you sure it's significative? We can always try the 'old way' with a four
line change like I did before. I've never detected a slowdown.
> Why doesn't a row know its position ?
I'll bet that this will be easy to do. When does row
On Wed, Mar 19, 2003 at 03:37:16PM +0100, Alfredo Braunstein wrote:
> Are you sure it's significative? We can always try the 'old way' with a four
> line change like I did before. I've never detected a slowdown.
It towers over everything else in the profiles.
> I'll bet that this will be easy
On Wed, Mar 19, 2003 at 03:37:16PM +0100, Alfredo Braunstein wrote:
> I'll bet that this will be easy to do. When does row positions can be
> updated? On rowpaint and row insert/delete I presume?
Actually, also whenever a row->height() can change, e.g. set font
john
John Levon wrote:
> Actually, also whenever a row->height() can change, e.g. set font
on LyXText::setHeightOfRow() would suffice?
Alfredo
On Wed, Mar 19, 2003 at 03:49:10PM +0100, Alfredo Braunstein wrote:
> > Actually, also whenever a row->height() can change, e.g. set font
>
> on LyXText::setHeightOfRow() would suffice?
plus removeRow, I guess ... dunno.
john
John Levon wrote:
>> on LyXText::setHeightOfRow() would suffice?
>
> plus removeRow, I guess ... dunno.
I'll make a try. Alfredo
On Wed, Mar 19, 2003 at 03:52:52PM +0100, Alfredo Braunstein wrote:
> I'll make a try. Alfredo
Great !
john
I don't really read all of the mails arriving right now (there is just
too much traffic), but I overscan all of them fast.
Now I'm a bit worried about the actual state of the lyx developement
are you all sure we will not end up as in the "old" development tree?
I hope you try to hold on yourself
On Wed, Mar 19, 2003 at 05:14:49PM +0100, Juergen Vigna wrote:
> I don't really read all of the mails arriving right now (there is just
> too much traffic), but I overscan all of them fast.
>
> Now I'm a bit worried about the actual state of the lyx developement
> are you all sure we will not
John Levon wrote:
> o slowdown of top_y()
> o anchor row setting on doc shorter than the workarea is not ideal
These two are my bad but are pretty isolated and can be 'eliminated' by
adding four lines to the existing code
Btw, what's the problem with the second?
Alfredo
1 - 100 of 112 matches
Mail list logo
