Mudlet: перемещение скриптов и папок удаляет другие

Да, большой. Это происходит и с настоящими предметами, или просто с пустыми «Новые триггеры»?

Это действительно так. Вот как я это заметил .. 😢

Это всего лишь небольшой краткий пример для вашего сравнения.

Также я заметил другие махинации, в некоторых случаях только некоторые (но не все) перемещенные элементы снова появляются после закрытия и открытия профиля. В то время как повторного открытия редактора сценариев недостаточно.

Другая, возможно, связанная с этим последующая ошибка, которую я заметил, - это то, что копирование / вставка также сломалась в том смысле, что если я скопирую сценарий A из подпапки B / C и хочу вставить его в подпапку D / E, вместо этого он переместит целевую папку в исходную папку и вставьте туда скрипт, например B / C / D / E / A

Просматривая недавние коммиты, мало кто затрагивает эту область кода.
Ищете, где взять скомпилированные версии последних разработок для перекрестного сравнения, чтобы сузить круг вопросов.

Я git разделил его пополам на b33b6c8dc3928a6aaa2fcc6ae182e54ec89b5768. @SlySven , не могли бы вы

Могу я снова открыть это - PR / Commit, который был признан виновным, не казался возможным, чтобы быть преступником - AFAICT.

Однако, учитывая характер сбоев, я подозреваю, что это удаление первого из пары методов:

• (void) TTreeWidget::rowsAboutToBeRemoved(const QModelIndex& parent, int start, int end)
• (void) TTreeWidget::beginInsertRows(const QModelIndex& parent, int first, int last)

(Второй не содержит фактического кода и является фиктивным)

Странно то, что эти методы определены - но, похоже, не вызываются из любого места - вот почему я подумал, что их можно вырезать ...

... однако, учитывая, что Qt документирует (void) QTreeWidget::rowsAboutToBeRemoved(const QModelIndex& parent, int start, int end) как [override virtual protected] меня возникает неприятное ощущение, что меня укусила функция C ++, которая застала меня врасплох!

Ну да, повторите отправку без этих самых изменений, тогда мы сможем протестировать снова.

Может быть, добавьте сюда ссылку в качестве краткого комментария, зачем нам нужна пустая функция.

Хорошо, можем ли мы проверить, что замена заблокированного PR # 4383, то есть # 4415, НЕ отображает эту проблему / ошибку ...?

Может быть, добавьте сюда ссылку в качестве краткого комментария, зачем нам нужна пустая функция.

Обжег пальцы, я просто кладу его обратно и оставляю ...!

После слияния 4415 эта ошибка все еще не возвращалась. Ура!