editor/cork options wrong after deleting a text #516
Comments
worstje
added a commit
to worstje/manuskript
that referenced
this issue
May 12, 2019
Describing all the rabbitholes that I and kakaroto have gone through while debugging this one until dawn can frankly not do enough justice to the crazy amount of rubberducking that went on while trying to fix this. This bug would be triggered whenever you had a document open in the editor and then moved an ancestor object downwards (visually) in the tree. Or when you simply deleted the ancestor. Depending on the exact method that caused the opened item to be removed from the internal model, the exact nature of the bug would vary, which means this commit fixes a few different bits of code that lead to what appears to be the same bug. In order of appearance, the bugs that ruined our sleep were: 1) The editor widget was trying to handle the removed item at too late a stage. 2) The editor widget tried to fix its view after a move by searching for the new item with the same ID, but in the case of moving an object down it came across its own old item, ruining the attempt. 3) The editor widget did not properly account for the hierarchical nature of the model. Upon fixing these the next day, it was revealed that: 4) The outlineItem.updateWordCount(emit=False) flag is broken. This function would call setData() in several spots which would still cause emits to bubble through the system despite emit=False, and we simply got lucky that it stopped enough of them until now. This last one was caused by a small mistake in the fixes for the first three bugs, but it has led to a couple of extra changes to make any future bug hunts slightly less arduous and frustrating: a) When calling item.removeChild(c), it now resets the associated parent and model to mirror item.insertChild(c). This has also led to an extra check in model.parent() to check for its validity. b) The outlineItem.updateWordCount(emit=) flag has been removed entirely and it now emits away with reckless abandon. I have been unable to reproduce the crashes the code warned about, so I consider this a code quality fix to prevent mysterious future issues where things sometimes do not properly update right. Worthy of note is that the original code clearly showed the intention to close tabs for items that were removed. Reworking the editor to support closing a tab is unfortunately way out of scope, so this intention was left in and the new fix was structured to make it trivial to implement such a change when the time comes. An existing FIXME regarding unrelated buggy editor behaviour was left in, too. Many thanks to Kakaroto for burning the midnight oil with me to get to the bottom of this. (I learned a lot that night!) Issues olivierkes#479 and olivierkes#559 are fixed by this commit. And maybe some others, too. Changes according to code review It also adds a bugfix for non-updating tab titles in the editor. Fix for issue olivierkes#516 + extra safety checks. A modified safety check has been added back in for the signals where these could protect against a buggy situation. Technically speaking, olivierkes#516 is out of scope... but it is a trivial fix, so why not? :-)
worstje
added a commit
to worstje/manuskript
that referenced
this issue
May 18, 2019
Describing all the rabbitholes that I and kakaroto have gone through while debugging this one until dawn can frankly not do enough justice to the crazy amount of rubberducking that went on while trying to fix this. This bug would be triggered whenever you had a document open in the editor and then moved an ancestor object downwards (visually) in the tree. Or when you simply deleted the ancestor. Depending on the exact method that caused the opened item to be removed from the internal model, the exact nature of the bug would vary, which means this commit fixes a few different bits of code that lead to what appears to be the same bug. In order of appearance, the bugs that ruined our sleep were: 1) The editor widget was trying to handle the removed item at too late a stage. 2) The editor widget tried to fix its view after a move by searching for the new item with the same ID, but in the case of moving an object down it came across its own old item, ruining the attempt. 3) The editor widget did not properly account for the hierarchical nature of the model. Upon fixing these the next day, it was revealed that: 4) The outlineItem.updateWordCount(emit=False) flag is broken. This function would call setData() in several spots which would still cause emits to bubble through the system despite emit=False, and we simply got lucky that it stopped enough of them until now. This last one was caused by a small mistake in the fixes for the first three bugs, but it has led to a couple of extra changes to make any future bug hunts slightly less arduous and frustrating: a) When calling item.removeChild(c), it now resets the associated parent and model to mirror item.insertChild(c). This has also led to an extra check in model.parent() to check for its validity. b) The outlineItem.updateWordCount(emit=) flag has been removed entirely and it now emits away with reckless abandon. I have been unable to reproduce the crashes the code warned about, so I consider this a code quality fix to prevent mysterious future issues where things sometimes do not properly update right. Worthy of note is that the original code clearly showed the intention to close tabs for items that were removed. Reworking the editor to support closing a tab is unfortunately way out of scope, so this intention was left in and the new fix was structured to make it trivial to implement such a change when the time comes. An existing FIXME regarding unrelated buggy editor behaviour was left in, too. Many thanks to Kakaroto for burning the midnight oil with me to get to the bottom of this. (I learned a lot that night!) Issues olivierkes#479, olivierkes#516 and olivierkes#559 are fixed by this commit. And maybe some others, too.
gedakc
pushed a commit
that referenced
this issue
May 19, 2019
Describing all the rabbitholes that I and kakaroto have gone through while debugging this one until dawn can frankly not do enough justice to the crazy amount of rubberducking that went on while trying to fix this. This bug would be triggered whenever you had a document open in the editor and then moved an ancestor object downwards (visually) in the tree. Or when you simply deleted the ancestor. Depending on the exact method that caused the opened item to be removed from the internal model, the exact nature of the bug would vary, which means this commit fixes a few different bits of code that lead to what appears to be the same bug. In order of appearance, the bugs that ruined our sleep were: 1) The editor widget was trying to handle the removed item at too late a stage. 2) The editor widget tried to fix its view after a move by searching for the new item with the same ID, but in the case of moving an object down it came across its own old item, ruining the attempt. 3) The editor widget did not properly account for the hierarchical nature of the model. Upon fixing these the next day, it was revealed that: 4) The outlineItem.updateWordCount(emit=False) flag is broken. This function would call setData() in several spots which would still cause emits to bubble through the system despite emit=False, and we simply got lucky that it stopped enough of them until now. This last one was caused by a small mistake in the fixes for the first three bugs, but it has led to a couple of extra changes to make any future bug hunts slightly less arduous and frustrating: a) When calling item.removeChild(c), it now resets the associated parent and model to mirror item.insertChild(c). This has also led to an extra check in model.parent() to check for its validity. b) The outlineItem.updateWordCount(emit=) flag has been removed entirely and it now emits away with reckless abandon. I have been unable to reproduce the crashes the code warned about, so I consider this a code quality fix to prevent mysterious future issues where things sometimes do not properly update right. Worthy of note is that the original code clearly showed the intention to close tabs for items that were removed. Reworking the editor to support closing a tab is unfortunately way out of scope, so this intention was left in and the new fix was structured to make it trivial to implement such a change when the time comes. An existing FIXME regarding unrelated buggy editor behaviour was left in, too. Many thanks to Kakaroto for burning the midnight oil with me to get to the bottom of this. (I learned a lot that night!) Issues #479, #516 and #559 are fixed by this commit. And maybe some others, too.
|
This issue has been resolved in the develop branch and will be included in the next release of Manuskript. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Minor bug:
To reproduce, select a text scene in the editor, and click the '-' button to remove it. The main editor window will switch to its parent (the folder) but the editor options beneath it don't change, so we can't switch from text/corkview/outline modes, and we have the option to go fullscreen on the folder even though we shouldn't.
The text was updated successfully, but these errors were encountered: