Le 24/08/2013 19:24, Hashini Senaratne a écrit :
But once we know that the row has to be slid, we could maybe draw it a
first time (it is possible to draw without actually drawing) to get
positions, and then do it a second time. Or we need to find what is the
place where this update happens.
I
Hello Jean-Marc,
> I think I know why this happens: have a look at this comment taken from
> coordCache.h:
>
> /**
> * A BufferView dependent cache that allows us to come from an inset in
> * a document to a position point and dimension on the screen.
> * The individual points are added a
Dear Hashini,
I did see several copies of your answer. Unfortunately, I am not able to do
much more than read the messages on myvphone. It is difficult to me to give
useful advice without the source code and a proper keyboard...
Tommaso, can ypu help ?
JMarc
Hashini Senaratne a écrit :
>Hel
On 08/05/2013 08:38 AM, Hashini Senaratne wrote:
Hello Jean-Marc,
I continue my backwards visit of history.
Although I posted some replies to mailing list last week, they do not seems
to appear to the outside yet. So I am re-sending those replies.
They did arrive here. It's just that JMarc i
On 08/01/2013 02:00 PM, Hashini Senaratne wrote:
Hello Jean-Marc,
+++ b/src/Cursor.cpp
-278,7 +278,7 CursorData::CursorData(DocIterator
const & dit)
// bv functions are not yet available!
Cursor::Cursor(BufferView & bv)
: CursorData(&bv.buffer()), bv_(&bv),
-
On 08/01/2013 01:15 PM, Hashini Senaratne wrote:
+ BufferView & bv = cur.bv();
+
You are defining bv, whereas you already have bv_, which is a BufferView
const *. Advice: always check whether a variable is needed before
defining it.
However in this case the situation is different
Hello Jean-Marc,
> +++ b/src/Cursor.cpp
> -278,7 +278,7 CursorData::CursorData(DocIterator
const & dit)
> // bv functions are not yet available!
> Cursor::Cursor(BufferView & bv)
> : CursorData(&bv.buffer()), bv_(&bv),
> - x_target_(-1), textTargetOffset_(0)
> +
Hello Jean-Marc,
> > I continue my backwards visit of history.
Although I posted some replies to mailing list last week, they do not seems
to appear to the outside yet. So I am re-sending those replies.
I carefully followed your reviews and modified the code accordingly. Your
comments on them we
Hello Jean-Marc,
> +++ b/src/Cursor.cpp
> -278,7 +278,7 CursorData::CursorData(DocIterator
const & dit)
> // bv functions are not yet available!
> Cursor::Cursor(BufferView & bv)
> : CursorData(&bv.buffer()), bv_(&bv),
> - x_target_(-1), textTargetOffset_(0)
> +
Hello Jean-Marc,
> > I continue my backwards visit of history.
I carefully followed your reviews and modified the code accordingly. Your
comments on them were really useful.
> I forgot a couple of remarks in this commit.
>
> - RowPainter rp(pi, *text_, pit, row, bidi, x, y);
> +
Hello Jean-Marc,
> > I continue my backwards visit of history.
I carefully followed your reviews and modified the code accordingly. Your
comments on them were really useful.
> I forgot a couple of remarks in this commit.
>
> - RowPainter rp(pi, *text_, pit, row, bidi, x, y);
> +
26/07/2013 10:54, Jean-Marc Lasgouttes:
I continue my backwards visit of history.
I forgot a couple of remarks in this commit.
- RowPainter rp(pi, *text_, pit, row, bidi, x, y);
+
+ cur.setTargetX();
Do you really need to set targetX? This seems plain wrong to me
As a preamble, the most important remark is that you should never
declare methods and members in a commit and implement them in anothe
rone. Each commit should be self contained and leave the trunk
compilable. The idea is not to commit file-by-file, but
function-by-function.
JMarc
+++ b/src/
I continue the review. Coding style point: please leave two empty lines
between method definitions.
JMarc
+++ b/src/Cursor.cpp
@@ -278,7 +278,7 @@ CursorData::CursorData(DocIterator const & dit)
// bv functions are not yet available!
Cursor::Cursor(BufferView & bv)
: CursorData(&bv.bu
I continue my backwards visit of history.
JMarc
+++ b/src/TextMetrics.cpp
@@ -16,7 +16,6 @@
*/
#include
-
#include "TextMetrics.h"
There is no reason to delete a line here. You should always before
pushing a commit look at the diff and spot this kind of unintented changes.
#include
Hi Hashinni,
I thought I would review your commits to gsoc/master, in reverse order.
I start from 78364e430.
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -627,6 +627,17 @@ void GuiWorkArea::Private::showCursor()
&& !completer_->inlineVisible();
cursor_visible_ = true;
25/07/2013 18:07, Jean-Marc Lasgouttes:
But once we know that the row has to be slid, we could maybe draw it a
first time (it is possible to draw without actually drawing) to get
positions, and then do it a second time. Or we need to find what is the
place where this update happens.
Have a look
25/07/2013 18:07, Jean-Marc Lasgouttes:
I think I know why this happens: have a look at this comment taken from
coordCache.h:
/**
* A BufferView dependent cache that allows us to come from an inset in
* a document to a position point and dimension on the screen.
* All points cached in this
22/07/2013 15:10, Hashini Senaratne:
Even the difference is 3pix it gives totally a wrong scroll, even we can't
see the text cursor position.
Hello,
I think I know why this happens: have a look at this comment taken from
coordCache.h:
/**
* A BufferView dependent cache that allows us to co
Hello Jean-Marc,
> > When the row slid to a wrong position (say when entering from right corner
> > leftedge is set to 10 pix unexpectedly); if I move the mouse pointer in to
> > and out of the document window; without any key pressing position resets to
> > the current position. So we only need t
22/07/2013 13:04, Hashini Senaratne:
I think what you are telling 'weird' is; then the cursor is at the left or
right edge and we are still moving beyond the screen; the text cursor is not
stable (I noticed that the given attachment of yours).
Is this a correct patch for it?
Yes, it is fine now
22/07/2013 11:53, Hashini Senaratne:
When I test further, figured out that the cur_x only gives the correct
position in pixels just after entering a Math inset; from the next row. That
is the next row consider in the for loop in drawParagraph() method. The line
responsible for updating this bv.ge
Hello Jean-Marc,
> I see it too, it is very strange. However, I think the problem is
> different, because it does not require to go out of the equation. You do
> not see it because (strangely) your test case contains a math equation
> in a Title layout[1] and thus with large character. Now take
Hello Jean-Marc,
> I tried to fix this and found that this happens because cur_x variable do
> mot get updates as expected. I save bv.getPos(cur).x_ to cur_x, as I
> discussed with you earlier. But my previous observation seems to be wrong
> when compared to cur.targetX(). I tried with cur.targetX
21/07/2013 21:50, Hashini Senaratne:
I tried to fix this and found that this happens because cur_x variable do
mot get updates as expected. I save bv.getPos(cur).x_ to cur_x, as I
discussed with you earlier. But my previous observation seems to be wrong
when compared to cur.targetX(). I tried wit
Jean-Marc Lasgouttes lyx.org> writes:
> This works very well! A small nit: when cursor goes to rith right at the
> end of the visible row, it goes backwards and the forwards. The &0px
> correction should maybe be applied also to the cursor position when not
> at the real end of the row.
I tri
Le 17/07/13 06:09, Hashini Senaratne a écrit :
Tried to update the text cursor position accordingly:
http://git.lyx.org/?p=gsoc.git;a=commitdiff;h=f2614dabfa0b93519ea6e30985d632f2bea871e3
This works very well! A small nit: when cursor goes to rith right at the
end of the visible row, it goes b
Hello Jean-Marc, Lasgouttes lyx.org> writes:
> >> What do you mean by "cursor positions"?
> >
> > The position where the text-cursor seems to be appear. I have to edit it as
> > the next step.
>
> OK.
>
Tried to update the text cursor position accordingly:
http://git.lyx.org/?p=gsoc.git;a=com
15/07/2013 19:22, Hashini Senaratne:
Hello Jean-Marc,
What do you mean by "cursor positions"?
The position where the text-cursor seems to be appear. I have to edit it as
the next step.
OK.
Besides, is it intentionnlly that you skipped the use of
(set|get)ToowideRow?
What I thought about
Hello Jean-Marc,
>What do you mean by "cursor positions"?
The position where the text-cursor seems to be appear. I have to edit it as
the next step.
>Something very weird: when moving in the long formula, the
>"Math-Formula" title moves, whereas it should not. I tried to debug
>this, but do no
15/07/2013 00:20, Jean-Marc Lasgouttes:
Something very weird: when moving in the long formula, the
"Math-Formula" title moves, whereas it should not. I tried to debug
this, but do not understand yet why it happens...
OK, after spending a lot of time staring at the code, I founf out that
there
Le 12/07/13 22:00, Hashini Senaratne a écrit :
The important thing is to know what is the row that you have decided to
slide. This is why you have defined (set|get)ToowideRow, isn't it? Why
don't you use these methods?
Thank you. I implemented the basic sliding functionality in order to slide a
Hi Jean-Marc,
> The important thing is to know what is the row that you have decided to
> slide. This is why you have defined (set|get)ToowideRow, isn't it? Why
> don't you use these methods?
Thank you. I implemented the basic sliding functionality in order to slide a
single row, according to
12/07/2013 09:03, Hashini Senaratne:
Hi Jean-Marc
I hope you found your way out of this problem. Otherwise tomorrow I will
comment on your patch and give advice.
I think I found the pr
oblem. That is because in the for loop I am updatingthe left edge all the
time. I will try to correct it
Hi Jean-Marc
> I hope you found your way out of this problem. Otherwise tomorrow I will
comment on your patch and give advice.
> I think I found the pr
> oblem. That is because in the for loop I am updatingthe left edge all the
time. I will try to correct it.
Although I found the reason, I am s
Hi Hashini,
I hope you found your way out of this problem. Otherwise tomorrow I will
comment on your patch and give advice.
JMarc
Hashini Senaratne a écrit :
>Hello Jean-Marc,
>
>> But at the moment I am stuck at a point. In my last comment, I wrote
>a
>> general algorithm. According to that
Hello Jean-Marc,
> But at the moment I am stuck at a point. In my last comment, I wrote a
> general algorithm. According to that all the rows should slide. But what I
> am getting is, sliding of a non relevant row.
>
http://git.lyx.org/?p=gsoc.git;a=commitdiff;h=18447e084037ef29b37f8bc938dc84f1a8
Hello Jean-Marc,
> I am not sure what you have in mind, but I think that you should not
> worry about that. The right place for setting the row offset (or
> whatever name you give to it) is when the screen is about to get drawn
> (BufferView::draw). It is not necessary to track all the places
01/07/2013 18:49, Hashini Senaratne:
When a LyX document opens, the cursor appears at the point where it was when
the document was closed after the final edition. How this is handled (from
where)? Is it something involved with BufferView.cpp?
I am not sure what you have in mind, but I think tha
Hi Hashini,
On Mon, Jul 1, 2013 at 12:49 PM, Hashini Senaratne wrote:
> When a LyX document opens, the cursor appears at the point where it was when
> the document was closed after the final edition. How this is handled (from
> where)? Is it something involved with BufferView.cpp?
I don't know
Hello Jean-Marc,
> I am not sure we undertand each other: in my mind, this "offset" is
> indeed the amount of horizontal pixel by which the row has been slid.
> That is, instead of drawing the part of the row that goes from 0 to
> window_width, LyX will draw the part between offset and
> offse
29/06/2013 13:40, Hashini Senaratne:
I think this not-suitability cannot decide only with this offset attribute.
As proceeds I figured out that only using the offset value, it is impossible
to give a correct output in scrolling. That is, without knowing the amount
that we already slid, we cannot
01/07/2013 01:23, Cyrille Artho:
Japanese (and probably Korean and several other languages) have no space
either, so the text is always broken at the end of the line, regardless
of word boundaries.
Therefore I think this functionality is essential. Please add it back.
Yes, this is something I
I think that I can stop worrying about that because there is no
scrolling for text sections.
Note that on somewhat unrelated rewrite of the metrics/display code I am
trying to do, I removed the "functionality" that splits a word larger
than the screen. While this probably does not happen in p
Jean-Marc Lasgouttes wrote:
> I finally managed to checkout your testing repository and give it a try.
> Here are a few remarks on where I think we should be going.
Any objection to putting this intro directly into cursor.h? P
> --*--
>
> First some explanation about what a Cursor really is. I
Hello Jean-Marc,
> This is why I proposed that the row (or the cursor) remembers the
> current offset and only changes it if is is not suitable. See one of my
> previous mails.
I think this not-suitability cannot decide only with this offset attribute.
As proceeds I figured out that only using
26/06/2013 20:14, Hashini Senaratne:
As this also did not work for me I did not try the following.
Following two are the most recent commits I have done and you can also see
the output after the final commit.
http://git.lyx.org/?p=gsoc.git;a=commitdiff;h=b673a5b0a650d19383ec836c693e72af3c432d71
Hello Jean-Marc,
> There is a mechanism to avoid drawing rows when they are unchanged. Look
> for this code in drawParagrph:
>
> // Row signature; has row changed since last paint?
> row.setCrc(pm.computeRowSignature(row, bparams));
> bool row_has_change
Le 26/06/2013 16:09, Hashini Senaratne a écrit :
Jean-Marc Lasgouttes lyx.org> writes:
OK, what about using TexMetrics::cursorX() or maybe
BufferView::getPos()? The later is what is called by setTargetX.
Nothing that work. I think the reason is when the cursor moves along a row
as a result o
Jean-Marc Lasgouttes lyx.org> writes:
> OK, what about using TexMetrics::cursorX() or maybe
> BufferView::getPos()? The later is what is called by setTargetX.
Nothing that work. I think the reason is when the cursor moves along a row
as a result of key board presses of arrow keys, drawparagraph
Le 26/06/2013 14:13, Hashini Senaratne a écrit :
I think I figured out some clue. When the cursor is in a Math inset and when
I move the cursor using "ARROW KEYS", no change happens. But when I use the
"MOUSE" for select a different position in the same row, the value targetX()
gets change. What
Hello Jean-Marc,
> > You can use setTargetX() to force a recomputation. Does this work?
> >
>
> Sorry that did not work.
>
> I am using this within drawparagraph() of TextMetrics. As setTargetX() is
> not a const method, I cannot call it as cur.setTargetX(). So I defined
> another non- cnstant
Hello Jean-Marc,
>
> Le 26/06/2013 08:45, Hashini Senaratne a écrit :
> > Hello Jean-Marc,
> >
> >> * A Cursor is a descendant of CursorData that contains interesting
> >> display-related information, in particular targetX(), the horizontal
> >> position of the cursor in pixels.
> >
> > I checked
Le 26/06/2013 08:45, Hashini Senaratne a écrit :
Hello Jean-Marc,
* A Cursor is a descendant of CursorData that contains interesting
display-related information, in particular targetX(), the horizontal
position of the cursor in pixels.
I checked targetX() and it only gets changed when the cur
Hello Jean-Marc,
> * A Cursor is a descendant of CursorData that contains interesting
> display-related information, in particular targetX(), the horizontal
> position of the cursor in pixels.
I checked targetX() and it only gets changed when the cursor is moving along
a Math equation.
To ment
Hello Jean-Marc,
> Does this look like a plan? Please do not hesitate to ask me if some
> parts are not clear.
You have explained me a lot of things that I do not know properly. Thank you
and I will ask questions while I proceed. I am sure that I will have a lot
of questions.
Thank you
Hashini
23/06/2013 10:36, Hashini Senaratne:
Hello Jean-Marc
I suspect this is not going to work when you want to set cursor by mouse on
a slided row. I think the offset information shall be in bufferview as Richard
said.
I tried it already; but still having some problems. Will continue on working
a
Hello Jean-Marc,
> I read on the wiki page that you had issue pushing some code. On what
> branch are you working? I cannot find your code. Being able to run your
> code would help me to see what are your problems and try to help.
I am pushing on the branch called scroll/testing. You can view t
Hello Jean-Marc
>
> I suspect this is not going to work when you want to set cursor by mouse on
a slided row. I think the offset information shall be in bufferview as Richard
said.
I tried it already; but still having some problems. Will continue on working
and report back when I come to a st
Le 21/06/13 19:28, Hashini Senaratne a écrit :
Thank you for this information; Jean-Marc Lasgouttes & Richard
Yes, only the visible cursor point is not at the correct place. I can delete
or add characters to where I expect.
Is this blink code is in Cursor.cpp or somewhere related to graphics? I
I suspect this is not going to work when you want to set cursor by mouse on a
slided row. I think the offset information shall be in bufferview as Richard
said.
JMarc
Hashini Senaratne a écrit :
>Thank you for this information; Jean-Marc Lasgouttes & Richard
>
>> > Yes, only the visible curs
Hello Richard,
> I think this is in the GuiWorkArea::Private::showCursor() routine. The
> place to put the cursor gets calculated there, and then passed to
> another showCursor(...) routine. That information is retrieved, however,
> from BufferView::cursorPosAndHeight(), so the thing to do mig
Thank you for this information; Jean-Marc Lasgouttes & Richard
> > Yes, only the visible cursor point is not at the correct place. I can delete
> > or add characters to where I expect.
> > Is this blink code is in Cursor.cpp or somewhere related to graphics? I
> > tried to find it but failed.
> >
Hello Jean-Mark , Pavel & Scott
Yes, I will try to document the areas where I will go through.
Thank you
Hashini
On Wed, Jun 19, 2013 at 10:52 PM, Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
>> [Side note: if during your research you find some function with a
>> lacking/wrong documentation, fel free to submit a patch to improve it.]
>
> Hashini, improving our lacking documentation of source code by what
Jean-Marc Lasgouttes wrote:
> [Side note: if during your research you find some function with a
> lacking/wrong documentation, fel free to submit a patch to improve it.]
Hashini, improving our lacking documentation of source code by whatsover
you learn through threads like this would be real gai
On 06/19/2013 09:33 AM, Hashini Senaratne wrote:
The code that draws the cursor does not know that you have moved the
row, so I aimgaine it will be wrong. What I would do maybe is to add a
x_offset (or something) variable to the Cursor object that indicates
that the row is sliding. Then the curso
19/06/2013 15:33, Hashini Senaratne:
The code that draws the cursor does not know that you have moved the
row, so I aimgaine it will be wrong. What I would do maybe is to add a
x_offset (or something) variable to the Cursor object that indicates
that the row is sliding. Then the cursor-blink code
> The code that draws the cursor does not know that you have moved the
> row, so I aimgaine it will be wrong. What I would do maybe is to add a
> x_offset (or something) variable to the Cursor object that indicates
> that the row is sliding. Then the cursor-blink code could take this in
> accou
19/06/2013 15:11, Hashini Senaratne:
Above problem was able to solve with the use of cur.targetX() and
bv.workWidth() as follows. Now the whole page slides as expected if we move
the cursor along a too wide Math inset. But the cursor gets disappear after
passing the right edge of the screen.
I tr
Hello Jean-Marc,
> I tested what you have given and that helped me to understand more. Today I
> did more testing and realized that cur.pos() is not related with pixels and
> this approach cannot be used as a generic solution.
>
> Problems:
> *I checked the cur.pos() values inside a tabular inse
19/06/2013 13:07, Hashini Senaratne:
I tested what you have given and that helped me to understand more. Today I
did more testing and realized that cur.pos() is not related with pixels and
this approach cannot be used as a generic solution.
Cur.pos() counts the characters. For example cur.pos()
Hello Jean-Marc,
> You have to check that you are in the correct paragraph. pos is the
> position in the paragraph. The index of the paragraph is "pit" (the same
> that is passed to RowPainter constructor). Thus the test should be
>
> if (cur.pos() >0 && cur.pit() == pit)
>
> This will however
Le 17/06/2013 19:12, Hashini Senaratne a écrit :
Hello All,
When I replace the line;
RowPainter rp(pi, *text_, pit, row, bidi, x, y);
in TextMetrics.cpp with following few lines:
int inc_x=x;
if(cur.pos()>0)
inc_x-=100;
RowPainter rp(pi, *text_, pit, row, bidi, inc_x, y);
Is it because that
74 matches
Mail list logo
