Thanks for the clarification.
El dom, 14 jul 2024 a la(s) 9:37 a.m., T Rex (sixpa...@gmail.com) escribió:
> The issue for me is irregular behavior regarding the "clip to coordinates"
> option.
> What I expect from "clip to coordinates" when it is active is that the
Am Sonntag, dem 14.07.2024 um 09:37 -0500 schrieb T Rex:
> The issue for me is irregular behavior regarding the "clip to
> coordinates" option.
> What I expect from "clip to coordinates" when it is active is that
> the action is performed, if not, the image is
The issue for me is irregular behavior regarding the "clip to coordinates"
option.
What I expect from "clip to coordinates" when it is active is that the
action is performed, if not, the image is restored to its original state. What
I have seen when the option is inactive
Am Samstag, dem 13.07.2024 um 09:58 -0500 schrieb T Rex:
> I don't know if I'm misinterpreting how the "Clip to coordinates"
> option works, but it seems that even if it's not selected, the
> clipping is still being done.
I don't see that. The coo
I don't know if I'm misinterpreting how the "Clip to coordinates" option
works, but it seems that even if it's not selected, the clipping is still
being done.
lyx-clip.7z
Description: application/7z-compressed
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
htt
Kornelia Pietsch wrote:
> This is a rebuild of the 'big' coordinate patch against
> current CVS.
This makes it a lot less crashy.
void LyXText::setCursorFromCoordinates(LCursor & cur, int const x, int const
y)
- for (; r < int(par.rows().size()); ++r) {
+ for (; r < int(par.rows().s
Lars Gullik BjÃnnes wrote:
> Kornelia Pietsch
> <[EMAIL PROTECTED]>
> writes:
>
> | This is a rebuild of the 'big' coordinate patch against
> | current CVS.
>
> Alfredo, I hope you will have the time to take a peek on this.
I'm having a look. I'll get back soon with details of my defeat ;-)
Al
Kornelia Pietsch wrote:
> This is a rebuild of the 'big' coordinate patch against
> current CVS.
Thanks
> I am somehow getting the feeling this might be 1.5
> business, though. Not sure...
Ok, I'll try a bit and see if I can do something.
Alfredo
Kornelia Pietsch <[EMAIL PROTECTED]> writes:
| This is a rebuild of the 'big' coordinate patch against
| current CVS.
Alfredo, I hope you will have the time to take a peek on this.
| I am somehow getting the feeling this might be 1.5
| business, though. Not sure...
The question is also how easy
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
24 matches
Mail list logo
