-
Michael Pyne authored
This mitigates a potential data-loss situation that might happen when adding new music items: Juk starts processing the new items in addFiles, Results in a new CollectionListItem being created, The resultant PlaylistItem superclass calls setFlags, This causes Qt to send a *data* changed signal from the QTreeWidget holding all the playlist items, saying that a *different* QTreeWidgetItem / PlaylistItem has been changed. This signal is normally only possible because of user interaction with the inline editor. As a result JuK assumes the signal is a user request to edit the track's tag, and does so. I have seen this cause existing files to take on the same tag values as one of the incoming new tracks. Although in theory a user could immediately select the "Undo" command to fix this, that's not a very good workaround. Since we have a separate tag editor already, we'll just use that instead until we can figure out a way to ensure that dataChanged signals are sent only when the data itself has changed (not just flags caused by unrelated items being created). CHANGELOG: Prevent opening new items from inadvertently editing track metadata on existing items. FIXED-IN:18.12.1
c6afa4c5