[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: Re: set of text scrolling patches (pageUp:/pageDown:) (+ Bonus
Re: [Fwd: Re: set of text scrolling patches (pageUp:/pageDown:) (+ Bonus ProjectCenter Patch :) )]
Sat, 12 Oct 2002 12:35:45 +0200
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
under 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
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.