[Libreoffice-ux-advise] [PATCH] use a geometric progression for zooming

[Tim Hardeck]

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 then the one you calculated.

So I have created some stimple functions which round against a multiple.
I thought that below 50 isn't rounded because the steps should be small. After 50 it is rounded against the multiple of 5. After 100 against 10, 500 against 50 and 1000 against 100. This creates nice values and still bases on a geometric progression.
To have one fix point I have added a check to make sure that when going above or below 100, it is always used as one step, independent of the prior distance. This should normalize all steps afterwards.

The multiple values might be adjusted a little bit if we use 1.1 but it would be still fine I suppose. Starting with 50 it would be 55, 60, 65, 70, 75, 85, 95, (100) and so on.

So what do you think?

Regards
Tim


On Monday 16 January 2012 12:35:06 Cor Nouws wrote:
> 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 be easily changed in one place.
> 
> Thanks - useful idea :-)
> 
> 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:
> 13>17>21>26>33>41>51>64>80>100>120>144>173>207>249>299>358>430>516>619>743>892 
> 
> 
> IMO that leaps are too large, so I would advise 1.1 at most
> ( at the slider currently + / -  is 5%)
> 
> Factor 1.1 will give the sequence
> 39>43>48>53>59>66>73>81>90>100>110>121>133>146>161>177>195>214>236>259>285>314
> 
> However, it results in numbers that might look weird to users ?
> Maybe a different algorithm / simply table giving steps is better for that?
> Hmm, how would that show for CTL languages?
> 
> > The change does not only influence mouse zooming but also the plus
> > minus slider buttons.
> >
> > The patch should be already committed so you can test it with a
> > current git version.
> 
> (I did not test it yet, just imagined how it would behave)
> 
> Cheers,
> 
> 

-- 
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
T: +49 (0) 911 74053-0  F: +49 (0) 911 74053-483
http://www.suse.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/libreoffice-ux-advise/attachments/20120116/a8276b31/attachment.pgp>