Re: [patch] fix drawing issue
On Wednesday 18 July 2007 06:43:17 Jürgen Spitzmüller wrote: José? OK. Jürgen -- José Abílio
Re: [patch] fix drawing issue
On Wednesday 18 July 2007 06:43:17 Jürgen Spitzmüller wrote: > José? OK. > Jürgen -- José Abílio
[patch] fix drawing issue
This oneliner fixes some ugly drawing artefacts with insets in the appendix
(probably introduced with revision 19039).
Attached also a testcase where you can see the artefacts.
OK to apply?
Jürgen
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 19092)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -471,7 +471,7 @@
void RowPainter::paintAppendix()
{
- if (!par_.params().appendix())
+ if (!par_.params().appendix() || !text_.isMainText(*bv_.buffer()))
return;
int y = yo_ - row_.ascent();
redraw.lyx
Description: application/lyx
Re: [patch] fix drawing issue
On Tuesday 17 July 2007 14:25:23 Jürgen Spitzmüller wrote: This oneliner fixes some ugly drawing artefacts with insets in the appendix (probably introduced with revision 19039). Attached also a testcase where you can see the artefacts. OK to apply? OK. Jürgen -- José Abílio
Re: [patch] fix drawing issue
On 7/17/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote: This oneliner fixes some ugly drawing artefacts with insets in the appendix (probably introduced with revision 19039). There is also a redraw problem when you delete in ERT or listings inset, do you also have an oneliner? :-) Bo
Re: [patch] fix drawing issue
Bo Peng wrote: There is also a redraw problem when you delete in ERT or listings inset, do you also have an oneliner? :-) No, unfortunately not. Jürgen
Re: [patch] fix drawing issue
Bo Peng wrote:
There is also a redraw problem when you delete in ERT or listings
inset, do you also have an oneliner? :-)
Try this (OK, a bit more than one line).
Jürgen
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 19101)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -918,13 +918,21 @@
{
// check whether the current inset is nested in a non-wide inset
Cursor cur = pi.base.bv-cursor();
- for (int i = cur.depth() - 1; --i = 0; ) {
+ Inset const * cur_in = cur.inset();
+ // check all higher nested insets
+ for (size_type i = 1; i cur.depth(); ++i) {
Inset * const in = cur[i].inset();
- if (in) {
+ if (in == cur_in)
+ // we reached the level of the current inset, so stop
+ return false;
+ else if (in) {
+ if (in-hasFixedWidth())
+return true;
InsetText * t =
const_castInsetText *(in-asTextInset());
- if (t)
-return !t-wide();
+ if (t !t-wide())
+// OK, we are in a non-wide() inset
+return true;
}
}
return false;
@@ -1000,7 +1008,7 @@
// Clear background of this row
// (if paragraph background was not cleared)
if (!repaintAll
- (!(in_inset_alone_on_row leftEdgeFixed)
+ (!(in_inset_alone_on_row leftEdgeFixed !inNarrowIns)
|| row_has_changed)) {
pi.pain.fillRectangle(x, y - rit-ascent(),
rp.maxWidth(), rit-height(),
Re: [patch] fix drawing issue
On 7/17/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote: Bo Peng wrote: There is also a redraw problem when you delete in ERT or listings inset, do you also have an oneliner? :-) Try this (OK, a bit more than one line). The problem seems to be solved, but I can not figure out when an ERT inset will occupy the rest of the line during edition. E.g. Normal Listings: Usually [listings ] Edit [listings ] Inline listings and ERT: Always a[ERT] or [ERT]a if there is something before/after it, otherwise span to the end of line during edition. I think it makes sense to either 1. does not expand to the end of the line at all, or 2. only expand when there is nothing after it. I.e. remove the case of a[ERT]. Bo
Re: [patch] fix drawing issue
Bo Peng wrote: The problem seems to be solved, but I can not figure out when an ERT inset will occupy the rest of the line during edition. E.g. This is the unsavoury wide() thing (TM). The rule is: an inset spans the whole line, if - it is the only thing in the row and - the cursor is inside. Normal Listings: Usually [listings ] Edit [listings ] Yes. Inline listings and ERT: Always a[ERT] or [ERT]a if there is something before/after it, otherwise span to the end of line during edition. Exactly. I think it makes sense to either 1. does not expand to the end of the line at all, or 2. only expand when there is nothing after it. I.e. remove the case of a[ERT]. I won't spend a single minute on improving it. IMO, the only reasonable goal is to remove the wide() thing altogether, once the speed problems are resolved (remember the wide() thing is just a hack to work around the speed issues). So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. Jürgen
Re: [patch] fix drawing issue
So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. It should, but you need another OK. Bo
Re: [patch] fix drawing issue
Bo Peng wrote: So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. It should, but you need another OK. OK from me. Abdel.
Re: [patch] fix drawing issue
Abdelrazak Younes wrote: It should, but you need another OK. OK from me. José? Jürgen
[patch] fix drawing issue
This oneliner fixes some ugly drawing artefacts with insets in the appendix
(probably introduced with revision 19039).
Attached also a testcase where you can see the artefacts.
OK to apply?
Jürgen
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 19092)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -471,7 +471,7 @@
void RowPainter::paintAppendix()
{
- if (!par_.params().appendix())
+ if (!par_.params().appendix() || !text_.isMainText(*bv_.buffer()))
return;
int y = yo_ - row_.ascent();
redraw.lyx
Description: application/lyx
Re: [patch] fix drawing issue
On Tuesday 17 July 2007 14:25:23 Jürgen Spitzmüller wrote: > This oneliner fixes some ugly drawing artefacts with insets in the appendix > (probably introduced with revision 19039). > > Attached also a testcase where you can see the artefacts. > > OK to apply? OK. > Jürgen -- José Abílio
Re: [patch] fix drawing issue
On 7/17/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: This oneliner fixes some ugly drawing artefacts with insets in the appendix (probably introduced with revision 19039). There is also a redraw problem when you delete in ERT or listings inset, do you also have an oneliner? :-) Bo
Re: [patch] fix drawing issue
Bo Peng wrote: > There is also a redraw problem when you delete in ERT or listings > inset, do you also have an oneliner? :-) No, unfortunately not. Jürgen
Re: [patch] fix drawing issue
Bo Peng wrote:
> There is also a redraw problem when you delete in ERT or listings
> inset, do you also have an oneliner? :-)
Try this (OK, a bit more than one line).
Jürgen
Index: src/rowpainter.cpp
===
--- src/rowpainter.cpp (Revision 19101)
+++ src/rowpainter.cpp (Arbeitskopie)
@@ -918,13 +918,21 @@
{
// check whether the current inset is nested in a non-wide inset
Cursor & cur = pi.base.bv->cursor();
- for (int i = cur.depth() - 1; --i >= 0; ) {
+ Inset const * cur_in = ();
+ // check all higher nested insets
+ for (size_type i = 1; i < cur.depth(); ++i) {
Inset * const in = [i].inset();
- if (in) {
+ if (in == cur_in)
+ // we reached the level of the current inset, so stop
+ return false;
+ else if (in) {
+ if (in->hasFixedWidth())
+return true;
InsetText * t =
const_cast(in->asTextInset());
- if (t)
-return !t->wide();
+ if (t && !t->wide())
+// OK, we are in a non-wide() inset
+return true;
}
}
return false;
@@ -1000,7 +1008,7 @@
// Clear background of this row
// (if paragraph background was not cleared)
if (!repaintAll &&
- (!(in_inset_alone_on_row && leftEdgeFixed)
+ (!(in_inset_alone_on_row && leftEdgeFixed && !inNarrowIns)
|| row_has_changed)) {
pi.pain.fillRectangle(x, y - rit->ascent(),
rp.maxWidth(), rit->height(),
Re: [patch] fix drawing issue
On 7/17/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: Bo Peng wrote: > There is also a redraw problem when you delete in ERT or listings > inset, do you also have an oneliner? :-) Try this (OK, a bit more than one line). The problem seems to be solved, but I can not figure out when an ERT inset will occupy the rest of the line during edition. E.g. Normal Listings: Usually [listings ] Edit [listings ] Inline listings and ERT: Always "a[ERT]" or "[ERT]a" if there is something before/after it, otherwise span to the end of line during edition. I think it makes sense to either 1. does not expand to the end of the line at all, or 2. only expand when there is nothing after it. I.e. remove the case of a[ERT]. Bo
Re: [patch] fix drawing issue
Bo Peng wrote: > The problem seems to be solved, but I can not figure out when an ERT > inset will occupy the rest of the line during edition. E.g. This is the unsavoury "wide() thing" (TM). The rule is: an inset spans the whole line, if - it is the only thing in the row and - the cursor is inside. > Normal Listings: > Usually [listings ] > Edit [listings ] Yes. > Inline listings and ERT: > > Always "a[ERT]" or "[ERT]a" if there is something before/after it, > otherwise span to the end of line during edition. Exactly. > I think it makes sense to either > 1. does not expand to the end of the line at all, or > 2. only expand when there is nothing after it. I.e. remove the case of > a[ERT]. I won't spend a single minute on improving it. IMO, the only reasonable goal is to remove the wide() thing altogether, once the speed problems are resolved (remember the wide() thing is just a hack to work around the speed issues). So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. Jürgen
Re: [patch] fix drawing issue
So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. It should, but you need another OK. Bo
Re: [patch] fix drawing issue
Bo Peng wrote: So if you think that bug 3582 is solved, I'd propose to put that into 1.5.0. It should, but you need another OK. OK from me. Abdel.
Re: [patch] fix drawing issue
Abdelrazak Younes wrote: > > It should, but you need another OK. > > OK from me. José? Jürgen
