Hi Abdel,
as much as I know before we started on fixing bugs there I was not able
to scroll trough the UserGuide without hitting an Assert ;)
I think that this is due to the more metrics calculations we have to do
in order to fix all that scrolling bugs and with it the removal of the
Asger Ottar Alstrup wrote:
One conclusion is clear: The only sure way to get substantially faster
rendering is to draw less on the screen, as discussed earlier today,
either by introducing the old singlePar optimisation, or do some
drawing-caching scheme.
I'm of the opinion that in 1.6 we
Hi Abdel,
as much as I know before we started on fixing bugs there I was not able
to scroll trough the UserGuide without hitting an Assert ;)
I think that this is due to the "more" metrics calculations we have to do
in order to fix all that scrolling bugs and with it the removal of the
Asger Ottar Alstrup wrote:
One conclusion is clear: The only sure way to get substantially faster
rendering is to draw less on the screen, as discussed earlier today,
either by introducing the old singlePar optimisation, or do some
drawing-caching scheme.
I'm of the opinion that in 1.6 we
Hello Asger,
I bought my tickets yesterday (Sterling: for 151€ ;)
So if nothing happens I will be there with all off you.
I will arrive Thurthday 19 October Afternoon and depart
Monday 23 October Midday.
Till then,
Jürgen
Asger Ottar Alstrup wrote:
Dear Jürgen,
It would be great
Hello Asger,
I bought my tickets yesterday (Sterling: for 151€ ;)
So if nothing happens I will be there with all off you.
I will arrive Thurthday 19 October Afternoon and depart
Monday 23 October Midday.
Till then,
Jürgen
Asger Ottar Alstrup wrote:
Dear Jürgen,
It would be great
Hello,
I may be also attending the meeting, but I have to do some
checks still :)
Greets,
Jürgen
--
**
Würth Phoenix S.r.l.
Dr. Jürgen Vigna
System Integration
Via Kravogl 4, I-39100 Bolzano
Phone: +39 0471 564111
Hello,
I may be also attending the meeting, but I have to do some
checks still :)
Greets,
Jürgen
--
**
Würth Phoenix S.r.l.
Dr. Jürgen Vigna
System Integration
Via Kravogl 4, I-39100 Bolzano
Phone: +39 0471 564111
This works! Thanks a lot! How did you discover this?
Greets,
Jürgen
Lars Gullik Bjønnes wrote:
Juergen Vigna [EMAIL PROTECTED] writes:
| Hello there,
|
| i tried today to build lyx on my RedHat 4 system and the build was OK,
| but when trying to run it I get a Segmentation fault
This works! Thanks a lot! How did you discover this?
Greets,
Jürgen
Lars Gullik Bjønnes wrote:
Juergen Vigna <[EMAIL PROTECTED]> writes:
| Hello there,
|
| i tried today to build lyx on my RedHat 4 system and the build was OK,
| but when trying to run it I get a Segmentation
Hello there,
i tried today to build lyx on my RedHat 4 system and the build was OK,
but when trying to run it I get a Segmentation fault. Anyone has similar
experiences?
This is the gdb backtrace:
$ gdb src/lyx-xforms
GNU gdb Red Hat Linux (6.3.0.0-1.96rh)
Copyright 2004 Free Software
Hello there,
i tried today to build lyx on my RedHat 4 system and the build was OK,
but when trying to run it I get a Segmentation fault. Anyone has similar
experiences?
This is the gdb backtrace:
$ gdb src/lyx-xforms
GNU gdb Red Hat Linux (6.3.0.0-1.96rh)
Copyright 2004 Free Software
Hello Lars,
I've seen that we have again an 100% full /var filesystem on www.lyx.org :(
It seems that blocks the mails from there.
Could you have a look please.
Best regards,
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen Vigna
Hello Lars,
I've seen that we have again an 100% full /var filesystem on www.lyx.org :(
It seems that blocks the mails from there.
Could you have a look please.
Best regards,
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen Vigna
Hello Angus,
I wish you, Emma and little William all the best.
Enjoy him till he's little that are the best years (also if sometimes tiresome
;)
Kind regards,
Jürgen
Angus Leeming wrote:
Dear all,
I'd like to announce the arrival of William who arrived on Tuesday 15
November,
Hello Angus,
I wish you, Emma and little William all the best.
Enjoy him till he's little that are the best years (also if sometimes tiresome
;)
Kind regards,
Jürgen
Angus Leeming wrote:
Dear all,
I'd like to announce the arrival of William who arrived on Tuesday 15
November,
I already bought my tickets today, so most probably we will meet up in Paris
#:O)
~Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
What do you mean my flight dates/times?
Arrival in Paris evening the 14th, departure evening the 18th :)
I will check back with you as soon as I have all plans ready,
for the moment I just booked the flight (77 ).
~Jrgen
Jean-Marc Lasgouttes wrote:
Juergen == Juergen Vigna [EMAIL PROTECTED
I already bought my tickets today, so most probably we will meet up in Paris
#:O)
~Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
What do you mean my flight dates/times?
Arrival in Paris evening the 14th, departure evening the 18th :)
I will check back with you as soon as I have all plans ready,
for the moment I just booked the flight (77 €).
~Jürgen
Jean-Marc Lasgouttes wrote:
"Juergen" == Juergen Vig
Hello,
I would really like to be there this year I just have to
organize myself. Probably any of the dates will be 3 for
me.
So put me there with 3 on all and I try to orgnize myself
to be able to partecipate.
I see forward to see you all again!!!
Cheers,
Jürgen
Lars Gullik Bjønnes wrote:
Hello,
I would really like to be there this year I just have to
organize myself. Probably any of the dates will be 3 for
me.
So put me there with 3 on all and I try to orgnize myself
to be able to partecipate.
I see forward to see you all again!!!
Cheers,
Jürgen
Lars Gullik Bjønnes wrote:
The same for me!
Regards,
Jürgen
Asger Alstrup wrote:
I grant permission to license any and all contributions I've made to LyX
under any open source license.
Regards,
Asger
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL
Angus Leeming wrote:
Juergen Vigna wrote:
The same for me!
Regards,
Jürgen
Wooo! Jürgen! It's good to see a message from you! How's life in Italy?
Very busy! #:O)
Anyway I follow the mailinglist by reading Subjects, but I don't find
more time than this for the moment.
Have fun
The same for me!
Regards,
Jürgen
Asger Alstrup wrote:
I grant permission to license any and all contributions I've made to LyX
under any open source license.
Regards,
Asger
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL
Angus Leeming wrote:
Juergen Vigna wrote:
The same for me!
Regards,
Jürgen
Wooo! Jürgen! It's good to see a message from you! How's life in Italy?
Very busy! #:O)
Anyway I follow the mailinglist by reading "Subjects", but I don't find
more time than this for the moment
Hello boys,
I still follow *very quiet* the lyx-devel list ;)
I would *really* also like to come, but as you know I'm very
committed especially in summer and as this year we have taken
over the Pool with Bar/Restaurant it's worse then before.
I see forward to another year when we can organize the
Hello boys,
I still follow *very quiet* the lyx-devel list ;)
I would *really* also like to come, but as you know I'm very
committed especially in summer and as this year we have taken
over the Pool with Bar/Restaurant it's worse then before.
I see forward to another year when we can organize the
Hello Folk,
it seems that I didn't follow enough the lyx list as I'm not anymore
able to configure LyX now. Could somebody explain me what options I
HAVE to use in the configure command?
How do I now compile the different frontends? When I do a --help
it seems that --with-frontend does not
Angus Leeming wrote:
Good to hear from you Jürgen.
:)
Well I still read the mailing list (not all most mails I only
read the subject ;) and I regularly build lyx on my pc to see
what you're all doing :P
Attached is a little wrapper script that I use. Use it so:
$ ./configure-14x $LYX_DIR xforms
Hello Folk,
it seems that I didn't follow enough the lyx list as I'm not anymore
able to configure LyX now. Could somebody explain me what options I
HAVE to use in the configure command?
How do I now compile the different frontends? When I do a --help
it seems that --with-frontend does not
Angus Leeming wrote:
Good to hear from you Jürgen.
:)
Well I still read the mailing list (not all most mails I only
read the subject ;) and I regularly build lyx on my pc to see
what you're all doing :P
Attached is a little wrapper script that I use. Use it so:
$ ./configure-14x $LYX_DIR xforms
John Levon wrote:
On Tue, Jul 22, 2003 at 05:38:40PM +0200, Andre Poenitz wrote:
What could go wrong after applying the following?
Mouse cursor positioning would be the obvious thing to try. But, it's
already quite broken in current CVS ...
And fixing mouse press positioning problems is even
John Levon wrote:
On Tue, Jul 22, 2003 at 05:38:40PM +0200, Andre Poenitz wrote:
What could go wrong after applying the following?
Mouse cursor positioning would be the obvious thing to try. But, it's
already quite broken in current CVS ...
And fixing mouse press positioning problems is even
Andre Poenitz wrote:
What could go wrong after applying the following?
The cursor x position is probably wrong (inset inside inset).
Greets,
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich
Andre Poenitz wrote:
What could go wrong after applying the following?
The cursor x position is probably wrong (inset inside inset).
Greets,
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich
Andre Poenitz wrote:
This is arguably a step back on the path to 'multiple BufferView' as
now there's just a single 'active' BufferView again (complete rebreak when
changing BufferViews), but the current 'solution' contained (among others)
- bool clear = false;
- if (!lt) {
-
Andre Poenitz wrote:
This is arguably a step back on the path to 'multiple BufferView' as
now there's just a single 'active' BufferView again (complete rebreak when
changing BufferViews), but the current 'solution' contained (among others)
- bool clear = false;
- if (!lt) {
-
Andre Poenitz wrote:
But the contained InsetTexts do, so I am not spanking 'slow InsetTabular as
created by Juergen' but 'InsetTabular as container of lots InsetTexts'
[Although I'd think that there is some unnecessary fat in InsetTabular,
too...]
You may have a point here, althought I don't know
Andre Poenitz wrote:
This 'when needed' is basically the time between first and second drawing
phase. We need the rebreak to figure out the height of the InsetText,
so it is needed in the metrics() phase. And once we've done it there there
is no reason not to save the results up to the next draw()
Andre Poenitz wrote:
But the contained InsetTexts do, so I am not spanking 'slow InsetTabular as
created by Juergen' but 'InsetTabular as container of lots InsetTexts'
[Although I'd think that there is some unnecessary fat in InsetTabular,
too...]
You may have a point here, althought I don't know
Andre Poenitz wrote:
This 'when needed' is basically the time between first and second drawing
phase. We need the rebreak to figure out the height of the InsetText,
so it is needed in the metrics() phase. And once we've done it there there
is no reason not to save the results up to the next draw()
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
John Levon wrote:
Can somebody give me a brief summary of how/why this works ?
Especially, why can't we reinitLyXText when lt is non-null ?
Because it might be we are working on Row pointers which would
disapear or be invalidated by the reinit, don't you think so?
Jug
--
José Matos wrote:
Probably you meant raw pointers, no?
No I meant (raw) row pointer
In this subject row pointers will probably mean something else. Also I
would not have pointed if it wasn't friday...
Did you joke?
Jug
--
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
John Levon wrote:
Can somebody give me a brief summary of how/why this works ?
Especially, why can't we "reinitLyXText" when lt is non-null ?
Because it might be we are working on "Row" pointers which would
disapear or be invalidated by the reinit, don't you think so?
Jug
--
José Matos wrote:
Probably you meant "raw" pointers, no?
No I meant (raw) "row" pointer
In this subject "row" pointers will probably mean something else. Also I
would not have pointed if it wasn't friday...
Did you joke?
Jug
--
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
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
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
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
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
--
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
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:
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
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
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
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
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
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
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
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
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
--
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
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:
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&qu
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
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
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
John Levon wrote:
[snip]
Perhaps you're referring to insettext/tabular specific code that
decides which cells needs updating ? But that's not related to
redrawings really, it's more a matter of rebreaking etc. (and it's
broken in several circumstances)
Yes John you are right and I see you're on
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
John Levon wrote:
[snip]
Perhaps you're referring to insettext/tabular specific code that
decides which cells needs updating ? But that's not related to
redrawings really, it's more a matter of rebreaking etc. (and it's
broken in several circumstances)
Yes John you are right and I see you're on
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
Lars Gullik Bjønnes wrote:
Juergen Vigna [EMAIL PROTECTED] writes:
| Alfredo Braunstein wrote:
| It doesn't. You need 1 _top_ lyxtext for every bv (and there is already).
| Then you have also a lyxtext in every children insettext... I'm talking
| about these, mostly. Or else I am confusing
John Levon wrote:
This looks to be very silly indeed, so I guess I'm missing something.
Why are we calling update(text) directly several times for one lfun ?
Can we not just post the update, and then call it *once* at the end of
handling the lfun (and at the end of handleKeypress and a couple of
Lars Gullik Bjønnes wrote:
Keep the enclosed LyXText somehwere else, so that parts of the
paragraph structure could be modified at will, without having to thing
about anything else.
I don't really understand how you would do that and how that would
facilitate the process, I understand however that
Lars Gullik Bjønnes wrote:
Who are we? the inset? The inset should know nothing about any
lyxtext at all, the same way a Paragraph today knows nothing about any
lyxtext.
Well we is the inset. And yes this is a good idea and quite easy IMO
we just have to remove the DRAW functionality from the
Andre Poenitz wrote:
On Tue, Mar 18, 2003 at 11:52:32AM +0100, Juergen Vigna wrote:
PS: CutPastepress C-M on this to create the math tabular.
$\begin{tabular}{}
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\
\end{tabular}$
??? I would like to try that but I don't
Andre Poenitz wrote:
Face it: Full redraw _is_ faster. This might have changed over time,
though, but it is the current state.
Well this is easy enough to try just forget about the inteligent
redraw and set the update always to NEED_FULL_REDRAW and you'll
see the difference.
Jug
--
John Levon wrote:
This just sounds like bugs to me, and several redraws (did you know each
character press sends redraws twice even in a normal par ?) is not the
correct solution. Do you mean cursor droppings ?
There are a lot of different situations when we have wrong redraws if
we don't do the
Andre Poenitz wrote:
Would that mean (almost) no effort is spent to be clever in this case?
I don't understand your question here?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050
Lars Gullik Bjønnes wrote:
Juergen Vigna <[EMAIL PROTECTED]> writes:
| Alfredo Braunstein wrote:
| > It doesn't. You need 1 _top_ lyxtext for every bv (and there is already).
| > Then you have also a lyxtext in every children insettext... I'm talking
| > about these, mostl
John Levon wrote:
This looks to be very silly indeed, so I guess I'm missing something.
Why are we calling update(text) directly several times for one "lfun" ?
Can we not just post the update, and then call it *once* at the end of
handling the lfun (and at the end of handleKeypress and a couple of
Lars Gullik Bjønnes wrote:
Keep the enclosed LyXText somehwere else, so that parts of the
paragraph structure could be modified at will, without having to thing
about anything else.
I don't really understand how you would do that and how that would
facilitate the process, I understand however that
Lars Gullik Bjønnes wrote:
Who are "we"? the inset? The inset should know nothing about any
lyxtext at all, the same way a Paragraph today knows nothing about any
lyxtext.
Well "we" is the inset. And yes this is a good idea and quite easy IMO
we just have to remove the "DRAW" functionality from
Andre Poenitz wrote:
On Tue, Mar 18, 2003 at 11:52:32AM +0100, Juergen Vigna wrote:
PS: Cut C-M on this to create the math tabular.
$\begin{tabular}{}
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\
\end{tabular}$
??? I would like to try that but I don't know how
Andre Poenitz wrote:
Face it: Full redraw _is_ faster. This might have changed over time,
though, but it is the current state.
Well this is easy enough to try just forget about the "inteligent"
redraw and set the update always to "NEED_FULL_REDRAW" and you'll
see the difference.
Jug
John Levon wrote:
This just sounds like bugs to me, and several redraws (did you know each
character press sends redraws twice even in a normal par ?) is not the
correct solution. Do you mean cursor droppings ?
There are a lot of different situations when we have "wrong redraws" if
we don't do the
Andre Poenitz wrote:
Would that mean (almost) no effort is spent to "be clever" in this case?
I don't understand your question here?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
Alfredo Braunstein wrote:
Lars Gullik Bjønnes wrote:
I have a patch ready (that seems to work) that does 99.9% of these
changes.
How the multiple bv will be adressed (or is it already in the patch?)
- by having a cont bv member in lyxtext (i.e different bv for different
buffers)
- by
Alfredo Braunstein wrote:
It doesn't. You need 1 _top_ lyxtext for every bv (and there is already).
Then you have also a lyxtext in every children insettext... I'm talking
about these, mostly. Or else I am confusing something ;)
InsetText already has support for multiple BufferViews (while other
Alfredo Braunstein wrote:
Lars Gullik Bjønnes wrote:
I have a patch ready (that seems to work) that does 99.9% of these
changes.
How the multiple bv will be adressed (or is it already in the patch?)
- by having a cont bv member in lyxtext (i.e different bv for different
buffers)
- by
Alfredo Braunstein wrote:
It doesn't. You need 1 _top_ lyxtext for every bv (and there is already).
Then you have also a lyxtext in every children insettext... I'm talking
about these, mostly. Or else I am confusing something ;)
InsetText already has support for multiple BufferViews (while other
Andre Poenitz wrote:
This would make Sep 27 a good target, closely followed by Sep 20 and July
26. The next bunch is July 19, and Sep 6.
IMO Sep 27 would be a perfect date ;)
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:
Andre Poenitz wrote:
This would make Sep 27 a good target, closely followed by Sep 20 and July
26. The next bunch is July 19, and Sep 6.
IMO Sep 27 would be a perfect date ;)
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:
Andre Poenitz wrote:
The hierarchy should be something like
LyXFunc
|
BufferView
|
Buffer
|
OutermostText [And this should go if everything is an inset]
|
Insets
and we should walk it bottom-up. Currently we have some strange combination
of guessing jumps down
Andre Poenitz wrote:
The hierarchy should be something like
LyXFunc
|
BufferView
|
Buffer
|
OutermostText [And this should go if everything is an inset]
|
Insets
and we should walk it bottom-up. Currently we have some strange combination
of guessing jumps down
Andre Poenitz wrote:
I am starting to believe that all insets should cache a bufferview or some
context after e.g. draw() is called ...
The problem with this is that the BufferView is sometimes redone and
you point to a non valid pointer (the problems we had especially in
the beginning with
Andre Poenitz wrote:
I am starting to believe that all insets should cache a bufferview or some
"context" after e.g. draw() is called ...
The problem with this is that the BufferView is sometimes redone and
you point to a non valid pointer (the problems we had especially in
the beginning with
1 - 100 of 4844 matches
Mail list logo
