Re: Bug 580 fix
Martin Vermeer wrote: How did you produce that list with 12 bugs? (Which are they?) I get either more or less depending on options. I simply searched for open bugs with target 1.4.0. Now I get 11, since Jean-Marc has fixed # 2092: http://bugzilla.lyx.org/buglist.cgi?short_desc_type=allwordssubstrshort_desc=target_milestone=1.4.0long_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=nowordskeywords=fixedintrunkbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=changedin=31chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= I did not yet have time to look at your patch. Georg
Re: Bug 580 fix
Georg Baum wrote: I simply searched for open bugs with target 1.4.0. Now I get 11, since Jean-Marc has fixed # 2092: I get 15: http://tinyurl.com/7qacq Jürgen
Re: Bug 580 fix
Juergen Spitzmueller wrote: Georg Baum wrote: I simply searched for open bugs with target 1.4.0. Now I get 11, since Jean-Marc has fixed # 2092: I get 15: http://tinyurl.com/7qacq Jürgen And the reason is... G:bug_status=UNCONFIRMED G:changedin=31 J:changedin= J:namedcmd=24h+changes -- Angus
Re: Bug 580 fix
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Georg Baum wrote: I simply searched for open bugs with target 1.4.0. Now I get 11, since Jean-Marc has fixed # 2092: Juergen I get 15: I get 16, because your search ignores UNCONFIRMED bugs. JMarc
Re: Bug 580 fix
Angus Leeming wrote: And the reason is... G:bug_status=UNCONFIRMED G:changedin=31 J:changedin= J:namedcmd=24h+changes Both was not intended. Seems it is time again to say that I don't like bugzilla. Georg
Re: Bug 580 fix
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Attached. It fixes the reported bug in a way that is logical Martin and understandable, and makes tabular.C a little less messy. Martin It may be true that lyx 1.4 cannot produce these crippled Martin files, but still it's better of we can handle them. Besides the fact that now is not the best time to fix this bug, I do not understand why we would want to add code to LyX to avoid a bug that is not there anymore. Would it be possible to do this through lyx2lyx, or is the tabular syntax too difficult to catter for? JMarc
Re: Bug 580 fix
Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Attached. It fixes the reported bug in a way that is logical Martin and understandable, and makes tabular.C a little less messy. Martin It may be true that lyx 1.4 cannot produce these crippled Martin files, but still it's better of we can handle them. Besides the fact that now is not the best time to fix this bug, I do not understand why we would want to add code to LyX to avoid a bug that is not there anymore. Would it be possible to do this through lyx2lyx, or is the tabular syntax too difficult to catter for? This is no task for lyx2lyx IMO. LyX should be so robust that invalid files don't lead to broken display or other failures. IMO the best way to achieve this is to check the structure of the table after reading it from file and then rely on the correct structure. This is what we are doing in mathed BTW. I agree that this is not for now. Georg
Re: Bug 580 fix
On Fri, 2005-10-28 at 16:26 +0200, Georg Baum wrote: Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Attached. It fixes the reported bug in a way that is logical Martin and understandable, and makes tabular.C a little less messy. Martin It may be true that lyx 1.4 cannot produce these crippled Martin files, but still it's better of we can handle them. Besides the fact that now is not the best time to fix this bug, I do not understand why we would want to add code to LyX to avoid a bug that is not there anymore. Would it be possible to do this through lyx2lyx, or is the tabular syntax too difficult to catter for? This is no task for lyx2lyx IMO. LyX should be so robust that invalid files don't lead to broken display or other failures. IMO the best way to achieve this is to check the structure of the table after reading it from file and then rely on the correct structure. Which is precisely what the patch is doing. This is what we are doing in mathed BTW. I agree that this is not for now. OK, it's in bugzilla waiting for the right time. - Martin signature.asc Description: This is a digitally signed message part
Re: Bug 580 fix
Martin Vermeer wrote: > How did you produce that list with 12 bugs? (Which are they?) I get > either more or less depending on options. I simply searched for open bugs with target 1.4.0. Now I get 11, since Jean-Marc has fixed # 2092: http://bugzilla.lyx.org/buglist.cgi?short_desc_type=allwordssubstr_desc=_milestone=1.4.0_desc_type=allwordssubstr_desc=_file_loc_type=allwordssubstr_file_loc=_type=nowords=fixedintrunk_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=substring==substring==include_id===31==Now==doit==Reuse+same+sort+as+last+time=noop=noop= I did not yet have time to look at your patch. Georg
Re: Bug 580 fix
Georg Baum wrote: > I simply searched for open bugs with target 1.4.0. Now I get 11, since > Jean-Marc has fixed # 2092: I get 15: http://tinyurl.com/7qacq Jürgen
Re: Bug 580 fix
Juergen Spitzmueller wrote: > Georg Baum wrote: >> I simply searched for open bugs with target 1.4.0. Now I get 11, >> since Jean-Marc has fixed # 2092: > > I get 15: > > http://tinyurl.com/7qacq > Jürgen And the reason is... G:bug_status=UNCONFIRMED& G:changedin=31& J:changedin=& J:namedcmd=24h+changes& -- Angus
Re: Bug 580 fix
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Georg Baum wrote: >> I simply searched for open bugs with target 1.4.0. Now I get 11, >> since Jean-Marc has fixed # 2092: Juergen> I get 15: I get 16, because your search ignores UNCONFIRMED bugs. JMarc
Re: Bug 580 fix
Angus Leeming wrote: > And the reason is... > > G:bug_status=UNCONFIRMED& > G:changedin=31& > J:changedin=& > J:namedcmd=24h+changes& Both was not intended. Seems it is time again to say that I don't like bugzilla. Georg
Re: Bug 580 fix
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> Attached. It fixes the reported bug in a way that is logical Martin> and understandable, and makes tabular.C a little less messy. Martin> It may be true that lyx 1.4 cannot produce these crippled Martin> files, but still it's better of we can handle them. Besides the fact that now is not the best time to fix this bug, I do not understand why we would want to add code to LyX to avoid a bug that is not there anymore. Would it be possible to do this through lyx2lyx, or is the tabular syntax too difficult to catter for? JMarc
Re: Bug 580 fix
Jean-Marc Lasgouttes wrote: >> "Martin" == Martin Vermeer >> <[EMAIL PROTECTED]> writes: > > Martin> Attached. It fixes the reported bug in a way that is logical > Martin> and understandable, and makes tabular.C a little less messy. > > Martin> It may be true that lyx 1.4 cannot produce these crippled > Martin> files, but still it's better of we can handle them. > > Besides the fact that now is not the best time to fix this bug, I do > not understand why we would want to add code to LyX to avoid a bug > that is not there anymore. > > Would it be possible to do this through lyx2lyx, or is the tabular > syntax too difficult to catter for? This is no task for lyx2lyx IMO. LyX should be so robust that invalid files don't lead to broken display or other failures. IMO the best way to achieve this is to check the structure of the table after reading it from file and then rely on the correct structure. This is what we are doing in mathed BTW. I agree that this is not for now. Georg
Re: Bug 580 fix
On Fri, 2005-10-28 at 16:26 +0200, Georg Baum wrote: > Jean-Marc Lasgouttes wrote: > > >> "Martin" == Martin Vermeer > >> <[EMAIL PROTECTED]> writes: > > > > Martin> Attached. It fixes the reported bug in a way that is logical > > Martin> and understandable, and makes tabular.C a little less messy. > > > > Martin> It may be true that lyx 1.4 cannot produce these crippled > > Martin> files, but still it's better of we can handle them. > > > > Besides the fact that now is not the best time to fix this bug, I do > > not understand why we would want to add code to LyX to avoid a bug > > that is not there anymore. > > > > Would it be possible to do this through lyx2lyx, or is the tabular > > syntax too difficult to catter for? > > This is no task for lyx2lyx IMO. LyX should be so robust that invalid files > don't lead to broken display or other failures. IMO the best way to achieve > this is to check the structure of the table after reading it from file and > then rely on the correct structure. Which is precisely what the patch is doing. > This is what we are doing in mathed BTW. > I agree that this is not for now. OK, it's in bugzilla waiting for the right time. - Martin signature.asc Description: This is a digitally signed message part
Re: Bug 580 fix
On Wed, 2005-10-26 at 17:45 +0200, Jean-Marc Lasgouttes wrote:
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg That is true, but please let's not forget that we want to
Georg create 1.4.0 as soon as possible. This bug is certainly not
Georg release-critical, so it would be better to work on one of the
Georg 12 open bugs with target 1.4.0.
Definitely.
Georg My favorite one is
Georg http://bugzilla.lyx.org/show_bug.cgi?id=1814.
Actually, most of the remaining open bugs are reasonably challenging
to fix and _have_ to be fixed.
JMarc
Try this on for size.
- Martin
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.598
diff -u -p -r1.598 BufferView_pimpl.C
--- BufferView_pimpl.C 11 Oct 2005 11:29:35 - 1.598
+++ BufferView_pimpl.C 27 Oct 2005 09:58:20 -
@@ -141,8 +141,8 @@ T * getInsetByCode(LCursor cur, InsetB
BufferView::Pimpl::Pimpl(BufferView bv, LyXView * owner,
int width, int height)
- : bv_(bv), owner_(owner), buffer_(0), cursor_timeout(400),
- using_xterm_cursor(false), cursor_(bv) ,
+ : bv_(bv), owner_(owner), buffer_(0), wh_(0), cursor_timeout(400),
+ using_xterm_cursor(false), cursor_(bv),
anchor_ref_(0), offset_ref_(0)
{
xsel_cache_.set = false;
@@ -439,8 +439,9 @@ void BufferView::Pimpl::updateScrollbar(
}
LyXText t = *bv_-text();
- if (anchor_ref_ int(t.paragraphs().size()) - 1) {
- anchor_ref_ = int(t.paragraphs().size()) - 1;
+ int const parsize = int(t.paragraphs().size() - 1);
+ if (anchor_ref_ parsize) {
+ anchor_ref_ = parsize;
offset_ref_ = 0;
}
@@ -454,21 +455,34 @@ void BufferView::Pimpl::updateScrollbar(
// values in [0..1] and divide everything by wh
// estimated average paragraph height:
- int const wh = workarea().workHeight() / 4;
+ if (wh_ == 0)
+ wh_ = workarea().workHeight() / 4;
int h = t.getPar(anchor_ref_).height();
+
// Normalize anchor/offset (MV):
- while (offset_ref_ h) {
+ while (offset_ref_ h anchor_ref_ parsize) {
anchor_ref_++;
offset_ref_ -= h;
h = t.getPar(anchor_ref_).height();
}
+ // Look at paragraph heights on-screen
+ int sumh = 0;
+ int nh = 0;
+ for (lyx::pit_type pit = anchor_ref_; pit = parsize; ++pit) {
+ if (sumh workarea().workHeight())
+ break;
+ int const h2 = t.getPar(pit).height();
+ sumh += h2;
+ nh++;
+ }
+ int const hav = sumh / nh;
+ // More realistic average paragraph height
+ if (hav wh_)
+ wh_ = hav;
- // The + 2 makes inoculates doc bottom display against
- // unrealistic wh values (docs with very large paragraphs) (MV)
- workarea().setScrollbarParams((t.paragraphs().size() + 2) * wh,
- anchor_ref_ * wh + int(offset_ref_ * wh / float(h)),
- int(wh * defaultRowHeight() / float(h)));
-// workarea().setScrollbarParams(t.paragraphs().size(), anchor_ref_, 1);
+ workarea().setScrollbarParams((parsize + 1) * wh_,
+ anchor_ref_ * wh_ + int(offset_ref_ * wh_ / float(h)),
+ int(wh_ * defaultRowHeight() / float(h)));
}
@@ -482,13 +496,13 @@ void BufferView::Pimpl::scrollDocView(in
screen().hideCursor();
- int const wh = workarea().workHeight() / 4;
-
LyXText t = *bv_-text();
- float const bar = value / float(wh * t.paragraphs().size());
+ float const bar = value / float(wh_ * t.paragraphs().size());
anchor_ref_ = int(bar * t.paragraphs().size());
+ if (anchor_ref_ int(t.paragraphs().size()) - 1)
+ anchor_ref_ = int(t.paragraphs().size()) - 1;
t.redoParagraph(anchor_ref_);
int const h = t.getPar(anchor_ref_).height();
offset_ref_ = int((bar * t.paragraphs().size() - anchor_ref_) * h);
Index: BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.128
diff -u -p -r1.128 BufferView_pimpl.h
--- BufferView_pimpl.h 31 May 2005 14:40:24 - 1.128
+++ BufferView_pimpl.h 27 Oct 2005 09:58:20 -
@@ -145,6 +145,8 @@ private:
boost::scoped_ptrLyXScreen screen_;
///
boost::scoped_ptrWorkArea workarea_;
+ /// Estimated average par height for scrollbar
+ int wh_;
///
Timeout cursor_timeout;
///
signature.asc
Description: This is a digitally signed message part
Re: Bug 580 fix
On Wed, Oct 26, 2005 at 04:43:11PM +0200, Georg Baum wrote: Martin Vermeer wrote: Attached. It fixes the reported bug in a way that is logical and understandable, and makes tabular.C a little less messy. It may be true that lyx 1.4 cannot produce these crippled files, but still it's better of we can handle them. That is true, but please let's not forget that we want to create 1.4.0 as soon as possible. This bug is certainly not release-critical, so it would be better to work on one of the 12 open bugs with target 1.4.0. My favorite one is http://bugzilla.lyx.org/show_bug.cgi?id=1814. How did you produce that list with 12 bugs? (Which are they?) I get either more or less depending on options. - Martin pgp3mPakIezJo.pgp Description: PGP signature
Re: Bug 580 fix
On Wed, 2005-10-26 at 17:45 +0200, Jean-Marc Lasgouttes wrote:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> That is true, but please let's not forget that we want to
> Georg> create 1.4.0 as soon as possible. This bug is certainly not
> Georg> release-critical, so it would be better to work on one of the
> Georg> 12 open bugs with target 1.4.0.
>
> Definitely.
>
> Georg> My favorite one is
> Georg> http://bugzilla.lyx.org/show_bug.cgi?id=1814.
>
> Actually, most of the remaining open bugs are reasonably challenging
> to fix and _have_ to be fixed.
>
> JMarc
Try this on for size.
- Martin
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.598
diff -u -p -r1.598 BufferView_pimpl.C
--- BufferView_pimpl.C 11 Oct 2005 11:29:35 - 1.598
+++ BufferView_pimpl.C 27 Oct 2005 09:58:20 -
@@ -141,8 +141,8 @@ T * getInsetByCode(LCursor & cur, InsetB
BufferView::Pimpl::Pimpl(BufferView & bv, LyXView * owner,
int width, int height)
- : bv_(), owner_(owner), buffer_(0), cursor_timeout(400),
- using_xterm_cursor(false), cursor_(bv) ,
+ : bv_(), owner_(owner), buffer_(0), wh_(0), cursor_timeout(400),
+ using_xterm_cursor(false), cursor_(bv),
anchor_ref_(0), offset_ref_(0)
{
xsel_cache_.set = false;
@@ -439,8 +439,9 @@ void BufferView::Pimpl::updateScrollbar(
}
LyXText & t = *bv_->text();
- if (anchor_ref_ > int(t.paragraphs().size()) - 1) {
- anchor_ref_ = int(t.paragraphs().size()) - 1;
+ int const parsize = int(t.paragraphs().size() - 1);
+ if (anchor_ref_ > parsize) {
+ anchor_ref_ = parsize;
offset_ref_ = 0;
}
@@ -454,21 +455,34 @@ void BufferView::Pimpl::updateScrollbar(
// values in [0..1] and divide everything by wh
// estimated average paragraph height:
- int const wh = workarea().workHeight() / 4;
+ if (wh_ == 0)
+ wh_ = workarea().workHeight() / 4;
int h = t.getPar(anchor_ref_).height();
+
// Normalize anchor/offset (MV):
- while (offset_ref_ > h) {
+ while (offset_ref_ > h && anchor_ref_ < parsize) {
anchor_ref_++;
offset_ref_ -= h;
h = t.getPar(anchor_ref_).height();
}
+ // Look at paragraph heights on-screen
+ int sumh = 0;
+ int nh = 0;
+ for (lyx::pit_type pit = anchor_ref_; pit <= parsize; ++pit) {
+ if (sumh > workarea().workHeight())
+ break;
+ int const h2 = t.getPar(pit).height();
+ sumh += h2;
+ nh++;
+ }
+ int const hav = sumh / nh;
+ // More realistic average paragraph height
+ if (hav > wh_)
+ wh_ = hav;
- // The "+ 2" makes inoculates doc bottom display against
- // unrealistic wh values (docs with very large paragraphs) (MV)
- workarea().setScrollbarParams((t.paragraphs().size() + 2) * wh,
- anchor_ref_ * wh + int(offset_ref_ * wh / float(h)),
- int(wh * defaultRowHeight() / float(h)));
-// workarea().setScrollbarParams(t.paragraphs().size(), anchor_ref_, 1);
+ workarea().setScrollbarParams((parsize + 1) * wh_,
+ anchor_ref_ * wh_ + int(offset_ref_ * wh_ / float(h)),
+ int(wh_ * defaultRowHeight() / float(h)));
}
@@ -482,13 +496,13 @@ void BufferView::Pimpl::scrollDocView(in
screen().hideCursor();
- int const wh = workarea().workHeight() / 4;
-
LyXText & t = *bv_->text();
- float const bar = value / float(wh * t.paragraphs().size());
+ float const bar = value / float(wh_ * t.paragraphs().size());
anchor_ref_ = int(bar * t.paragraphs().size());
+ if (anchor_ref_ > int(t.paragraphs().size()) - 1)
+ anchor_ref_ = int(t.paragraphs().size()) - 1;
t.redoParagraph(anchor_ref_);
int const h = t.getPar(anchor_ref_).height();
offset_ref_ = int((bar * t.paragraphs().size() - anchor_ref_) * h);
Index: BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.128
diff -u -p -r1.128 BufferView_pimpl.h
--- BufferView_pimpl.h 31 May 2005 14:40:24 - 1.128
+++ BufferView_pimpl.h 27 Oct 2005 09:58:20 -
@@ -145,6 +145,8 @@ private:
boost::scoped_ptr screen_;
///
boost::scoped_ptr workarea_;
+ /// Estimated average par height for scrollbar
+ int wh_;
///
Timeout cursor_timeout;
///
signature.asc
Description: This is a digitally signed message part
Re: Bug 580 fix
On Wed, Oct 26, 2005 at 04:43:11PM +0200, Georg Baum wrote: > Martin Vermeer wrote: > > > Attached. It fixes the reported bug in a way that is logical and > > understandable, and makes tabular.C a little less messy. > > > > It may be true that lyx 1.4 cannot produce these crippled files, but > > still it's better of we can handle them. > > That is true, but please let's not forget that we want to create 1.4.0 as > soon as possible. This bug is certainly not release-critical, so it would > be better to work on one of the 12 open bugs with target 1.4.0. My favorite > one is http://bugzilla.lyx.org/show_bug.cgi?id=1814. How did you produce that list with 12 bugs? (Which are they?) I get either more or less depending on options. - Martin pgp3mPakIezJo.pgp Description: PGP signature
Re: Bug 580 fix
Martin Vermeer wrote: Attached. It fixes the reported bug in a way that is logical and understandable, and makes tabular.C a little less messy. It may be true that lyx 1.4 cannot produce these crippled files, but still it's better of we can handle them. That is true, but please let's not forget that we want to create 1.4.0 as soon as possible. This bug is certainly not release-critical, so it would be better to work on one of the 12 open bugs with target 1.4.0. My favorite one is http://bugzilla.lyx.org/show_bug.cgi?id=1814. Georg
Re: Bug 580 fix
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg That is true, but please let's not forget that we want to Georg create 1.4.0 as soon as possible. This bug is certainly not Georg release-critical, so it would be better to work on one of the Georg 12 open bugs with target 1.4.0. Definitely. Georg My favorite one is Georg http://bugzilla.lyx.org/show_bug.cgi?id=1814. Actually, most of the remaining open bugs are reasonably challenging to fix and _have_ to be fixed. JMarc
Re: Bug 580 fix
On Wed, Oct 26, 2005 at 05:45:09PM +0200, Jean-Marc Lasgouttes wrote: Georg == Georg Baum [EMAIL PROTECTED] writes: Georg That is true, but please let's not forget that we want to Georg create 1.4.0 as soon as possible. This bug is certainly not Georg release-critical, so it would be better to work on one of the Georg 12 open bugs with target 1.4.0. Definitely. Georg My favorite one is Georg http://bugzilla.lyx.org/show_bug.cgi?id=1814. Actually, most of the remaining open bugs are reasonably challenging to fix and _have_ to be fixed. JMarc Does that mean that you agree that my patch for 580 goes in, provided I fix 1814? I've been offered worse deals ;-) - Martin pgpkbXqimfLCc.pgp Description: PGP signature
Re: Bug 580 fix
Martin Vermeer wrote: > Attached. It fixes the reported bug in a way that is logical and > understandable, and makes tabular.C a little less messy. > > It may be true that lyx 1.4 cannot produce these crippled files, but > still it's better of we can handle them. That is true, but please let's not forget that we want to create 1.4.0 as soon as possible. This bug is certainly not release-critical, so it would be better to work on one of the 12 open bugs with target 1.4.0. My favorite one is http://bugzilla.lyx.org/show_bug.cgi?id=1814. Georg
Re: Bug 580 fix
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> That is true, but please let's not forget that we want to Georg> create 1.4.0 as soon as possible. This bug is certainly not Georg> release-critical, so it would be better to work on one of the Georg> 12 open bugs with target 1.4.0. Definitely. Georg> My favorite one is Georg> http://bugzilla.lyx.org/show_bug.cgi?id=1814. Actually, most of the remaining open bugs are reasonably challenging to fix and _have_ to be fixed. JMarc
Re: Bug 580 fix
On Wed, Oct 26, 2005 at 05:45:09PM +0200, Jean-Marc Lasgouttes wrote: > > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: > > Georg> That is true, but please let's not forget that we want to > Georg> create 1.4.0 as soon as possible. This bug is certainly not > Georg> release-critical, so it would be better to work on one of the > Georg> 12 open bugs with target 1.4.0. > > Definitely. > > Georg> My favorite one is > Georg> http://bugzilla.lyx.org/show_bug.cgi?id=1814. > > Actually, most of the remaining open bugs are reasonably challenging > to fix and _have_ to be fixed. > > JMarc Does that mean that you agree that my patch for 580 goes in, provided I fix 1814? I've been offered worse deals ;-) - Martin pgpkbXqimfLCc.pgp Description: PGP signature
