I'm way above my pay grade here but I'll spam the list anyway ...
I removed the update() call in MatrixScene::handleEventRemove() in
[e85854] and confirmed it (mysteriously) fixed the problem. Then I
restored it, and ran with:
(gdb) dprintf QGraphicsScene::update, "QGraphicsScene::update\n"
(gdb) dprintf MatrixScene::handleEventRemoved,
"MatrixScene::handleEventRemoved\n"
(gdb) dprintf BasicCommand::execute, "BasicCommand::execute\n"
(gdb) dprintf BasicCommand::unexecute, "BasicCommand::unexecute\n"
I created ("painted") four notes, each time getting:
BasicCommand::execute
MatrixScene::handleEventRemoved
QGraphicsScene::update
QGraphicsScene::update
I have no idea where the second update is coming from. The
handleEventRemoved when creating an event is part of the command
architecture that I understand and am highly critical of, but that's a
story for another day.
Undoing the four notes one at a time once again shows no difference
between using the button vs CTRL+Z. But again*2 there's inexplicable
behavior. Undoing the first and third notes gives:
BasicCommand::unexecute
MatrixScene::handleEventRemoved
QGraphicsScene::update
QGraphicsScene::update
The second one:
BasicCommand::unexecute
MatrixScene::handleEventRemoved
QGraphicsScene::update
QGraphicsScene::update
MatrixScene::handleEventRemoved
QGraphicsScene::update
QGraphicsScene::update
And the fourth, which works if CTRL+Z but not with the button, is:
BasicCommand::unexecute
MatrixScene::handleEventRemoved
QGraphicsScene::update
QGraphicsScene::update
MatrixScene::handleEventRemoved
QGraphicsScene::update
QGraphicsScene::update
MatrixScene::handleEventRemoved
QGraphicsScene::update
QGraphicsScene::update
MatrixScene::handleEventRemoved
QGraphicsScene::update
QGraphicsScene::update
OK, so likely none of the above is helpful. Apologies for the waste of
time. "Do we go with this for 22.06?" Maybe this is the only mystery in
RG for you guys, but from my vantage point the code is full of black
magic that just somehow works (and there are many comment sections in
the code that seem to agree). So why not another one? It probably not
any worse than the current situation, and if it crashes some obscure
workflow there's always a ".1" emergency update.
In the long term I think there needs to be a concerted effort to clean
up all the "just somehow works" code, including the many redundant calls
to methods that just repeat the same modifications to the model that the
first one did. "Doesn't hurt" is IMO a latent bug waiting to happen. I'm
trying to do some of it incrementally in my merge requests but probably
won't volunteer globally/proactively.
On 6/4/22 8:08 AM, Ted Felix wrote:
I think I fixed it. But it makes little sense. So I'm not sure.
Read on...
First, I confirmed that Philip's change works. Doing a full update()
for the pointer position appeared to fix this. So that got me thinking
about update()...
MatrixScene::handleEventRemoved() calls QGraphicsScene::update(). I
would expect that to handle this. I even added an invalidate() for fun,
no difference.
So then I tried something crazy. Just to make sure that update()
call in MatrixScene::handleEventRemoved() was doing something, I removed
it.
And now it works fine. Even tested deleting in Notation to make sure
the note goes away on Matrix. Works fine.
Theories? Do we go with this for 22.06?
Ted.
On 6/3/22 4:42 PM, Philip Leishman wrote:
I have been experimenting a bit here.
I can only reproduce the error if the pointer position is within the
segment.
with the pointer position at the start of the composition try a segment
starting at bar 2. I do not get the error.
Move the pointer to bar 3 and create a segment from bar 2 to bar 4. Now
I get the error.
Looking into Panned.cpp:
There are 2 showPositionPointer routines. One is used by the notation
editor and one by the matrix editor.
The Notation editor version uses viewport()->update(). The matrix editor
version calls viewport()->update(newRect).
If I change to the viewport()->update() call the bug seems to
disappear !!!!
Don't ask me to explain this but maybe someone can confirm this behavior.
Philip
On 6/2/22 20:38, Ted Felix wrote:
On 6/2/22 1:06 PM, mark_at_yahoo via Rosegarden-devel wrote:
I'm looking forward to seeing the fix. :)
Yeah. This is a strange one. So everyone sees it no matter what
version of Qt. I'm guessing it was introduced when we added the
toolbar undo history dropdown. 21.06 doesn't seem to have the
problem. Haven't actually bisected to see if that's really it, though.
Don't have a lot of hope for fixing this for 22.06. Ah well. I'll
see if I can come up with something clever given that it is likely to
affect anyone who uses the toolbar.
Ted.
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to
unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to
unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
