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'
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 yo
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.
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
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
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
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 t
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
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
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
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) parag
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
>>
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,
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 diff
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
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
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 i
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
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).
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
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 th
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 vers
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 us
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 s
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 resize
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
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 ot
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
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. et
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 clic
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 t
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 Alf
Alfredo,
can you please provide frontends/WorkArea.C? Otherwise I can't try the
patch ;-(
Georg
33 matches
Mail list logo
