On Thu, Mar 06, 2003 at 12:12:16PM +0100, Alfredo Braunstein wrote:
> > Yep ok. Please embed those three vars in a little struct though, so its
> > obvious they are entirely related.
>
> Sorry, yes to what? I've proposed two options. (and the one I like best is
> not implemented yet and has only
John Levon wrote:
> Yep ok. Please embed those three vars in a little struct though, so its
> obvious they are entirely related.
Sorry, yes to what? I've proposed two options. (and the one I like best is
not implemented yet and has only two vars: top_row_ and top_row_offset_).
Alfredo
On Thu, Mar 06, 2003 at 12:01:42PM +0100, Alfredo Braunstein wrote:
> If you ask why a row would be added or deleted before the top_y() position,
> think about rebreaking of previous paragraphs because of image size
> changing (it indeed happends often with previews), or latex error boxes
> gettin
John Levon wrote:
> On Thu, Mar 06, 2003 at 11:39:10AM +0100, Alfredo Braunstein wrote:
>
>> What about keeping an up-to-date int top_row_, that is we increment
>> top_row if we add a row before, decrement it if we delete a row before?
>
> Under what circumstances do we do anything before top_y(
John Levon wrote:
> On Thu, Mar 06, 2003 at 11:39:10AM +0100, Alfredo Braunstein wrote:
>
>> What about keeping an up-to-date int top_row_, that is we increment
>> top_row if we add a row before, decrement it if we delete a row before?
>
> Under what circumstances do we do anything before top_y(
On Thu, Mar 06, 2003 at 11:39:10AM +0100, Alfredo Braunstein wrote:
> What about keeping an up-to-date int top_row_, that is we increment top_row
> if we add a row before, decrement it if we delete a row before?
Under what circumstances do we do anything before top_y() ??
regards,
john
John Levon wrote:
> Hopefully one day we will have a simple cursor class that is an iterator
> on a document, and another class that has one of those and a pixel
> offset (for passing mouse clicks around or something). But that's some
> way off I suppose.
I don't know really. Each time I make my
On Wed, Mar 05, 2003 at 09:44:30PM +0100, Alfredo Braunstein wrote:
> I'm not convinced about using a row as a reference position. Keeping a row
> number is wrong (it can change with rebreaking in previous rows).
> Keeping instead a row pointer (as I do now) is broken, because the row can
> disap
Alfredo Braunstein wrote:
> The fact that I use rows for fixing the reference is is not crucial (in
> fact, it is somewhat broken: if a previous row gets eliminated because of
> rebreaking, we will see a one-row jump on screen. Maybe the right solution
^^
John Levon wrote:
>
> Does this mean first_y_ will be a pixel offset from this row ? If so,
> it needs renaming. If not, why not ?
It's not (it's an absolute pixel value from the start), but it could
perfectly be (with the renaming you suggest below).
I'm not convinced about using a row as a
On Wed, Mar 05, 2003 at 04:36:30PM +0100, Alfredo Braunstein wrote:
> * rename LyXText::first_y to first_y_ and make it private.
> * add a first_y() const method that returns first_y with some adjustment
> * add a set_first_y(int newy) method
>
> Putting set_first_y(int newy) to assign first_y_ =
Angus Leeming wrote:
>> * rename LyXText::first_y to first_y_ and make it private.
>> * add a first_y() const method that returns first_y with some adjustment
>> * add a set_first_y(int newy) method
>
> Why not call them first_row() and set_first_row(int newrow). It might help
> future generation
Angus Leeming <[EMAIL PROTECTED]> writes:
| Alfredo Braunstein wrote:
|
| > In a document full of previews, the size of the document changes when
| > mathed insets get replaced by preview snippets. This makes very
| > unconfortable to input (or even follow) text when the changes are being
| > mad
Alfredo Braunstein wrote:
> In a document full of previews, the size of the document changes when
> mathed insets get replaced by preview snippets. This makes very
> unconfortable to input (or even follow) text when the changes are being
> made. The problem is not exclusive to previews, but also t
In a document full of previews, the size of the document changes when mathed
insets get replaced by preview snippets. This makes very unconfortable to
input (or even follow) text when the changes are being made. The problem is
not exclusive to previews, but also to other things that could change si
15 matches
Mail list logo
