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

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,

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

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

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

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

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

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).

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

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

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

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

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.

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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).

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

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

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

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

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

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.

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

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)

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

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

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

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

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

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

[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

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

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

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

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

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

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

[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

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

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

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

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.

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

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