[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Re: set of text scrolling patches (pageUp:/pageDown:) (+ Bonus

From: David Ayers
Subject: Re: [Fwd: Re: set of text scrolling patches (pageUp:/pageDown:) (+ Bonus ProjectCenter Patch :) )]
Date: Fri, 11 Oct 2002 10:00:57 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910

Nicola Pero wrote:

Thanks David, I applied most of it - definitely the pageUp/pageDown, and
the fix for the font panel key equivalent.  Thanks!  Very good stuff. :-)

Thanks a lot!

+   * Take verticalPageScroll into accout, but try to make sure
+   * that amount is never negativ (ie do not scroll backwards.)
+   * FIXME: Maybe we sould send messages instead of accessing
+   * ivars for verticakPageScroll as subclasses may override it,
+   * but for now be consistent with the rest of the code.

If you want to change the verticalPageScroll, you call
setVerticalPageScroll:.  There is no need to subclass it. :-)

If a subclass wants to change the vertical scroll, it can call
setVerticalPageScroll: as well (in -initWithFrame: I suppose).

So I don't see any advantage in sending a message to itself to access its
own ivar in this case ... in practice it would just be a useless slow-down
- the API already gives you all the flexibility you need.

There might definitely be cases in which sending a message to itself to
access an ivar might be a very good idea for more powerful subclassing etc
- but in this case in practical terms it's just a waste of resources
(which, I think, is why we access all those variables directly).

Fine, not religious about it, since this *is* free software, if anyone *really* needs it they can see it and state thier case or change it as they need it.

+  iPoint.y = NSMinY(oldGlyphBounds) - 1;

This is precisely where I was not really convinced.  It's sort of a
philosophical question :-) ... why 1 ?  why not 2 or 0.3 or 1000 ?

I know it's because in practical terms, 1 works well with the normal fonts
under the normal scaling (you probably thought you'd never get a font
smaller than 1 in points/pixels).

Yes you're right, I momentarily wondered what value I wanted. First I thought of takeing half the size of the current line fragment, but that upper line fragment couln have a very different size. Then I thought of going down/up the text storage (or glyph) chain) until the line fragment changes, but then I would need to to know in which direction the line sweeps. And this is when I reallised that implementing the hardly documented NSLineSweepDirection and NSLineMovesDirction handling would be much more fundamental, than worrying about fonts with less than 1.0 points. :-) As this NSLine*Direction is niether handled by my patch or the current imlpementation, I didn't give the "search delta" much though anymore.

For practical reasons I would just leave the 1.0 and add a "FIXME: when we have NSLine*Direction handling and then we can search up/down the charchter/glyph chain to get the size/position of the prev/next line fragment/gyph. Because in certain cases (ie: NSLineSweepUp/Down) we would have to select the prev/next glyph instead of the prev/next line fragement.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]