Поймать изменение Q(tree/table/list)Widget при редактировании.

[Bepec]

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

Пример - имитируем содержимое каталога, мы переименовываем файл "1.exe" в "2.exe". После чего нам необходимо выполнить переименование на диске и сделать вид актуальным (может ошибка переименовая, мб недопустимые символы и так далее).

На данным момент закавыка в том, что я не нахожу вариантов как получить значения "1.exe" и "2.exe" в момент изменения.

Сейчас сделано так, что при начале редактирования мы получаем указатель на итем (и соответственно значение "1.exe"), а при окончании редактирования из делегата испускает сигнал с данными "2.exe". Т.к. функции делегата константные, сигнал испускается через прокси виджет.

PS оно работает, живёт и даже шевелится, но хотелось бы более изящного и менее извращённого решения, которое я мог не заметить

[Igors]

Хранить полное имя файла ну хотя бы в UserRole. Тогда все данные имеются в слоте itemChanged

[__Heaven__]

Верес, а вы не хотите попробовать перейти на Q(tree/table/list)View?
У меня таким образом много проблем исчезло. setData будет пытаться переименовать ваш файл, а data будет читать актуальный

[Bepec]

Собственно я не хочу на них переходить, ибо появляется сотня лишняя других проблем, особенно в древовидной структуре.
Я использую QTreeWidget зачастую из-за простоты.

Переход на View принесёт необходимость в создании модели.

ммм... Счас даже лучше поясню:
Мне нужна не модель, которая осуществляет изменения автоматически и показывает всю информацию (аналог View с FileModel), а модель отображающая данные, которые контролирую я.
Т.е. используя TreeWidget я отбрасываю проблемы модели и View, я просто вставляю туда итемы для отображения. Взаимодействие же происходит в коде, который не зависит от view/модели и позволяет творить абсолютно всё, не имея ограничения модели.
По сути я беру QDir + QTreeWidget и получаю тот же результат, что и View+FileModel, но имею бОльшие возможности фильтрации, контроля, виртуализации.
Чтобы добавить допустим ссылку, не имеющуюся на диске, мне необходимо всего лишь добавить итем и изменить процедуру обработки. В то время как в модели я не могу этого сделать, мне придётся написать универсальный механизм добавления ссылок, обработку их удаления/изменения/переноса,т.е. переписать все встроенные механизмы.

По сути я строю велосипеды, как выразился бы Igors. И эти велосипеды без переключения скоростей, динамо машины во втулке и прочих излишеств.

PS я с легкостью поменяю своё мнение, если вы мне откроете глаза на плюсы модели в таких простых задачах.
PPS я понимаю необходимость моделей для работы с большим количеством данных и стандартными операциями, но в простых задачах они мне кажутся излишними.

[Bepec]

Отдельный пост для благодарности Igors - проглядел я этот метод. Точнее неверно понимал его значение. Спасибо.

[__Heaven__]

На начальном этапе дерево достаточно сложно реализуется, зато потом достаточно просто расширяется.
На самом деле, большого опыта работы с виджетом не имею (да и с моделью тоже ), поэтому убедить вряд ли смогу.
Но в моей задаче оказалось выгоднее использовать модель. Например, динамическая смена языка, имхо проще.

[Bepec]

Она как раз проще для дальнейшей разработки, когда нужно поддерживать и развивать продукт. У меня несколько иная ситуация аля "приёмка" и гуляй вася.