Re: [patch] new scrollbar code
On Wed, Mar 30, 2005 at 09:01:02PM +0200, Alfredo Braunstein wrote: One option is to eliminate the scrollbar size completely (i.e. make it fixed size). Or perhaps 1/#paragraphs + const or something similar that keeps constant during plain scrolling. Andre'
Re: [patch] new scrollbar code
On Wed, Mar 30, 2005 at 09:01:02PM +0200, Alfredo Braunstein wrote: > One option is to eliminate the scrollbar size completely (i.e. make it > fixed size). Or perhaps 1/#paragraphs + const or something similar that keeps constant during plain scrolling. Andre'
Re: [patch] new scrollbar code
John Levon wrote: On Wed, Mar 30, 2005 at 09:01:02PM +0200, Alfredo Braunstein wrote: On your document indeed the scrollbar resizes a lot (the reason is obvious, we have paragraphs of very different vertical size). OK, we need to go to Mac-style scrollbars where the widget is of a fixed size. It's unusable otherwise IMHO. This is easy. OTOH, I'm a bit confused by your 'unusable'. Setting the widget to fixed size would make no difference in useability AFAICS. Still I don't find it's completely broken, scrolling from top to bottom is possible (even if 'speed' is very variable). I don't see jumps. I see both jumps and the document getting stuck with no progress being made when holding down the button to continuously scroll. qt version? Please give detailed instructions. Alfredo
Re: [patch] new scrollbar code
Georg Baum wrote: Am Mittwoch, 30. Mrz 2005 19:51 schrieb John Levon: On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: Lots of testing needed... Dragging the scrollbar on the Qt frontend is very broken (I tried with small document). It constantly resizes itself, jumps about. etc I see this, too (also qt). The fact that it resizes itself is normal (altough the resizing should be smooth). It shouldn't jump. I don't understand if both of you are seeing the same behaviour as I do and find it ugly or if you are seeing something different. Could you describe some behaviour you find weird in a few steps? Thanks. I noticed also that there is almost always a brown area below the document, even if the document is larger than the screen. Resizing the main window does not work properly: The scrollbar height is not updated when I resize the window at the top border (see image) resizing at the bottom works. Truly weird. Thanks for the testing. Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote:
Dragging the scrollbar on the Qt frontend is very broken (I tried with
small document). It constantly resizes itself, jumps about. etc
I see this, too (also qt).
The fact that it resizes itself is normal (altough the resizing should be
smooth). It shouldn't jump. I don't understand if both of you are seeing
the same behaviour as I do and find it ugly or if you are seeing something
different.
Could you describe some behaviour you find weird in a few steps? Thanks.
In case we are testing different things, here's an updated patch. It
suffices to uncomment the commented line in WorkArea.C:78 to test a
fixed-size widget scrollbar.
Regards, Alfredo
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.260
diff -u -p -u -r1.260 BufferView.C
--- BufferView.C 22 Feb 2005 11:41:19 - 1.260
+++ BufferView.C 31 Mar 2005 10:00:28 -
@@ -148,12 +148,6 @@ void BufferView::update(bool fitcursor,
}
-void BufferView::updateScrollbar()
-{
- pimpl_-updateScrollbar();
-}
-
-
void BufferView::scrollDocView(int value)
{
pimpl_-scrollDocView(value);
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.185
diff -u -p -u -r1.185 BufferView.h
--- BufferView.h 22 Feb 2005 11:41:19 - 1.185
+++ BufferView.h 31 Mar 2005 10:00:28 -
@@ -85,8 +85,6 @@ public:
/// move the screen to fit the cursor. Only to be called with
/// good y coordinates (after a bv::metrics)
bool fitCursor();
- /// reset the scrollbar to reflect current view position
- void updateScrollbar();
/// FIXME
bool available() const;
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.580
diff -u -p -u -r1.580 BufferView_pimpl.C
--- BufferView_pimpl.C 25 Feb 2005 11:55:29 - 1.580
+++ BufferView_pimpl.C 31 Mar 2005 10:00:29 -
@@ -100,7 +100,6 @@ using std::string;
using std::mem_fun_ref;
using std::vector;
-
extern BufferList bufferlist;
@@ -113,6 +112,10 @@ unsigned int const saved_positions_num =
// to these connections we avoid a segfault upon startup, and also at exit.
// (Lgb)
+boost::signals::connection pagedowncon;
+boost::signals::connection pageupcon;
+boost::signals::connection lineupcon;
+boost::signals::connection linedowncon;
boost::signals::connection dispatchcon;
boost::signals::connection timecon;
boost::signals::connection doccon;
@@ -152,6 +155,15 @@ BufferView::Pimpl::Pimpl(BufferView bv
// Setup the signals
doccon = workarea().scrollDocView
.connect(boost::bind(BufferView::Pimpl::scrollDocView, this, _1));
+ pageupcon = workarea().scrollPageUp
+ .connect(boost::bind(BufferView::Pimpl::scrollPageUp, this));
+
+ pagedowncon = workarea().scrollPageDown
+ .connect(boost::bind(BufferView::Pimpl::scrollPageDown, this));
+ lineupcon = workarea().scrollLineUp
+ .connect(boost::bind(BufferView::Pimpl::scrollLineUp, this));
+ linedowncon = workarea().scrollLineDown
+ .connect(boost::bind(BufferView::Pimpl::scrollLineDown, this));
resizecon = workarea().workAreaResize
.connect(boost::bind(BufferView::Pimpl::workAreaResize, this));
dispatchcon = workarea().dispatch
@@ -365,7 +377,6 @@ void BufferView::Pimpl::setBuffer(Buffer
}
update();
- updateScrollbar();
owner_-updateMenubar();
owner_-updateToolbars();
owner_-updateLayoutChoice();
@@ -399,16 +410,15 @@ void BufferView::Pimpl::resizeCurrentBuf
// Reset the Formatting... message
owner_-clearMessage();
- updateScrollbar();
}
-void BufferView::Pimpl::updateScrollbar()
+void BufferView::Pimpl::updateScrollbar(ViewMetricsInfo const vi)
{
if (!bv_-text()) {
lyxerr[Debug::DEBUG] BOOST_CURRENT_FUNCTION
no text in updateScrollbar endl;
- workarea().setScrollbarParams(0, 0, 0);
+ workarea().setScrollbarParams(0, 0);
return;
}
@@ -424,35 +434,71 @@ void BufferView::Pimpl::updateScrollbar(
curr par: cursor_.bottom().pit()
default height defaultRowHeight() endl;
- // It would be better to fix the scrollbar to understand
- // values in [0..1] and divide everything by wh
- int const wh = workarea().workHeight() / 4;
- int const h = t.getPar(anchor_ref_).height();
- workarea().setScrollbarParams(t.paragraphs().size() * wh, anchor_ref_ * wh + int(offset_ref_ * wh / float(h)), int (wh * defaultRowHeight() / float(h)));
-// workarea().setScrollbarParams(t.paragraphs().size(), anchor_ref_, 1);
+ int const h1 = t.getPar(vi.p1).height();
+ int const h2 = t.getPar(vi.p2).height();
+ double const chop1 = (- vi.y1) / double(h1);
+ double const chop2 = (vi.y2 - workarea().workHeight()) / double(h2);
+ double const tot = t.paragraphs().size();
+ double const pos = (vi.p1 + chop1) / tot;
+
Re: [patch] new scrollbar code
I believe that a fixed sized scroll bar is a significant regression in terms of usability. Also, I think that a very unreliable scroll bar is a problem. The scroll bar can change a few pixels, but if it jumps much more than that, it is confusing. I did not test the new scrollbar, but if you use a uniform estimated size on all paragraphs, I think the obvious thing is to improve this by estimating the height as a function of the number of characters in the paragraph and the width available for the paragraph. You can define a function for this which calculates in constant time by using mean values for the character width and word length. To improve further, consider the insets in the paragraph by having a default size for each type and take that into account. Now, we are linear time in the number of insets, but no loading or rendering of insets are necessary to get the estimate, so it is still very fast. If this is still not accurate enough, then I'd go for better handling of the biggest elements that can appear in a document: images, tables and such. Ultimately, if such patching up does not fix the problem, we have to admit that it was a mistake, and introduce full document word breaking again. The scrollbar is one of the single most important features in a word processor. You use it all the time. You want that to be reliable and not seem strange. Regards, Asger
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 11:12:51AM +0200, Alfredo Braunstein wrote: This is easy. OTOH, I'm a bit confused by your 'unusable'. Setting the widget to fixed size would make no difference in useability AFAICS. Having the widget constantly change size on you is extremely disconcerting. qt version? Please give detailed instructions. Later regards john
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 01:08:48PM +0200, Asger Alstrup wrote: I believe that a fixed sized scroll bar is a significant regression in terms of usability. Asger, we lost the ability to have a properly working scrollbar after the core rewrite. I'm sure there are reasons it's difficult to do this, so I am afraid we are stuck with it, and complaining will only irritate people (usually my forte) The question is how can we salvage the situation to make it as good as we can. To improve further, consider the insets in the paragraph by having a default size for each type and take that into account. Now, we are linear There's no such thing as a linear size for figures, so this is guaranteed to go wrong in the worst possible cases (very large figures). regards john
Re: [patch] new scrollbar code
Asger Alstrup wrote: I believe that a fixed sized scroll bar is a significant regression in terms of usability. I'm not sure about that. Specially since there's no difference in the scrollbar size in a mid-sized document vs a big document like UG, because most toolkits have a minimum size for the widget. Also, I think that a very unreliable scroll bar is a problem. The scroll bar can change a few pixels, but if it jumps much more than that, it is confusing. It shouldn't jump at all (otherwise is just a bug). I did not test the new scrollbar, but if you use a uniform estimated size on all paragraphs, I think the obvious thing is to improve this by estimating the height as a function of the number of characters in the paragraph and the width available for the paragraph. You can define a function for this which calculates in constant time by using mean values for the character width and word length. Constant time per paragraph, O(number of paragraphs) total time To improve further, consider the insets in the paragraph by having a default size for each type and take that into account. Now, we are linear time in the number of insets, but no loading or rendering of insets are necessary to get the estimate, so it is still very fast. The biggest problem seems to be very high insets, like long tabulars If this is still not accurate enough, then I'd go for better handling of the biggest elements that can appear in a document: images, tables and such. This could be, the question is how to do this consistently. Otherwise we will always have problems with corner cases. Ultimately, if such patching up does not fix the problem, we have to admit that it was a mistake, and introduce full document word breaking again. It may be, but I am afraid that we cannot afford this. The scrollbar is one of the single most important features in a word processor. You use it all the time. You want that to be reliable and not seem strange. Sure, it is important. The problem is if what we have is good enough or not. An alternative you didn't mention would be to have background computation of the exact size (including full rebreak etc). Alfredo
Re: [patch] new scrollbar code
John Levon wrote:
To improve further, consider the insets in the paragraph by having a
default size for each type and take that into account. Now, we are linear
There's no such thing as a linear size for figures, so this is
guaranteed to go wrong in the worst possible cases (very large figures).
I believe it is monotoneously better to estimate all figures at say 200x200
pixels, rather than at 0x0 pixels like it does now.
The linear bit in my sentence refers to the time it takes to estimate the
height of a paragraph: The algorithm is roughly something like this:
int x = 0;
int y = average-character-height;
for (int i = 0; i != numberOfInsets-in-paragraph; ++i) {
// First estimate size of the text
x += average-character-width
* number-of-characters-in-paragraph
/ numberOfInsets-in-paragraph;
y += (x / width-available) * average-character-height;
x = x % width-available;
// Next estimate size of the insets
x += average-width-of-inset-at-position(i);
if (x width-available) {
y += average-height;
x = x % width-available;
}
}
Notice small constant factors and linear time in number of insets. That
should be fast enough, and improve tremendously on a totally static estimate.
My point is that this estimation routine can be continuously refined until
it represents a complete rendering of the paragraph. We need to try and
find out how fine-grained the estimate has to be in order for the scroll
bar to be usable.
Regards,
Asger
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 01:54:11PM +0200, Asger Alstrup wrote: I believe it is monotoneously better to estimate all figures at say 200x200 pixels, rather than at 0x0 pixels like it does now. Well, perhaps, but I doubt it significantly helps. My point is that this estimation routine can be continuously refined until it represents a complete rendering of the paragraph. We need to try and find out how fine-grained the estimate has to be in order for the scroll bar to be usable. Fair enough. I suspect the real answer is full rebreaking... regards john
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: The fact that it resizes itself is normal (altough the resizing should be smooth). It shouldn't jump. I don't understand if both of you are seeing the same behaviour as I do and find it ugly or if you are seeing something different. I am actually not sure if it is all the same. Could you describe some behaviour you find weird in a few steps? Thanks. - Create a document with some paragraphs (~20, only text, one line each) - resize the main window to the smallest possible height - drag the scrollbar from top to bottom. It will not follow the cursor immediately, and if you don't drag it to the lowest possible position it will jump back to the top. It will also jump back if you drag it to the end, but will afterwards jump to the bottom. I see also the jumping and getting stuck when pressing PgDown that John observed. BTW, this is qt 3.3.3 (stock SuSE 9.2) and yor second version of the patch. Resizing the main window does not work properly: The scrollbar height is not updated when I resize the window at the top border (see image) resizing at the bottom works. Truly weird. This happens with both qt 3.4 and 3.3.3 Georg
Re: [patch] new scrollbar code
John Levon wrote: On Thu, Mar 31, 2005 at 01:54:11PM +0200, Asger Alstrup wrote: I believe it is monotoneously better to estimate all figures at say 200x200 pixels, rather than at 0x0 pixels like it does now. Well, perhaps, but I doubt it significantly helps. My point is that this estimation routine can be continuously refined until it represents a complete rendering of the paragraph. We need to try and find out how fine-grained the estimate has to be in order for the scroll bar to be usable. Fair enough. I suspect the real answer is full rebreaking... Always optimitic, huh? ;-) Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: I'm not sure about that. Specially since there's no difference in the scrollbar size in a mid-sized document vs a big document like UG, because most toolkits have a minimum size for the widget. Small documents are important too. It shouldn't jump at all (otherwise is just a bug). The size should not change more than a few pixels either. Constant time per paragraph, O(number of paragraphs) total time And can't we afford this? If so, our paragraph list traversal sucks and should be changed. The biggest problem seems to be very high insets, like long tabulars Great, then try to address those, and see what is the next problem. This is exactly the approach I'm advocating. This could be, the question is how to do this consistently. Otherwise we will always have problems with corner cases. It is still monotoneously better than ignoring the problem. Ultimately, if such patching up does not fix the problem, we have to admit that it was a mistake, and introduce full document word breaking again. It may be, but I am afraid that we cannot afford this. We used to be able to afford it, so it is affordable. It might not be feasible with the current rewritten core, but then the rewrite is not complete or a failure. An alternative you didn't mention would be to have background computation of the exact size (including full rebreak etc). This is similar to what web-browsers do as they receive the data, so that might be acceptable. But I thought the problem was that keeping the data up-to-date as the document changes is the problem? You will not avoid that can of worms with background rebreak. Regards, Asger
Re: [patch] new scrollbar code
Hi Georg, Georg Baum wrote: Alfredo Braunstein wrote: The fact that it resizes itself is normal (altough the resizing should be smooth). It shouldn't jump. I don't understand if both of you are seeing the same behaviour as I do and find it ugly or if you are seeing something different. I am actually not sure if it is all the same. It seems different indeed. Could you describe some behaviour you find weird in a few steps? Thanks. - Create a document with some paragraphs (~20, only text, one line each) - resize the main window to the smallest possible height - drag the scrollbar from top to bottom. It will not follow the cursor immediately, and if you don't drag it to the lowest possible position it will jump back to the top. It will also jump back if you drag it to the end, but will afterwards jump to the bottom. This is very strange, I cannot reproduce. I see also the jumping and getting stuck when pressing PgDown that John observed. You mean pagedown on the keyboard, or clicking on the scrollbar background (i.e. scrollbar pgdown) BTW, this is qt 3.3.3 (stock SuSE 9.2) and yor second version of the patch. This is qt-3.3.4-0.fc3.0 on fc3. Resizing the main window does not work properly: The scrollbar height is not updated when I resize the window at the top border (see image) resizing at the bottom works. Truly weird. This happens with both qt 3.4 and 3.3.3 Cannot reproduce either. Regards, Alfredo PS: in any case, your test case should be one of these in which the scheme works fine (all paragraphs are equal in vertical size). So I find this really strange.
Re: [patch] new scrollbar code
Asger Alstrup wrote: Alfredo Braunstein wrote: I'm not sure about that. Specially since there's no difference in the scrollbar size in a mid-sized document vs a big document like UG, because most toolkits have a minimum size for the widget. Small documents are important too. Sure, I am only noting that it is a feature that only *exists* in small documents. Thus, it cannot be so fundamentally important. It shouldn't jump at all (otherwise is just a bug). The size should not change more than a few pixels either. Constant time per paragraph, O(number of paragraphs) total time And can't we afford this? If so, our paragraph list traversal sucks and should be changed. I wasn't saying anything about affordability, just clarifying that we need to compute the size of all paragraphs, not only onscreen ones. The biggest problem seems to be very high insets, like long tabulars Great, then try to address those, and see what is the next problem. This is exactly the approach I'm advocating. This could be, the question is how to do this consistently. Otherwise we will always have problems with corner cases. It is still monotoneously better than ignoring the problem. Hey, don be so picky. I'm very glad we are discussing this, it is certainly much better than ignoring the problem. Ultimately, if such patching up does not fix the problem, we have to admit that it was a mistake, and introduce full document word breaking again. It may be, but I am afraid that we cannot afford this. We used to be able to afford it, so it is affordable. It might not be feasible with the current rewritten core, but then the rewrite is not complete or a failure. I was talking in terms of man-power. An alternative you didn't mention would be to have background computation of the exact size (including full rebreak etc). This is similar to what web-browsers do as they receive the data, so that might be acceptable. But I thought the problem was that keeping the data up-to-date as the document changes is the problem? You will not avoid that can of worms with background rebreak. Well, we could just keep (maybe outdated) paragraphs sizes, and just update on-screen ones when drawing. Then the scrollbar computation would be only a loop over all outer paragraphs. Regards, Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: I believe it is monotoneously better to estimate all figures at say 200x200 pixels, rather than at 0x0 pixels like it does now. Well, perhaps, but I doubt it significantly helps. My point is that this estimation routine can be continuously refined until it represents a complete rendering of the paragraph. We need to try and find out how fine-grained the estimate has to be in order for the scroll bar to be usable. Fair enough. I suspect the real answer is full rebreaking... Always optimitic, huh? I haven't been following this thread very closely, but isn't the problem one of calculating the length of the document when it is first loaded? Thereafter, the scrollbar would change size only when the document was modified. (This could happen just by scrolling through a read-only document I guess as figures are loaded and therefore the graphics inset changes size.) Alfredo, would it be expensive to do a one time, accurate calculation of the document height? If so, why? Would use of the nullpainter help? -- Angus
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: Small documents are important too. Sure, I am only noting that it is a feature that only *exists* in small documents. Thus, it cannot be so fundamentally important. It serves as important feedback on the size of the document. Well, we could just keep (maybe outdated) paragraphs sizes, and just update on-screen ones when drawing. Then the scrollbar computation would be only a loop over all outer paragraphs. Since you mentioned that tables are the biggest problem, I would suggest to come up with a light-weight improved estimate for those, and see how much that helps. Then address images next. I.e. go down the path outlined in my earlier mail, except that the priorities are: - Tables - Images - Paragraph text size - Other stuff Only looking at outer paragraphs ignores the two most important ones. Regards, Asger
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: Georg Baum wrote: You mean pagedown on the keyboard, or clicking on the scrollbar background (i.e. scrollbar pgdown) I mean the key on the keyboard. Georg
Re: [patch] new scrollbar code
Angus Leeming wrote: I haven't been following this thread very closely, but isn't the problem one of calculating the length of the document when it is first loaded? Thereafter, the scrollbar would change size only when the document was modified. (This could happen just by scrolling through a read-only document I guess as figures are loaded and therefore the graphics inset changes size.) Alfredo, would it be expensive to do a one time, accurate calculation of the document height? If so, why? Would use of the nullpainter help? It's not terribly expensive, a fullRebreak of the UG is a matter of about a second on some fast computer (1.3.x does that on loading, and there is some loading time where it just said rebreaking document or something). We don't need the second drawing step, as all vertical height can be computed in the metrics phase. The problem, as Asger pointed out, is to mantain this information up-to-date. Think for instance of a change in evironment-depth, that may affect several screens down of paragrahs. IMO, though, we can live with 'old data size', and only update the information when drawing on screen. I may try to implement something like that this weekend. Regards, Alfredo
Re: [patch] new scrollbar code
Asger Alstrup wrote: Well, we could just keep (maybe outdated) paragraphs sizes, and just update on-screen ones when drawing. Then the scrollbar computation would be only a loop over all outer paragraphs. Only looking at outer paragraphs ignores the two most important ones. I think you didn't understand what I suggested. I suggested to do a fullrebreak on start (foreground or background) and then keep outer paragraphs sizes. Only update sizes when drawing paragraphs on-screen, and live with outdated sizes for out-of-screen outer paragraphs. I think that this may work very well. Regards, Alfredo
Re: [patch] new scrollbar code
Georg Baum [EMAIL PROTECTED] writes: Alfredo Braunstein wrote: ... Could you describe some behaviour you find weird in a few steps? Thanks. - Create a document with some paragraphs (~20, only text, one line each) - resize the main window to the smallest possible height - drag the scrollbar from top to bottom. It will not follow the cursor immediately, and if you don't drag it to the lowest possible position it will jump back to the top. It will also jump back if you drag it to the end, but will afterwards jump to the bottom. I see similar behaviour without the patch. If I drag the scrollbar down it will jump back up again. Maybe not all the way, but still annoying (tested with UserGuide). I have Qt 3.3.3 on Mac and preview on (haven't seen this mentioned in earlier posts, but it might be useful to consider this setting when comparing results). Re small documents: I made a CV recently which consisted of just a table and a picture on top. Although it was larger than the screen size I didn't get any scrollbar at all! (still without the patch) That's clearly unacceptable. Cheers /Andreas
Re: [patch] new scrollbar code
Georg Baum wrote: Alfredo Braunstein wrote: Georg Baum wrote: You mean pagedown on the keyboard, or clicking on the scrollbar background (i.e. scrollbar pgdown) I mean the key on the keyboard. Ah ok. But I think this is unrelated. Regards, Alfredo
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 02:05:38PM +0200, Alfredo Braunstein wrote: Fair enough. I suspect the real answer is full rebreaking... Always optimitic, huh? Hmm, I wonder if we could rebreak in full below a certain document size. This would fix the most apparent breakages whilst still giving us the load time boost we need for big docs (where we use the approximation). An idea? regards john
Re: [patch] new scrollbar code
John Levon wrote: Hmm, I wonder if we could rebreak in full below a certain document size. This would fix the most apparent breakages whilst still giving us the load time boost we need for big docs (where we use the approximation). An idea? Interesting... Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: I think you didn't understand what I suggested. I suggested to do a fullrebreak on start (foreground or background) and then keep outer paragraphs sizes. Only update sizes when drawing paragraphs on-screen, and live with outdated sizes for out-of-screen outer paragraphs. I think that this may work very well. I agree that this will help a lot, especially if the clipboard does not throw away the sizes of full paragraphs copied/pasted. And when the window is resized, we need a full rebreak like in the old days. Regards, Asger
Re: [patch] new scrollbar code
Andreas Vox wrote: Georg Baum [EMAIL PROTECTED] writes: - Create a document with some paragraphs (~20, only text, one line each) - resize the main window to the smallest possible height - drag the scrollbar from top to bottom. It will not follow the cursor immediately, and if you don't drag it to the lowest possible position it will jump back to the top. It will also jump back if you drag it to the end, but will afterwards jump to the bottom. I see similar behaviour without the patch. If I drag the scrollbar down it will jump back up again. Maybe not all the way, but still annoying (tested with UserGuide). I rechecked with a clean build and get indeed the same behaviour. I have Qt 3.3.3 on Mac and preview on (haven't seen this mentioned in earlier posts, but it might be useful to consider this setting when comparing results). Switching this on or off makes no difference for me. Re small documents: I made a CV recently which consisted of just a table and a picture on top. Although it was larger than the screen size I didn't get any scrollbar at all! (still without the patch) That's clearly unacceptable. This is a known problem of the current code and one of the reasons to change it. Georg
Re: [patch] new scrollbar code
John Levon wrote: > On Wed, Mar 30, 2005 at 09:01:02PM +0200, Alfredo Braunstein wrote: > >> On your document indeed the scrollbar resizes a lot (the reason is >> obvious, we have paragraphs of very different vertical size). > > OK, we need to go to Mac-style scrollbars where the widget is of a > fixed size. It's unusable otherwise IMHO. This is easy. OTOH, I'm a bit confused by your 'unusable'. Setting the widget to fixed size would make no difference in useability AFAICS. >> Still I don't find >> it's completely broken, scrolling from top to bottom is possible (even if >> 'speed' is very variable). I don't see jumps. > > I see both jumps and the document getting stuck with no progress being > made when holding down the button to continuously scroll. qt version? Please give detailed instructions. Alfredo
Re: [patch] new scrollbar code
Georg Baum wrote: > Am Mittwoch, 30. MÃrz 2005 19:51 schrieb John Levon: >> On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: >> >> > Lots of testing needed... >> >> Dragging the scrollbar on the Qt frontend is very broken (I tried with >> small document). It constantly resizes itself, jumps about. etc > > I see this, too (also qt). The fact that it resizes itself is normal (altough the resizing should be smooth). It shouldn't jump. I don't understand if both of you are seeing the same behaviour as I do and find it ugly or if you are seeing something different. Could you describe some behaviour you find weird in a few steps? Thanks. > I noticed also that there is almost always a brown area below the > document, even if the document is larger than the screen. > > Resizing the main window does not work properly: The scrollbar height is > not updated when I resize the window at the top border (see image) > resizing at the bottom works. Truly weird. Thanks for the testing. Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote:
>>> Dragging the scrollbar on the Qt frontend is very broken (I tried with
>>> small document). It constantly resizes itself, jumps about. etc
>>
>> I see this, too (also qt).
>
> The fact that it resizes itself is normal (altough the resizing should be
> smooth). It shouldn't jump. I don't understand if both of you are seeing
> the same behaviour as I do and find it ugly or if you are seeing something
> different.
>
> Could you describe some behaviour you find weird in a few steps? Thanks.
In case we are testing different things, here's an updated patch. It
suffices to uncomment the commented line in WorkArea.C:78 to test a
fixed-size widget scrollbar.
Regards, Alfredo
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.260
diff -u -p -u -r1.260 BufferView.C
--- BufferView.C 22 Feb 2005 11:41:19 - 1.260
+++ BufferView.C 31 Mar 2005 10:00:28 -
@@ -148,12 +148,6 @@ void BufferView::update(bool fitcursor,
}
-void BufferView::updateScrollbar()
-{
- pimpl_->updateScrollbar();
-}
-
-
void BufferView::scrollDocView(int value)
{
pimpl_->scrollDocView(value);
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.185
diff -u -p -u -r1.185 BufferView.h
--- BufferView.h 22 Feb 2005 11:41:19 - 1.185
+++ BufferView.h 31 Mar 2005 10:00:28 -
@@ -85,8 +85,6 @@ public:
/// move the screen to fit the cursor. Only to be called with
/// good y coordinates (after a bv::metrics)
bool fitCursor();
- /// reset the scrollbar to reflect current view position
- void updateScrollbar();
/// FIXME
bool available() const;
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.580
diff -u -p -u -r1.580 BufferView_pimpl.C
--- BufferView_pimpl.C 25 Feb 2005 11:55:29 - 1.580
+++ BufferView_pimpl.C 31 Mar 2005 10:00:29 -
@@ -100,7 +100,6 @@ using std::string;
using std::mem_fun_ref;
using std::vector;
-
extern BufferList bufferlist;
@@ -113,6 +112,10 @@ unsigned int const saved_positions_num =
// to these connections we avoid a segfault upon startup, and also at exit.
// (Lgb)
+boost::signals::connection pagedowncon;
+boost::signals::connection pageupcon;
+boost::signals::connection lineupcon;
+boost::signals::connection linedowncon;
boost::signals::connection dispatchcon;
boost::signals::connection timecon;
boost::signals::connection doccon;
@@ -152,6 +155,15 @@ BufferView::Pimpl::Pimpl(BufferView & bv
// Setup the signals
doccon = workarea().scrollDocView
.connect(boost::bind(::Pimpl::scrollDocView, this, _1));
+ pageupcon = workarea().scrollPageUp
+ .connect(boost::bind(::Pimpl::scrollPageUp, this));
+
+ pagedowncon = workarea().scrollPageDown
+ .connect(boost::bind(::Pimpl::scrollPageDown, this));
+ lineupcon = workarea().scrollLineUp
+ .connect(boost::bind(::Pimpl::scrollLineUp, this));
+ linedowncon = workarea().scrollLineDown
+ .connect(boost::bind(::Pimpl::scrollLineDown, this));
resizecon = workarea().workAreaResize
.connect(boost::bind(::Pimpl::workAreaResize, this));
dispatchcon = workarea().dispatch
@@ -365,7 +377,6 @@ void BufferView::Pimpl::setBuffer(Buffer
}
update();
- updateScrollbar();
owner_->updateMenubar();
owner_->updateToolbars();
owner_->updateLayoutChoice();
@@ -399,16 +410,15 @@ void BufferView::Pimpl::resizeCurrentBuf
// Reset the "Formatting..." message
owner_->clearMessage();
- updateScrollbar();
}
-void BufferView::Pimpl::updateScrollbar()
+void BufferView::Pimpl::updateScrollbar(ViewMetricsInfo const & vi)
{
if (!bv_->text()) {
lyxerr[Debug::DEBUG] << BOOST_CURRENT_FUNCTION
<< " no text in updateScrollbar" << endl;
- workarea().setScrollbarParams(0, 0, 0);
+ workarea().setScrollbarParams(0, 0);
return;
}
@@ -424,35 +434,71 @@ void BufferView::Pimpl::updateScrollbar(
<< " curr par: " << cursor_.bottom().pit()
<< " default height " << defaultRowHeight() << endl;
- // It would be better to fix the scrollbar to understand
- // values in [0..1] and divide everything by wh
- int const wh = workarea().workHeight() / 4;
- int const h = t.getPar(anchor_ref_).height();
- workarea().setScrollbarParams(t.paragraphs().size() * wh, anchor_ref_ * wh + int(offset_ref_ * wh / float(h)), int (wh * defaultRowHeight() / float(h)));
-// workarea().setScrollbarParams(t.paragraphs().size(), anchor_ref_, 1);
+ int const h1 = t.getPar(vi.p1).height();
+ int const h2 = t.getPar(vi.p2).height();
+ double const chop1 = (- vi.y1) / double(h1);
+ double const chop2 = (vi.y2 - workarea().workHeight()) / double(h2);
+ double const tot = t.paragraphs().size();
+ double const pos = (vi.p1 + chop1) / tot;
+ double
Re: [patch] new scrollbar code
I believe that a fixed sized scroll bar is a significant regression in terms of usability. Also, I think that a very unreliable scroll bar is a problem. The scroll bar can change a few pixels, but if it jumps much more than that, it is confusing. I did not test the new scrollbar, but if you use a uniform estimated size on all paragraphs, I think the obvious thing is to improve this by estimating the height as a function of the number of characters in the paragraph and the width available for the paragraph. You can define a function for this which calculates in constant time by using mean values for the character width and word length. To improve further, consider the insets in the paragraph by having a default size for each type and take that into account. Now, we are linear time in the number of insets, but no loading or rendering of insets are necessary to get the estimate, so it is still very fast. If this is still not accurate enough, then I'd go for better handling of the biggest elements that can appear in a document: images, tables and such. Ultimately, if such patching up does not fix the problem, we have to admit that it was a mistake, and introduce full document word breaking again. The scrollbar is one of the single most important features in a word processor. You use it all the time. You want that to be reliable and not seem strange. Regards, Asger
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 11:12:51AM +0200, Alfredo Braunstein wrote: > This is easy. OTOH, I'm a bit confused by your 'unusable'. Setting the > widget to fixed size would make no difference in useability AFAICS. Having the widget constantly change size on you is extremely disconcerting. > qt version? Please give detailed instructions. Later regards john
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 01:08:48PM +0200, Asger Alstrup wrote: > I believe that a fixed sized scroll bar is a significant regression in > terms of usability. Asger, we lost the ability to have a properly working scrollbar after the core rewrite. I'm sure there are reasons it's difficult to do this, so I am afraid we are stuck with it, and complaining will only irritate people (usually my forte) The question is how can we salvage the situation to make it as good as we can. > To improve further, consider the insets in the paragraph by having a > default size for each type and take that into account. Now, we are linear There's no such thing as a linear size for figures, so this is guaranteed to go wrong in the worst possible cases (very large figures). regards john
Re: [patch] new scrollbar code
Asger Alstrup wrote: > I believe that a fixed sized scroll bar is a significant regression in > terms of usability. I'm not sure about that. Specially since there's no difference in the scrollbar size in a mid-sized document vs a big document like UG, because most toolkits have a minimum size for the widget. > Also, I think that a very unreliable scroll bar is a problem. The scroll > bar can change a few pixels, but if it jumps much more than that, it is > confusing. It shouldn't jump at all (otherwise is just a bug). > I did not test the new scrollbar, but if you use a uniform estimated size > on all paragraphs, I think the obvious thing is to improve this by > estimating the height as a function of the number of characters in the > paragraph and the width available for the paragraph. You can define a > function for this which calculates in constant time by using mean values > for the character width and word length. Constant time per paragraph, O(number of paragraphs) total time > To improve further, consider the insets in the paragraph by having a > default size for each type and take that into account. Now, we are linear > time in the number of insets, but no loading or rendering of insets are > necessary to get the estimate, so it is still very fast. The biggest problem seems to be very high insets, like long tabulars > If this is still not accurate enough, then I'd go for better handling of > the biggest elements that can appear in a document: images, tables and > such. This could be, the question is how to do this consistently. Otherwise we will always have problems with corner cases. > Ultimately, if such patching up does not fix the problem, we have to admit > that it was a mistake, and introduce full document word breaking again. It may be, but I am afraid that we cannot afford this. > The scrollbar is one of the single most important features in a word > processor. You use it all the time. You want that to be reliable and not > seem strange. Sure, it is important. The problem is if what we have is good enough or not. An alternative you didn't mention would be to have background computation of the exact size (including full rebreak etc). Alfredo
Re: [patch] new scrollbar code
John Levon wrote:
To improve further, consider the insets in the paragraph by having a
default size for each type and take that into account. Now, we are linear
There's no such thing as a linear size for figures, so this is
guaranteed to go wrong in the worst possible cases (very large figures).
I believe it is monotoneously better to estimate all figures at say 200x200
pixels, rather than at 0x0 pixels like it does now.
The linear bit in my sentence refers to the time it takes to estimate the
height of a paragraph: The algorithm is roughly something like this:
int x = 0;
int y = average-character-height;
for (int i = 0; i != numberOfInsets-in-paragraph; ++i) {
// First estimate size of the text
x += average-character-width
* number-of-characters-in-paragraph
/ numberOfInsets-in-paragraph;
y += (x / width-available) * average-character-height;
x = x % width-available;
// Next estimate size of the insets
x += average-width-of-inset-at-position(i);
if (x > width-available) {
y += average-height;
x = x % width-available;
}
}
Notice small constant factors and linear time in number of insets. That
should be fast enough, and improve tremendously on a totally static estimate.
My point is that this estimation routine can be continuously refined until
it represents a complete rendering of the paragraph. We need to try and
find out how fine-grained the estimate has to be in order for the scroll
bar to be usable.
Regards,
Asger
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 01:54:11PM +0200, Asger Alstrup wrote: > I believe it is monotoneously better to estimate all figures at say 200x200 > pixels, rather than at 0x0 pixels like it does now. Well, perhaps, but I doubt it significantly helps. > My point is that this estimation routine can be continuously refined until > it represents a complete rendering of the paragraph. We need to try and > find out how fine-grained the estimate has to be in order for the scroll > bar to be usable. Fair enough. I suspect the real answer is full rebreaking... regards john
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: > The fact that it resizes itself is normal (altough the resizing should be > smooth). It shouldn't jump. I don't understand if both of you are seeing > the same behaviour as I do and find it ugly or if you are seeing something > different. I am actually not sure if it is all the same. > Could you describe some behaviour you find weird in a few steps? Thanks. - Create a document with some paragraphs (~20, only text, one line each) - resize the main window to the smallest possible height - drag the scrollbar from top to bottom. It will not follow the cursor immediately, and if you don't drag it to the lowest possible position it will jump back to the top. It will also jump back if you drag it to the end, but will afterwards jump to the bottom. I see also the jumping and getting stuck when pressing PgDown that John observed. BTW, this is qt 3.3.3 (stock SuSE 9.2) and yor second version of the patch. >> Resizing the main window does not work properly: The scrollbar height is >> not updated when I resize the window at the top border (see image) >> resizing at the bottom works. > > Truly weird. This happens with both qt 3.4 and 3.3.3 Georg
Re: [patch] new scrollbar code
John Levon wrote: > On Thu, Mar 31, 2005 at 01:54:11PM +0200, Asger Alstrup wrote: > >> I believe it is monotoneously better to estimate all figures at say >> 200x200 pixels, rather than at 0x0 pixels like it does now. > > Well, perhaps, but I doubt it significantly helps. > >> My point is that this estimation routine can be continuously refined >> until it represents a complete rendering of the paragraph. We need to try >> and find out how fine-grained the estimate has to be in order for the >> scroll bar to be usable. > > Fair enough. I suspect the real answer is full rebreaking... Always optimitic, huh? ;-) Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: I'm not sure about that. Specially since there's no difference in the scrollbar size in a mid-sized document vs a big document like UG, because most toolkits have a minimum size for the widget. Small documents are important too. It shouldn't jump at all (otherwise is just a bug). The size should not change more than a few pixels either. Constant time per paragraph, O(number of paragraphs) total time And can't we afford this? If so, our paragraph list traversal sucks and should be changed. The biggest problem seems to be very high insets, like long tabulars Great, then try to address those, and see what is the next problem. This is exactly the approach I'm advocating. This could be, the question is how to do this consistently. Otherwise we will always have problems with corner cases. It is still monotoneously better than ignoring the problem. Ultimately, if such patching up does not fix the problem, we have to admit that it was a mistake, and introduce full document word breaking again. It may be, but I am afraid that we cannot afford this. We used to be able to afford it, so it is affordable. It might not be feasible with the current rewritten core, but then the rewrite is not complete or a failure. An alternative you didn't mention would be to have background computation of the exact size (including full rebreak etc). This is similar to what web-browsers do as they receive the data, so that might be acceptable. But I thought the problem was that keeping the data up-to-date as the document changes is the problem? You will not avoid that can of worms with background rebreak. Regards, Asger
Re: [patch] new scrollbar code
Hi Georg, Georg Baum wrote: > Alfredo Braunstein wrote: > >> The fact that it resizes itself is normal (altough the resizing should be >> smooth). It shouldn't jump. I don't understand if both of you are seeing >> the same behaviour as I do and find it ugly or if you are seeing >> something different. > > I am actually not sure if it is all the same. It seems different indeed. >> Could you describe some behaviour you find weird in a few steps? Thanks. > > - Create a document with some paragraphs (~20, only text, one line each) > - resize the main window to the smallest possible height > - drag the scrollbar from top to bottom. It will not follow the cursor > immediately, and if you don't drag it to the lowest possible position it > will jump back to the top. It will also jump back if you drag it to the > end, but will afterwards jump to the bottom. This is very strange, I cannot reproduce. > I see also the jumping and getting stuck when pressing PgDown that John > observed. You mean pagedown on the keyboard, or clicking on the scrollbar background (i.e. scrollbar pgdown) > BTW, this is qt 3.3.3 (stock SuSE 9.2) and yor second version of the > patch. This is qt-3.3.4-0.fc3.0 on fc3. >>> Resizing the main window does not work properly: The scrollbar height is >>> not updated when I resize the window at the top border (see image) >>> resizing at the bottom works. >> >> Truly weird. > > This happens with both qt 3.4 and 3.3.3 Cannot reproduce either. Regards, Alfredo PS: in any case, your test case should be one of these in which the scheme works fine (all paragraphs are equal in vertical size). So I find this really strange.
Re: [patch] new scrollbar code
Asger Alstrup wrote: > Alfredo Braunstein wrote: >> I'm not sure about that. Specially since there's no difference in the >> scrollbar size in a mid-sized document vs a big document like UG, because >> most toolkits have a minimum size for the widget. > > Small documents are important too. Sure, I am only noting that it is a feature that only *exists* in small documents. Thus, it cannot be so fundamentally important. >> It shouldn't jump at all (otherwise is just a bug). > > The size should not change more than a few pixels either. > >> Constant time per paragraph, O(number of paragraphs) total time > > And can't we afford this? If so, our paragraph list traversal sucks and > should be changed. I wasn't saying anything about affordability, just clarifying that we need to compute the size of all paragraphs, not only onscreen ones. >> The biggest problem seems to be very high insets, like long tabulars > > Great, then try to address those, and see what is the next problem. This > is exactly the approach I'm advocating. > >> This could be, the question is how to do this consistently. >> Otherwise we will always have problems with corner cases. > > It is still monotoneously better than ignoring the problem. Hey, don be so picky. I'm very glad we are discussing this, it is certainly much better than ignoring the problem. >>>Ultimately, if such patching up does not fix the problem, we have to >>>admit that it was a mistake, and introduce full document word breaking >>>again. >> >> It may be, but I am afraid that we cannot afford this. > > We used to be able to afford it, so it is affordable. It might not be > feasible with the current rewritten core, but then the rewrite is not > complete or a failure. I was talking in terms of man-power. >> An alternative you didn't mention would be to have background computation >> of the exact size (including full rebreak etc). > > This is similar to what web-browsers do as they receive the data, so that > might be acceptable. But I thought the problem was that keeping the data > up-to-date as the document changes is the problem? You will not avoid that > can of worms with background rebreak. Well, we could just keep (maybe outdated) paragraphs sizes, and just update on-screen ones when drawing. Then the scrollbar computation would be only a loop over all outer paragraphs. Regards, Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: >>> I believe it is monotoneously better to estimate all figures at say >>> 200x200 pixels, rather than at 0x0 pixels like it does now. >> >> Well, perhaps, but I doubt it significantly helps. >> >>> My point is that this estimation routine can be continuously refined >>> until it represents a complete rendering of the paragraph. We need to >>> try and find out how fine-grained the estimate has to be in order for >>> the scroll bar to be usable. >> >> Fair enough. I suspect the real answer is full rebreaking... > > Always optimitic, huh? I haven't been following this thread very closely, but isn't the problem one of calculating the length of the document when it is first loaded? Thereafter, the scrollbar would change size only when the document was modified. (This could happen just by scrolling through a read-only document I guess as figures are loaded and therefore the graphics inset changes size.) Alfredo, would it be expensive to do a one time, accurate calculation of the document height? If so, why? Would use of the nullpainter help? -- Angus
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: Small documents are important too. Sure, I am only noting that it is a feature that only *exists* in small documents. Thus, it cannot be so fundamentally important. It serves as important feedback on the size of the document. Well, we could just keep (maybe outdated) paragraphs sizes, and just update on-screen ones when drawing. Then the scrollbar computation would be only a loop over all outer paragraphs. Since you mentioned that tables are the biggest problem, I would suggest to come up with a light-weight improved estimate for those, and see how much that helps. Then address images next. I.e. go down the path outlined in my earlier mail, except that the priorities are: - Tables - Images - Paragraph text size - Other stuff Only looking at outer paragraphs ignores the two most important ones. Regards, Asger
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: > Georg Baum wrote: > > You mean pagedown on the keyboard, or clicking on the scrollbar background > (i.e. scrollbar pgdown) I mean the key on the keyboard. Georg
Re: [patch] new scrollbar code
Angus Leeming wrote: > I haven't been following this thread very closely, but isn't the problem > one of calculating the length of the document when it is first loaded? > Thereafter, the scrollbar would change size only when the document was > modified. (This could happen just by scrolling through a read-only > document I guess as figures are loaded and therefore the graphics inset > changes size.) > > Alfredo, would it be expensive to do a one time, accurate calculation of > the document height? If so, why? Would use of the nullpainter help? It's not terribly expensive, a fullRebreak of the UG is a matter of about a second on some fast computer (1.3.x does that on loading, and there is some loading time where it just said "rebreaking document" or something). We don't need the second drawing step, as all vertical height can be computed in the metrics phase. The problem, as Asger pointed out, is to mantain this information up-to-date. Think for instance of a change in evironment-depth, that may affect several screens down of paragrahs. IMO, though, we can live with 'old data size', and only update the information when drawing on screen. I may try to implement something like that this weekend. Regards, Alfredo
Re: [patch] new scrollbar code
Asger Alstrup wrote: >> Well, we could just keep (maybe outdated) paragraphs sizes, and just >> update on-screen ones when drawing. Then the scrollbar computation would >> be only a loop over all outer paragraphs. > > Only looking at outer paragraphs ignores the two most important ones. I think you didn't understand what I suggested. I suggested to do a fullrebreak on start (foreground or background) and then keep outer paragraphs sizes. Only update sizes when drawing paragraphs on-screen, and live with outdated sizes for out-of-screen outer paragraphs. I think that this may work very well. Regards, Alfredo
Re: [patch] new scrollbar code
Georg Baum <[EMAIL PROTECTED]> writes: > > Alfredo Braunstein wrote: ... > > Could you describe some behaviour you find weird in a few steps? Thanks. > > - Create a document with some paragraphs (~20, only text, one line each) > - resize the main window to the smallest possible height > - drag the scrollbar from top to bottom. It will not follow the cursor > immediately, and if you don't drag it to the lowest possible position it > will jump back to the top. It will also jump back if you drag it to the > end, but will afterwards jump to the bottom. I see similar behaviour without the patch. If I drag the scrollbar down it will jump back up again. Maybe not all the way, but still annoying (tested with UserGuide). I have Qt 3.3.3 on Mac and preview on (haven't seen this mentioned in earlier posts, but it might be useful to consider this setting when comparing results). Re small documents: I made a CV recently which consisted of just a table and a picture on top. Although it was larger than the screen size I didn't get any scrollbar at all! (still without the patch) That's clearly unacceptable. Cheers /Andreas
Re: [patch] new scrollbar code
Georg Baum wrote: > Alfredo Braunstein wrote: > >> Georg Baum wrote: >> >> You mean pagedown on the keyboard, or clicking on the scrollbar >> background (i.e. scrollbar pgdown) > > I mean the key on the keyboard. Ah ok. But I think this is unrelated. Regards, Alfredo
Re: [patch] new scrollbar code
On Thu, Mar 31, 2005 at 02:05:38PM +0200, Alfredo Braunstein wrote: > > Fair enough. I suspect the real answer is full rebreaking... > > Always optimitic, huh? Hmm, I wonder if we could rebreak in full below a certain document size. This would fix the most apparent breakages whilst still giving us the load time boost we need for big docs (where we use the approximation). An idea? regards john
Re: [patch] new scrollbar code
John Levon wrote: > Hmm, I wonder if we could rebreak in full below a certain document size. > This would fix the most apparent breakages whilst still giving us the > load time boost we need for big docs (where we use the approximation). > An idea? Interesting... Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: I think you didn't understand what I suggested. I suggested to do a fullrebreak on start (foreground or background) and then keep outer paragraphs sizes. Only update sizes when drawing paragraphs on-screen, and live with outdated sizes for out-of-screen outer paragraphs. I think that this may work very well. I agree that this will help a lot, especially if the clipboard does not throw away the sizes of full paragraphs copied/pasted. And when the window is resized, we need a full rebreak like in the old days. Regards, Asger
Re: [patch] new scrollbar code
Andreas Vox wrote: > Georg Baum <[EMAIL PROTECTED]> writes: > >> - Create a document with some paragraphs (~20, only text, one line each) >> - resize the main window to the smallest possible height >> - drag the scrollbar from top to bottom. It will not follow the cursor >> immediately, and if you don't drag it to the lowest possible position it >> will jump back to the top. It will also jump back if you drag it to the >> end, but will afterwards jump to the bottom. > > I see similar behaviour without the patch. If I drag the scrollbar down it > will jump back up again. Maybe not all the way, but still annoying (tested > with UserGuide). I rechecked with a clean build and get indeed the same behaviour. > I have Qt 3.3.3 on Mac and preview on (haven't seen this mentioned in > earlier posts, but it might be useful to consider this setting when > comparing results). Switching this on or off makes no difference for me. > Re small documents: > > I made a CV recently which consisted of just a table and a picture on top. > Although it was larger than the screen size I didn't get any scrollbar at > all! > (still without the patch) That's clearly unacceptable. This is a known problem of the current code and one of the reasons to change it. Georg
[patch] new scrollbar code
This is a proposal for the new scrollbar code, as discussed in the list. qt
and xforms seem to work, gtk compiles (doesn't work ok but I hope should be
easy to fix)
This patch does quite a lot of things, and I'm sure is still rough around
the edges, but IMO is what needs to be done to have a decent scrollbar
again. There is a couple of things that can be commited separately (once
tested):
- there is some polishing of BufferView::Pimpl::metrics to compute stricter
top and bottom paragraphs to be drawn: this may give a small speed
improvement in update (not so much because out-of screen paragraphs are
drawn with nullpainter anyway), and also makes scrollbar computations a bit
easier.
- there is a bv::update() call replaced by update(false, true) to avoid
fitting the cursor when an image has finished loading.
Main changes are:
Simplified signature of WorkArea::setScrollBarParam, now takes two doubles
(position and height, both in [0,1]). Frontends work internally with
integer values as always.
An implementation of the WorkArea class, which is no more pure virtual. This
is to allow to introduce a couple of hooks before scrollDocView and
updateScrollbarParameters calls. In particular makes doSetScrollbarParams
to follow the NVI thing. Added 4 more signals: scroll{Page,Line}{Up,Down}.
Reworking of BufferView::Pimpl::updateScrollbar.
Lots of testing needed...
Regards, Alfredo
? frontends/WorkArea.C
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.260
diff -u -p -u -r1.260 BufferView.C
--- BufferView.C 22 Feb 2005 11:41:19 - 1.260
+++ BufferView.C 30 Mar 2005 13:56:49 -
@@ -148,12 +148,6 @@ void BufferView::update(bool fitcursor,
}
-void BufferView::updateScrollbar()
-{
- pimpl_-updateScrollbar();
-}
-
-
void BufferView::scrollDocView(int value)
{
pimpl_-scrollDocView(value);
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.185
diff -u -p -u -r1.185 BufferView.h
--- BufferView.h 22 Feb 2005 11:41:19 - 1.185
+++ BufferView.h 30 Mar 2005 13:56:49 -
@@ -85,8 +85,6 @@ public:
/// move the screen to fit the cursor. Only to be called with
/// good y coordinates (after a bv::metrics)
bool fitCursor();
- /// reset the scrollbar to reflect current view position
- void updateScrollbar();
/// FIXME
bool available() const;
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.580
diff -u -p -u -r1.580 BufferView_pimpl.C
--- BufferView_pimpl.C 25 Feb 2005 11:55:29 - 1.580
+++ BufferView_pimpl.C 30 Mar 2005 13:56:50 -
@@ -100,7 +100,6 @@ using std::string;
using std::mem_fun_ref;
using std::vector;
-
extern BufferList bufferlist;
@@ -113,6 +112,10 @@ unsigned int const saved_positions_num =
// to these connections we avoid a segfault upon startup, and also at exit.
// (Lgb)
+boost::signals::connection pagedowncon;
+boost::signals::connection pageupcon;
+boost::signals::connection lineupcon;
+boost::signals::connection linedowncon;
boost::signals::connection dispatchcon;
boost::signals::connection timecon;
boost::signals::connection doccon;
@@ -152,6 +155,15 @@ BufferView::Pimpl::Pimpl(BufferView bv
// Setup the signals
doccon = workarea().scrollDocView
.connect(boost::bind(BufferView::Pimpl::scrollDocView, this, _1));
+ pageupcon = workarea().scrollPageUp
+ .connect(boost::bind(BufferView::Pimpl::scrollPageUp, this));
+
+ pagedowncon = workarea().scrollPageDown
+ .connect(boost::bind(BufferView::Pimpl::scrollPageDown, this));
+ lineupcon = workarea().scrollLineUp
+ .connect(boost::bind(BufferView::Pimpl::scrollLineUp, this));
+ linedowncon = workarea().scrollLineDown
+ .connect(boost::bind(BufferView::Pimpl::scrollLineDown, this));
resizecon = workarea().workAreaResize
.connect(boost::bind(BufferView::Pimpl::workAreaResize, this));
dispatchcon = workarea().dispatch
@@ -365,7 +377,6 @@ void BufferView::Pimpl::setBuffer(Buffer
}
update();
- updateScrollbar();
owner_-updateMenubar();
owner_-updateToolbars();
owner_-updateLayoutChoice();
@@ -399,16 +410,15 @@ void BufferView::Pimpl::resizeCurrentBuf
// Reset the Formatting... message
owner_-clearMessage();
- updateScrollbar();
}
-void BufferView::Pimpl::updateScrollbar()
+void BufferView::Pimpl::updateScrollbar(ViewMetricsInfo const vi)
{
if (!bv_-text()) {
lyxerr[Debug::DEBUG] BOOST_CURRENT_FUNCTION
no text in updateScrollbar endl;
- workarea().setScrollbarParams(0, 0, 0);
+ workarea().setScrollbarParams(0, 0);
return;
}
@@ -424,35 +434,71 @@ void BufferView::Pimpl::updateScrollbar(
curr par: cursor_.bottom().pit()
default height defaultRowHeight() endl;
Re: [patch] new scrollbar code
Alfredo, can you please provide frontends/WorkArea.C? Otherwise I can't try the patch ;-( Georg
Re: [patch] new scrollbar code
Georg Baum wrote:
Alfredo,
can you please provide frontends/WorkArea.C? Otherwise I can't try the
patch ;-(
Ah right, sorry my bad.
Alfredo
/**
* \file WorkArea.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Alfredo Braunstein
*
* Full author contact details are available in file CREDITS.
*/
#include config.h
#include WorkArea.h
#include debug.h
using std::endl;
namespace {
static int const bignum = 100;
}
WorkArea::WorkArea() : scroll_(0), page_(0)
{}
void WorkArea::scrollDocViewInternal(int value)
{
lyxerr BOOST_CURRENT_FUNCTION endl;
int oldvalue = scroll_;
lyxerr value: value oldvalue: oldvalue page: page_;
if (value == oldvalue + 1) {
scrollLineDown();
lyxerr LINE DOWN endl;
return;
}
if (value == oldvalue - 1) {
scrollLineUp();
lyxerr LINE UP endl;
return;
}
if (value == oldvalue + page_) {
scrollPageDown();
lyxerr PAGE DOWN endl;
return;
}
if (value == oldvalue - page_) {
scrollPageUp();
lyxerr PAGE UP endl;
return;
}
scrollDocView(double(value)/bignum);
}
void WorkArea::setScrollbarParams(double height, double pos)
{
static int const bignum = 100;
page_ = int(height * bignum);
BOOST_ASSERT(height = 0);
BOOST_ASSERT(page_ = 0);
scroll_ = int(pos * bignum);
lyxerr setting scrollbar, page: page_scroll: scroll_ endl;
doSetScrollbarParams(bignum, page_, scroll_, 1);
}
Re: [patch] new scrollbar code
On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: Lots of testing needed... Dragging the scrollbar on the Qt frontend is very broken (I tried with small document). It constantly resizes itself, jumps about. etc Indeed, this happens just clicking on the scrollbar background to move a page down/up I can no longer hold the mouse on the arrows to continuously scroll a line at a time I can't really do any useful testing due to these... regards john
Re: [patch] new scrollbar code
John Levon wrote: On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: Lots of testing needed... Dragging the scrollbar on the Qt frontend is very broken (I tried with small document). It constantly resizes itself, jumps about. etc Indeed, this happens just clicking on the scrollbar background to move a page down/up I can no longer hold the mouse on the arrows to continuously scroll a line at a time I can't really do any useful testing due to these... Humm, can you send me your document? I don't see any of these here. Regards, Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: John Levon wrote: On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: Lots of testing needed... Dragging the scrollbar on the Qt frontend is very broken (I tried with small document). It constantly resizes itself, jumps about. etc On your document indeed the scrollbar resizes a lot (the reason is obvious, we have paragraphs of very different vertical size). Still I don't find it's completely broken, scrolling from top to bottom is possible (even if 'speed' is very variable). I don't see jumps. Indeed, this happens just clicking on the scrollbar background to move a page down/up Scrollbar resizing, yes. But the scrolling should be exactly one fullscreen (else it's a bug) I can no longer hold the mouse on the arrows to continuously scroll a line at a time What happends when you do so? It works here. One option is to eliminate the scrollbar size completely (i.e. make it fixed size). We don't have that many other options if the resize is disturbing. I'll have a look again tomorrow. Thanks for the testing. Alfredo
Re: [patch] new scrollbar code
Am Mittwoch, 30. März 2005 19:51 schrieb John Levon: On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: Lots of testing needed... Dragging the scrollbar on the Qt frontend is very broken (I tried with small document). It constantly resizes itself, jumps about. etc I see this, too (also qt). I noticed also that there is almost always a brown area below the document, even if the document is larger than the screen. Resizing the main window does not work properly: The scrollbar height is not updated when I resize the window at the top border (see image) resizing at the bottom works. Georg attachment: scrollbar2.png
Re: [patch] new scrollbar code
On Wed, Mar 30, 2005 at 09:01:02PM +0200, Alfredo Braunstein wrote: On your document indeed the scrollbar resizes a lot (the reason is obvious, we have paragraphs of very different vertical size). OK, we need to go to Mac-style scrollbars where the widget is of a fixed size. It's unusable otherwise IMHO. Still I don't find it's completely broken, scrolling from top to bottom is possible (even if 'speed' is very variable). I don't see jumps. I see both jumps and the document getting stuck with no progress being made when holding down the button to continuously scroll. regards john
[patch] new scrollbar code
This is a proposal for the new scrollbar code, as discussed in the list. qt
and xforms seem to work, gtk compiles (doesn't work ok but I hope should be
easy to fix)
This patch does quite a lot of things, and I'm sure is still rough around
the edges, but IMO is what needs to be done to have a decent scrollbar
again. There is a couple of things that can be commited separately (once
tested):
- there is some polishing of BufferView::Pimpl::metrics to compute stricter
top and bottom paragraphs to be drawn: this may give a small speed
improvement in update (not so much because out-of screen paragraphs are
drawn with nullpainter anyway), and also makes scrollbar computations a bit
easier.
- there is a bv::update() call replaced by update(false, true) to avoid
fitting the cursor when an image has finished loading.
Main changes are:
Simplified signature of WorkArea::setScrollBarParam, now takes two doubles
(position and height, both in [0,1]). Frontends work internally with
integer values as always.
An implementation of the WorkArea class, which is no more pure virtual. This
is to allow to introduce a couple of hooks before scrollDocView and
updateScrollbarParameters calls. In particular makes doSetScrollbarParams
to follow the NVI thing. Added 4 more signals: scroll{Page,Line}{Up,Down}.
Reworking of BufferView::Pimpl::updateScrollbar.
Lots of testing needed...
Regards, Alfredo
? frontends/WorkArea.C
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.260
diff -u -p -u -r1.260 BufferView.C
--- BufferView.C 22 Feb 2005 11:41:19 - 1.260
+++ BufferView.C 30 Mar 2005 13:56:49 -
@@ -148,12 +148,6 @@ void BufferView::update(bool fitcursor,
}
-void BufferView::updateScrollbar()
-{
- pimpl_->updateScrollbar();
-}
-
-
void BufferView::scrollDocView(int value)
{
pimpl_->scrollDocView(value);
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.185
diff -u -p -u -r1.185 BufferView.h
--- BufferView.h 22 Feb 2005 11:41:19 - 1.185
+++ BufferView.h 30 Mar 2005 13:56:49 -
@@ -85,8 +85,6 @@ public:
/// move the screen to fit the cursor. Only to be called with
/// good y coordinates (after a bv::metrics)
bool fitCursor();
- /// reset the scrollbar to reflect current view position
- void updateScrollbar();
/// FIXME
bool available() const;
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.580
diff -u -p -u -r1.580 BufferView_pimpl.C
--- BufferView_pimpl.C 25 Feb 2005 11:55:29 - 1.580
+++ BufferView_pimpl.C 30 Mar 2005 13:56:50 -
@@ -100,7 +100,6 @@ using std::string;
using std::mem_fun_ref;
using std::vector;
-
extern BufferList bufferlist;
@@ -113,6 +112,10 @@ unsigned int const saved_positions_num =
// to these connections we avoid a segfault upon startup, and also at exit.
// (Lgb)
+boost::signals::connection pagedowncon;
+boost::signals::connection pageupcon;
+boost::signals::connection lineupcon;
+boost::signals::connection linedowncon;
boost::signals::connection dispatchcon;
boost::signals::connection timecon;
boost::signals::connection doccon;
@@ -152,6 +155,15 @@ BufferView::Pimpl::Pimpl(BufferView & bv
// Setup the signals
doccon = workarea().scrollDocView
.connect(boost::bind(::Pimpl::scrollDocView, this, _1));
+ pageupcon = workarea().scrollPageUp
+ .connect(boost::bind(::Pimpl::scrollPageUp, this));
+
+ pagedowncon = workarea().scrollPageDown
+ .connect(boost::bind(::Pimpl::scrollPageDown, this));
+ lineupcon = workarea().scrollLineUp
+ .connect(boost::bind(::Pimpl::scrollLineUp, this));
+ linedowncon = workarea().scrollLineDown
+ .connect(boost::bind(::Pimpl::scrollLineDown, this));
resizecon = workarea().workAreaResize
.connect(boost::bind(::Pimpl::workAreaResize, this));
dispatchcon = workarea().dispatch
@@ -365,7 +377,6 @@ void BufferView::Pimpl::setBuffer(Buffer
}
update();
- updateScrollbar();
owner_->updateMenubar();
owner_->updateToolbars();
owner_->updateLayoutChoice();
@@ -399,16 +410,15 @@ void BufferView::Pimpl::resizeCurrentBuf
// Reset the "Formatting..." message
owner_->clearMessage();
- updateScrollbar();
}
-void BufferView::Pimpl::updateScrollbar()
+void BufferView::Pimpl::updateScrollbar(ViewMetricsInfo const & vi)
{
if (!bv_->text()) {
lyxerr[Debug::DEBUG] << BOOST_CURRENT_FUNCTION
<< " no text in updateScrollbar" << endl;
- workarea().setScrollbarParams(0, 0, 0);
+ workarea().setScrollbarParams(0, 0);
return;
}
@@ -424,35 +434,71 @@ void BufferView::Pimpl::updateScrollbar(
<< " curr par: " << cursor_.bottom().pit()
<< " default height " << defaultRowHeight() << endl;
- // It would be better to
Re: [patch] new scrollbar code
Alfredo, can you please provide frontends/WorkArea.C? Otherwise I can't try the patch ;-( Georg
Re: [patch] new scrollbar code
Georg Baum wrote:
> Alfredo,
>
> can you please provide frontends/WorkArea.C? Otherwise I can't try the
> patch ;-(
Ah right, sorry my bad.
Alfredo
/**
* \file WorkArea.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Alfredo Braunstein
*
* Full author contact details are available in file CREDITS.
*/
#include
#include "WorkArea.h"
#include "debug.h"
using std::endl;
namespace {
static int const bignum = 100;
}
WorkArea::WorkArea() : scroll_(0), page_(0)
{}
void WorkArea::scrollDocViewInternal(int value)
{
lyxerr << BOOST_CURRENT_FUNCTION << endl;
int oldvalue = scroll_;
lyxerr << "value: " << value << " oldvalue: " << oldvalue << " page: " << page_;
if (value == oldvalue + 1) {
scrollLineDown();
lyxerr << " LINE DOWN"<< endl;
return;
}
if (value == oldvalue - 1) {
scrollLineUp();
lyxerr << " LINE UP"<< endl;
return;
}
if (value == oldvalue + page_) {
scrollPageDown();
lyxerr << " PAGE DOWN" << endl;
return;
}
if (value == oldvalue - page_) {
scrollPageUp();
lyxerr << " PAGE UP" << endl;
return;
}
scrollDocView(double(value)/bignum);
}
void WorkArea::setScrollbarParams(double height, double pos)
{
static int const bignum = 100;
page_ = int(height * bignum);
BOOST_ASSERT(height >= 0);
BOOST_ASSERT(page_ >= 0);
scroll_ = int(pos * bignum);
lyxerr << "setting scrollbar, page:" << page_ << " scroll: " << scroll_ << endl;
doSetScrollbarParams(bignum, page_, scroll_, 1);
}
Re: [patch] new scrollbar code
On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: > Lots of testing needed... Dragging the scrollbar on the Qt frontend is very broken (I tried with small document). It constantly resizes itself, jumps about. etc Indeed, this happens just clicking on the scrollbar background to move a page down/up I can no longer hold the mouse on the arrows to continuously scroll a line at a time I can't really do any useful testing due to these... regards john
Re: [patch] new scrollbar code
John Levon wrote: > On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: > >> Lots of testing needed... > > Dragging the scrollbar on the Qt frontend is very broken (I tried with > small document). It constantly resizes itself, jumps about. etc > > Indeed, this happens just clicking on the scrollbar background to move a > page down/up > > I can no longer hold the mouse on the arrows to continuously scroll a > line at a time > > I can't really do any useful testing due to these... Humm, can you send me your document? I don't see any of these here. Regards, Alfredo
Re: [patch] new scrollbar code
Alfredo Braunstein wrote: > John Levon wrote: > >> On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: >> >>> Lots of testing needed... >> >> Dragging the scrollbar on the Qt frontend is very broken (I tried with >> small document). It constantly resizes itself, jumps about. etc On your document indeed the scrollbar resizes a lot (the reason is obvious, we have paragraphs of very different vertical size). Still I don't find it's completely broken, scrolling from top to bottom is possible (even if 'speed' is very variable). I don't see jumps. >> Indeed, this happens just clicking on the scrollbar background to move a >> page down/up Scrollbar resizing, yes. But the scrolling should be exactly one fullscreen (else it's a bug) >> I can no longer hold the mouse on the arrows to continuously scroll a >> line at a time What happends when you do so? It works here. One option is to eliminate the scrollbar size completely (i.e. make it fixed size). We don't have that many other options if the resize is disturbing. I'll have a look again tomorrow. Thanks for the testing. Alfredo
Re: [patch] new scrollbar code
Am Mittwoch, 30. März 2005 19:51 schrieb John Levon: > On Wed, Mar 30, 2005 at 04:28:11PM +0200, Alfredo Braunstein wrote: > > > Lots of testing needed... > > Dragging the scrollbar on the Qt frontend is very broken (I tried with > small document). It constantly resizes itself, jumps about. etc I see this, too (also qt). I noticed also that there is almost always a brown area below the document, even if the document is larger than the screen. Resizing the main window does not work properly: The scrollbar height is not updated when I resize the window at the top border (see image) resizing at the bottom works. Georg <>
Re: [patch] new scrollbar code
On Wed, Mar 30, 2005 at 09:01:02PM +0200, Alfredo Braunstein wrote: > On your document indeed the scrollbar resizes a lot (the reason is obvious, > we have paragraphs of very different vertical size). OK, we need to go to Mac-style scrollbars where the widget is of a fixed size. It's unusable otherwise IMHO. > Still I don't find > it's completely broken, scrolling from top to bottom is possible (even if > 'speed' is very variable). I don't see jumps. I see both jumps and the document getting stuck with no progress being made when holding down the button to continuously scroll. regards john
