30/09/2013 20:55, Hashini Senaratne:
I tried this but it seems like not working properly. Now the content that we
are adding or deleting are not visible, while adding and deleting to/from a
already wide cell.
I will try more testing. As it is not visible most of the time it is hard to
notice the
Hello Jean-Marc,
> Hello Hashini,
>
> I think the problem is just SingleParUpdate vs FullScreenUpdate. Try the
> attached patch.
Really sorry for the late reply.
I tried this but it seems like not working properly. Now the content that we
are adding or deleting are not visible, while adding and
Le 21/09/2013 09:52, Hashini Senaratne a écrit :
Next I will try to focus on the problems having with table inset.
*When moving inside a table and adding and deleting text at a scrolled
state, the text cursor is not overlapping with the actual typing position.
According to my testing so far, i
22/09/2013 10:50, Hashini Senaratne:
As I see, void InsetTabular::cursorPos is the place where modify the cursor
position within tables. By disabling resetPos(...) what we do is keep scx_
at 0 and do not update the cursor x position using scx_. If we disable
resetPos(...) and try adding text to a
> Try using "git blame src/insets/InsetTabular.cpp" to know at what commit
each line of code has been added/modified. Google can tell you how to play
detective with that command
> I am surprised though. What is the problem ?
Thanks. I will try with that.
As I see, void InsetTabular::cursorPos i
Try using "git blame src/insets/InsetTabular.cpp" to know at what commit each
line of code has been added/modified. Google can tell you how to play detective
with that command
I am surprised though. What is the problem ?
JMarc
Hashini Senaratne a écrit :
>Hello Jean-Marc,
>
>> Your commit l
Hello Jean-Marc,
> Your commit log is pretty good. See a few comments below.
Thank you for reviewing it.
Is there a way to get the full patch for half-back solution for
insetTabular? I tried fing in the Bug Tracker, but could not. It seems like
disabling resetPos(...) and scx_x is not completely
.
JMarc
[Feature] Key board based horizontal scrolling for math insets
This feature also applicable for other insets; graphics and labels.
So why not just write that the feature is about horizontal scrolling of
wide insets?
Although the initial implementation was started with scrolling the
Dear Jean-Marc,
> Here is as promised a patch concerning vertical scrolling. If it works
> correctly, please remoce Cursor::bottomRow, which is not needed anymore.
>
> What the patch does is to test whether a row exists before reading it.
> This avoid strange changes in rows that in turn confu
deleting
merges that I have done so far. It would be very helpful, even if you can
quickly go through it. (also can find at:
https://dl.dropboxusercontent.com/u/105510128/Log-master)
[Feature] Key board based horizontal scrolling for math insets
This feature also applicable for other insets; gr
19/09/2013 08:49, Hashini Senaratne:
I was trying to figure out what has happened with vertical scrolling. This
problem has remained for a long time as I can see. The first point this
introduced was when using,
if (&cur.textRow() == &row)
What happens is what is doing inside cur.textRow() affects
Le 19/09/2013 08:49, Hashini Senaratne a écrit :
I was trying to figure out what has happened with vertical scrolling. This
problem has remained for a long time as I can see. The first point this
introduced was when using,
if (&cur.textRow() == &row)
What happens is what is doing inside cur.textR
Le 19/09/2013 12:31, Hashini Senaratne a écrit :
In this commit:
http://git.lyx.org/?p=gsoc.git;a=commitdiff;h=72ae4610ffabf6b8c974b3af3b8d19c39de9e6c6
I tried to resolve the differences compared to origin/master. Now the
statistics are as follows.
This looks very good now.
Then I hope to dea
Hello Jean-Marc,
> Yes, resetting all the changes that are there for now.
In this commit:
http://git.lyx.org/?p=gsoc.git;a=commitdiff;h=72ae4610ffabf6b8c974b3af3b8d19c39de9e6c6
I tried to resolve the differences compared to origin/master. Now the
statistics are as follows.
BufferView.cpp
Le 19/09/2013 08:49, Hashini Senaratne a écrit :
Hello Jean-Marc,
- create a nice and tidy scroll/master repo with a few commits, or maybe
one for where we are now and one for removing insettabulat special code
once you got it right in testing.
Did you mean deleting current scroll/master and
Hello Jean-Marc,
> - create a nice and tidy scroll/master repo with a few commits, or maybe
> one for where we are now and one for removing insettabulat special code
> once you got it right in testing.
Did you mean deleting current scroll/master and recreate one?
> I prefer the later option. T
16/09/2013 20:31, Hashini Senaratne:
Will we be able to show the same repository under, gsoc/scroll/master? Or I
can create a repository in my GitHub account.
What I would do is remove what is currently in gsoc/scroll/master, and
replace it with the new code. Two ways of doing it
- import al
Hello Jean-Marc,
> Is it still the case with my latest patch?
I checked and it seems not. So, I think I have to remove my temporal patch
and rearrange the code according to your suggested patch in the other
message. I will try testing with that.
> We also have to think about how to prepare this
Hello Jean-Marc,
> Have a look at the updated patch below that implements the new way of
> identifying rows. It seems to work in my limited testing.
I think this solves the problem. I will do more testing tomorrow.
A little weird thing happened. When I go down in the document and coming
back to
15/09/2013 21:44, Hashini Senaratne:
This problem also applicable for tables. And wired things happen in tables
when editing.
* When delete some text within a cell using (backspace or delete key) above
problem appears. Also, it seems like more columns are creating. But it is
actually not. When c
15/09/2013 19:32, Hashini Senaratne:
I do not know how to get a CursorSlice that points the start character of a
row. So I tried with the following, within the Cursor.cpp.
Have a look at the updated patch below that implements the new way of
identifying rows. It seems to work in my limited tes
Hello Jean-Marc,
> I checked the current implementation with too wide tables by commenting the
> content in void InsetTabular::resetPos(Cursor & cur) const. It seems to work
> with tables, but the proper behaviour seems to appearing with fullpaint
updates.
I think I am incorrect at the above ment
Hello Jean-Marc,
> What may happen is that DecorationUpdate redraw is triggerred when
> moving the mouse. In this case, the rows would be recretated and change
> value.
>
> A way to avoid that would be to remember the position of the start of
> the row (a cursor slice pointing at the first cha
Le 15/09/13 08:11, Hashini Senaratne a écrit :
Thank you. I tried this. Even it solves above mentioned problem (unwanted
sliding when moving from the rightmost position of the math inset to the
below row, using right arrow), again it is not working for the mouse pointer
selections within the row.
Hi Scott,
> I know nothing about this. Can you send an email to lyx-devel and
> Vincent asking these questions? I would be interested to find out the
> answer as well.
Ok,
I too followed this
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg180430.html. But
could not find the correct proce
Hello Jean-Marc,
> Thank you. I tried this. Even it solves above mentioned problem (unwanted
> sliding when moving from the rightmost position of the math inset to the
> below row, using right arrow), again it is not working for the mouse pointer
> selections within the row. However it is good to
On Sun, Sep 15, 2013 at 1:58 AM, Hashini Senaratne wrote:
>> This might not be relevant, but have you tested with a right-to-left
>> language? "moving away" might mean the opposite there.
>
> I have not check. But I think moving away from a row is independent from the
> language. I did not get yo
Hello Jean-Marc,
>
> Le 12/09/13 08:53, Hashini Senaratne a écrit :
> > I tried with removing this. If you also try that, you will see that the it
> > will introduce an abnormal behaviour when moving from the rightmost position
> > of the math inset to the below row, using right arrow. The observ
Hi Scott,
> This might not be relevant, but have you tested with a right-to-left
> language? "moving away" might mean the opposite there.
I have not check. But I think moving away from a row is independent from the
language. I did not get your point.
> This would be great. I'm very interested
Le 12/09/13 08:53, Hashini Senaratne a écrit :
I tried with removing this. If you also try that, you will see that the it
will introduce an abnormal behaviour when moving from the rightmost position
of the math inset to the below row, using right arrow. The observation is
word "Graphics" get scro
Hi Hashini,
> Yes, this happens because of the early return. But if we remove that we are
> with the problem, that I mentioned above. What I see is, we need to paint
> the too wide rows when we are moving away from them. For example, if we are
> moving from the right most position of a too wide ro
Le 12/09/2013 08:53, Hashini Senaratne a écrit :
Yes, this happens because of the early return. But if we remove that we are
with the problem, that I mentioned above. What I see is, we need to paint
the too wide rows when we are moving away from them.
I may have an idea for this. I will try to
Hello Jean-Marc,
> I think this behavior (of Cursor::bottomRow) is fixed in the attached
> commit. I also reverted some of the workarounds that you introduced.
> Please test and commit if it is satisfying.
I test this patch and committed to the repository. Moreover I deleted the
setLeftEdge(0)
Dear Hashini,
As you probably saw, I just answered to your previous message and sent a
patch.
11/09/2013 14:54, Hashini Senaratne:
But after the last commit I think now I can use, left_edge != >
cur.getLeftEdge() too. Although, to me this boolean is more clear. Yes, I
will follow the term you
11/09/2013 11:43, Hashini Senaratne:
As &row do not give the expected row address in checkCursorLeftEdge() method
in BufferView when selecting certain positions in Math inset using the mouse
pointer, above first two bugs caused. Here the row is defined as,
Row const & row = cur.bottomRow();
At th
Hello Jean-Marc,
> 1/ In checkCursorLeftEdge, you introduce a new bool row_need_slide that
> in my mind is equivalent to the old test "left_edge !=
> cur.getLeftEdge()", since the goal is to know whether the row needs to
> be repainted. Does the new form make a difference?
>
> I am OK with the
11/09/2013 11:43, Hashini Senaratne:
Hello Jean-Marc,
Now it seems like most of the bugs are fixed with keyboard based solution.
*Selecting a different position in an already slid row
*Selecting a range of text in an already slid row
*Behaviour related to Home and End keys
Above features seems
Hello Jean-Marc,
Now it seems like most of the bugs are fixed with keyboard based solution.
*Selecting a different position in an already slid row
*Selecting a range of text in an already slid row
*Behaviour related to Home and End keys
Above features seems to work well in this commit:
http://gi
38 matches
Mail list logo
