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
14 matches
Mail list logo
