Discussion:
painting bug?
Scott Kostyshak
2014-07-28 17:19:08 UTC
Permalink
In the attached document, if I put the cursor inside the text
"handout:0" and type, it writes over the next inset (same thing if I
type after deleting all the text to begin with). Are we missing a
repaint? I can reproduce this with both Qt4 and Qt5, on Ubuntu 14.04.

Here is a screencast:
https://www.dropbox.com/s/a6g3jkmpuzfgs66/screencast-LQ-wide.ogv

Scott
Scott Kostyshak
2014-07-28 17:22:15 UTC
Permalink
Post by Scott Kostyshak
In the attached document, if I put the cursor inside the text
"handout:0" and type, it writes over the next inset (same thing if I
type after deleting all the text to begin with). Are we missing a
repaint? I can reproduce this with both Qt4 and Qt5, on Ubuntu 14.04.
https://www.dropbox.com/s/a6g3jkmpuzfgs66/screencast-LQ-wide.ogv
Scott
I got the attached SIGSEGV when playing around with the MWE (deleting
and undoing). I can't reproduce it and I don't know if it's related,
but I attach it just in case.

Scott
Jean-Marc Lasgouttes
2014-07-29 08:38:37 UTC
Permalink
Post by Scott Kostyshak
I got the attached SIGSEGV when playing around with the MWE (deleting
and undoing). I can't reproduce it and I don't know if it's related,
but I attach it just in case.
Don't you love these stl template backtraces? Making sense of them is a
horrible task. Note however that it is possible to install a gdb
pretty-printer that improve things:
http://askubuntu.com/questions/403143/setting-up-gdb-pretty-printing-in-ubuntu-13-10

Nevertheless, if you manage to reproduce the bug, I will take a look at
it. As it is, it is difficult to make up my mind.

Note that this could be related to the original bug.

JMarc
Scott Kostyshak
2014-07-29 13:20:12 UTC
Permalink
On Tue, Jul 29, 2014 at 4:38 AM, Jean-Marc Lasgouttes
Post by Jean-Marc Lasgouttes
Post by Scott Kostyshak
I got the attached SIGSEGV when playing around with the MWE (deleting
and undoing). I can't reproduce it and I don't know if it's related,
but I attach it just in case.
Don't you love these stl template backtraces? Making sense of them is a
horrible task. Note however that it is possible to install a gdb
http://askubuntu.com/questions/403143/setting-up-gdb-pretty-printing-in-ubuntu-13-10
I had never heard of that. I´ll check it out.
Post by Jean-Marc Lasgouttes
Nevertheless, if you manage to reproduce the bug, I will take a look at it.
As it is, it is difficult to make up my mind.
Note that this could be related to the original bug.
OK.

Scott
Jean-Marc Lasgouttes
2014-07-29 13:57:22 UTC
Permalink
Post by Scott Kostyshak
Post by Jean-Marc Lasgouttes
Don't you love these stl template backtraces? Making sense of them is a
horrible task. Note however that it is possible to install a gdb
http://askubuntu.com/questions/403143/setting-up-gdb-pretty-printing-in-ubuntu-13-10
I had never heard of that. I´ll check it out.
It is nice actually. You can also do it by hand (see in the gdb
documentation).

It looks like one can install boost prettyprinters too. I do not know if
they are packaged with the dbg versions of boost too.

JMarc
Scott Kostyshak
2014-07-28 18:00:55 UTC
Permalink
Post by Scott Kostyshak
In the attached document, if I put the cursor inside the text
"handout:0" and type, it writes over the next inset (same thing if I
type after deleting all the text to begin with). Are we missing a
repaint? I can reproduce this with both Qt4 and Qt5, on Ubuntu 14.04.
https://www.dropbox.com/s/a6g3jkmpuzfgs66/screencast-LQ-wide.ogv
I do not see this bug at 1fefbf5b.

Scott
Jean-Marc Lasgouttes
2014-07-28 21:38:17 UTC
Permalink
Post by Scott Kostyshak
In the attached document, if I put the cursor inside the text
"handout:0" and type, it writes over the next inset (same thing if I
type after deleting all the text to begin with). Are we missing a
repaint? I can reproduce this with both Qt4 and Qt5, on Ubuntu 14.04.
This one stymies me. I do not know what could have changed to cause that
such a bahavior. It looks like the problem is that the SingleParUpdate
code does not really notice that the rows need to be recomputed.

Please create a ticket assigned to me.

JMarc

PS: I did fix a problem with this bug, where clicking at the end of the
row would not set the cursor at the right place. The cursor is really
misplaced here, whereas the previous problem was a display problem.
Scott Kostyshak
2014-07-29 01:32:15 UTC
Permalink
On Mon, Jul 28, 2014 at 5:38 PM, Jean-Marc Lasgouttes
Post by Jean-Marc Lasgouttes
Post by Scott Kostyshak
In the attached document, if I put the cursor inside the text
"handout:0" and type, it writes over the next inset (same thing if I
type after deleting all the text to begin with). Are we missing a
repaint? I can reproduce this with both Qt4 and Qt5, on Ubuntu 14.04.
This one stymies me. I do not know what could have changed to cause that
such a bahavior. It looks like the problem is that the SingleParUpdate code
does not really notice that the rows need to be recomputed.
Are you able to reproduce it?
If it would help, I can do a git bisect.
Post by Jean-Marc Lasgouttes
Please create a ticket assigned to me.
Done at http://www.lyx.org/trac/ticket/9224.

Scott
Jean-Marc Lasgouttes
2014-07-29 08:01:46 UTC
Permalink
Post by Scott Kostyshak
Are you able to reproduce it?
If it would help, I can do a git bisect.
Yes I can. This is the most depressing part ;)

JMarc
Scott Kostyshak
2014-07-29 08:11:11 UTC
Permalink
On Tue, Jul 29, 2014 at 4:01 AM, Jean-Marc Lasgouttes
Post by Jean-Marc Lasgouttes
Post by Scott Kostyshak
Are you able to reproduce it?
If it would help, I can do a git bisect.
Yes I can. This is the most depressing part ;)
OK. I can still bisect if that would help.

Scott
Jean-Marc Lasgouttes
2014-07-29 08:21:07 UTC
Permalink
Post by Scott Kostyshak
Post by Jean-Marc Lasgouttes
Yes I can. This is the most depressing part ;)
OK. I can still bisect if that would help.
I have a theory, I will test it first. Bisecting is still quite time
consuming.

JMarc
Scott Kostyshak
2014-07-29 08:24:45 UTC
Permalink
On Tue, Jul 29, 2014 at 4:21 AM, Jean-Marc Lasgouttes
Post by Jean-Marc Lasgouttes
Post by Scott Kostyshak
Post by Jean-Marc Lasgouttes
Yes I can. This is the most depressing part ;)
OK. I can still bisect if that would help.
I have a theory, I will test it first. Bisecting is still quite time
consuming.
OK, let me know if your theory is rejected.

Scott
Jean-Marc Lasgouttes
2014-07-29 09:07:24 UTC
Permalink
Post by Scott Kostyshak
Post by Jean-Marc Lasgouttes
I have a theory, I will test it first. Bisecting is still quite time
consuming.
OK, let me know if your theory is rejected.
Well, my theory is indeed proven false. If you have time to bsect, it
will be appreciated. No hurry though, I will probably not have time
until September.

JMarc
Scott Kostyshak
2014-07-29 13:30:39 UTC
Permalink
On Tue, Jul 29, 2014 at 5:07 AM, Jean-Marc Lasgouttes
Post by Scott Kostyshak
Post by Jean-Marc Lasgouttes
I have a theory, I will test it first. Bisecting is still quite time
consuming.
OK, let me know if your theory is rejected.
Well, my theory is indeed proven false. If you have time to bsect, it will
be appreciated. No hurry though, I will probably not have time until
September.
Bisect lead me to e1c4cb71 but I´m not sure because on some of the
"good commits" the line breaking did not work correctly, which I think
is important to reproducing the bug. So in summary, I'm not confident
that e1c4cb71 is the *first* bad commit (because I'm not confident
when marking "good" commits), but I am confident it is "bad" in the
sense that I can reproduce the bug.

Scott
Jean-Marc Lasgouttes
2014-07-29 13:57:55 UTC
Permalink
Post by Scott Kostyshak
Bisect lead me to e1c4cb71 but I´m not sure because on some of the
"good commits" the line breaking did not work correctly, which I think
is important to reproducing the bug. So in summary, I'm not confident
that e1c4cb71 is the *first* bad commit (because I'm not confident
when marking "good" commits), but I am confident it is "bad" in the
sense that I can reproduce the bug.
Thanks., I have a look later.

JMarc

Loading...