gnustep-dev
[Top][All Lists]
Advanced

[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: 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:

+  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

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






reply via email to

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