|
From: | David Ayers |
Subject: | Re: [Fwd: Re: set of text scrolling patches (pageUp:/pageDown:) (+ Bonus ProjectCenter Patch :) )] |
Date: | Sat, 12 Oct 2002 12:35:45 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 |
David Ayers wrote:
David Ayers wrote:Nicola Pero wrote: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+ 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 fontsunder the normal scaling (you probably thought you'd never get a font smaller than 1 in points/pixels).After another quick chat with Alexander, I'm not so sure anymore that 1.0 is such a good value. You probably need some allgorithm, which loop through all line fragments and determinst the best fit. And also take into account vertical line fragments, that would result in selection the next/prev glyph in the same fragement. But all this needs a new NSLayoutManager and some of it's subclasses and goes far beyond what I can currently suggest in patch.As a compromise maybe a step = MIN (0.01, [oldGlyphBounds height]/10); would solve it until then.
OK, after a good night's sleep, and some pondering on the discussions, I must agree that this is a hack. I guess the correct approach for moveUp: is to create a rect that has a width of 0.0, starts at the 'x', 'y' position of the 1 (depending on NSSelectionAffinity maybe last) glyph of the selection and goes up. From all intersecting line fragements, one would choose the closest (i.e. smallest 'y' difference) that's different from the current line fragment and position the selection in that fragement with the cached 'x' value.
To be even more exect, one should first search the current line fragment to find an intersecting glyph which differs from the current selection. The would handle sweep up/down layout also. I'm not sure how a mixed sweep layout should handle move*: messages. Should the selection stay in the same sweep direction, or should the visual postion take precidence?
The next problem would arise when no gylph or rect could be found. How could you figure out the sweep direction to change the selection in the charachter range?
When I get back to implementing on the gui, I'll try to implement the first suggestion for moveUp/Down and assume a NSLineSweepRight and NSLineMovesDown for now. Maybe Alex can figure out later how different sweep line move directions can be handled. If you (or someone else) wants to take a shot at implementing it, feel free because I don't know when I'll get to it. But please let me know, because eventually I will try.
Cheers, Dave
[Prev in Thread] | Current Thread | [Next in Thread] |