Hi Tim,
Tim Hardeck wrote (14-01-12 18:21)
I have created a patch to address fdo#44173.
Zooming does now base on a geometric progression instead of an
arithmetic one. Since the zoom factor is not only used in Draw but
for all other applications 1.2 seems like a good choice but the value
could
Hi Tim, Cor,
On 16 January 2012 12:35, Cor Nouws oo...@nouenoff.nl wrote:
I am looking at the factor 1.2
That means that when zoom is 100, the next will be 120.
The sequence (if round in Calc does the same as in C++) would look like:
131721263341516480100120144173207249299358430516619743892
Hi Cor,
thanks for your input. 1.1 is Ok but the scrolling effort needed would be
doubled. Since the mouse wheel is pretty fast it should be still fine though.
The problem is that if you start from a manual set zooming level or the full
page zoom like for example 66% the values are different
Hi Stefan,
thanks for your ideas. Like I have written in my previous mail I have
implemented something similar, at least above 50%.
Before that I think little steps are fine but this is just my opinion.
Besides 100% it really does make sense to also check for the complete page
width and
Hi Tim,
Tim Hardeck wrote (16-01-12 21:38)
The problem is that if you start from a manual set zooming level or
the full page zoom like for example 66% the values are different then
the one you calculated.
I know - it was just an example.
So I have created some stimple functions which round
Hi,
while I tested different scrolling values I realized that the scrolling
target/center could be really annoying especially in Writer because it always
tends to zoom in the upper left corner instead of at least the center.
So I think it would make sense to use mouse centered scrolling
