Евгений Темиргалеев писал(а):
P.S. Нельзя ли реализовать специальную операцию по изменению размера так, что на Undo/Redo она не будет "портить вида"? Вопрос, как сочетать её с последовательностью других операций...
У меня была конкретная задача: сделать авторазмер вьюшек при фоновом поступлении данных так, чтобы пользователь мог работать с документом как обычно. Прямой поддержки такого поведения нет. Идеологически устроено так, что контейнер полностью распоряжается своим содержимым. Если он скажет, что встроенный объект должен отобразиться в квадратике 3 на 3 пикселя, тот не смеет ослушаться.
Если подумать о минимальных шагах, которые могли бы этому поспособствовать, то я вижу 4 варианта:
1 - добавить поддержку спецсвойства "авторазмер" в заинтересованные контейнеры (требуется доработка подсистемы Text). При этом изменения размера встроенного объекта будут игнорироваться контейнером автоматически, т.е. не будут попадать в очередь undo/redo;
2 - иметь возможность менять размер напрямую, мимо цепи undo/redo. Полностью выносить изменение размера за пределы механизма отправки сообщений нельзя, так как контейнер должен иметь контроль над своим содержимым (может быть, он должен автоматически что-то выравнивать при этом в соответствии с линейкой), но предусмотреть какой-то особый "не сохраняемый" способ изменить размер можно;
3 - иметь возможность пропускать некоторые действия мимо цепи undo/redo - это и есть notRecorded;
4 - завести дополнительную шину для таких особых сообщений. Это будут операции, которые работают как прочие операции, но не сохраняются в очередь undo/redo.
Другими словами, есть общий механизм отправки сообщений по шине. Во фреймворке на этот механизм дополнительно навесили функцию undo/redo и открыли пользователю доступ гулять в прошлое. Понятно, что не все сообщения, которые потенциально можно передать по шине, возможно отменить, поэтому придумали атрибут notUndoable. Но точно так же ведь бывают и сообщения, которые вообще не имеет смысла учитывать в undo/redo. Они по всем параметрам должны быть именно в шине (контейнер должен на них реагировать, обновляя отображение), но отменять их нет смысла. Не невозможно (notUndoable), а бессмысленно: была их тысяча или не было ни одного - абсолютно не важно, потому что документ не является хранилищем данного содержимого, а представляет из себя лишь "окно", через которое нечто видно (протекающие в сети внешние процессы).
В этом и кроется системное противоречие: мы используем текстовую
модель для создания безмодельного
отображения. Нам важно сохранить текстовую модель как конфигурацию "окна", через которое мы нечто видим, но само содержимое видимого мы должны пропустить мимо очереди undo/redo этой модели окна.
PS: Хочу быть системным архитектором.