Предполагается, что QUndoCommands связаны с видом или моделью?

Question

В среде отмены Qt вы можете иметь стек QUndoCommand экземпляров.Каждый из них описывает действие в пользовательском интерфейсе.В нашем приложении у нас есть набор представлений, работающих с набором моделей, некоторые из которых являются комбинациями, и у нас часто есть несколько представлений, работающих с одним и тем же набором моделей.Сейчас я смотрю на возможность отмены действий, основанных на этой платформе.

Теперь я знаком с общей схемой наличия командных классов для описания действий пользовательского интерфейса, но должны ли они представлять изменение состояния вЭлементы пользовательского интерфейса или изменение данных в базовой модели?Сколько данных и состояний должен содержать командный класс?

Пример, иллюстрирующий мою точку зрения: предположим, у вас есть QStandardItemModel в качестве базовой модели и несколько прокси-моделей, расположенных поверх этого.Каждая модель прокси будет выполнять своего рода преобразование, такое как фильтрация по появлению определенного значения.Затем, если я создаю класс команд для конкретного изменения одного значения в одной из этих моделей прокси-серверов, и условия фильтра меняются, состояние этого класса команд становится недействительным.Поэтому я должен также включить состояние фильтра или отображение в основную базовую модель.Другой вариант - добавить команды для всех изменений состояния в пользовательском интерфейсе (например, те, которые вызывают изменение условия фильтра), но недостатком этого является то, что список отменяемых команд становится довольно большим.

Какие здесь лучшие практики?

Answer 1

Это в некоторой степени зависит от вашего приложения и способа его использования, но вот общие рекомендации, которые я использовал в прошлом для команд отмены:

• Является ли это частью данных?Если это так, пользователь должен иметь возможность отменить его.
• Сохраняется ли как-то (запоминается между сеансами приложения)?Если это так, пользователь, вероятно, должен быть в состоянии отменить его.
• Это связано с основным назначением программы?Если так, то отмена.
• Это часто выполняемая часть рабочего процесса?Если это так, скорее всего, невозможно отменить.
• Это вызвано тем, что что-то еще меняется?Если это так, он должен отменяться, когда другой элемент изменяется обратно, а не сам по себе.
• Сбрасывается ли он каждый раз, когда происходит * X *?Возможно, вам удастся сойти с рук, если он не будет в стеке отмены.
• Легко ли его отменить одним и тем же движением (например, скрыть / показать дополнительную информацию)?Вы, вероятно, не хотите этого в стеке отмены.

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