|
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!
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.+ * 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).
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.+ 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).
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.
Cheers, Dave
[Prev in Thread] | Current Thread | [Next in Thread] |