OberonCore

мне бы хотелось сначала больше потестировать… а с другой стороны: если что-то найдём — то сделаем фикс, тоже верно.

может, эту часть в отдельную тему, чтобы если что — туда багрепорты всякие, и улучшения оттуда? только я не знаю, как её назвать. ;-)

ага. проблема в том, что `v.ShowRange()` пытается найти фрэйм для этого view, и не может. использование же публичного API вместо метода делает броадкаст по домену для текстовой модели, и поэтому сообщение приходит. то есть, для новых окон `Controllers.Forward()` не отрабатывает как надо. и `Views.Broadcast()`, похоже, тоже. надо разбираться.

так. странным образом `Views.Open()` в итоге создаёт окно не с тем view, которое вернула `Views.OldView()`, а с другим (похоже, копией). поэтому позиционирование через оригинальную view из `Views.OldView()` и не работает: у оригинала, естественно, нет фрэйма.

ага. кто-то по дороге вместо `Documents.StdDocument` засовывает в окно `StdDocuments.Document`. то есть, похоже, пересоздаёт документ. а! вот этот гад, в StdWindows:



а `DuplicateAs()`, соответственно, делает `Views.CopyOf(src.ThisView(), Views.shallow)`.

я не очень уверен, зачем тут копия вообще, разбираюсь дальше.

p.s.: ага, копия нужна чтобы новый контекст создать для view, под новый документ. тогда я не очень понимаю, почему бы не заменить `Documents.dir` на `StdDocuments.dir`. сейчас попробую.

а! стоп. это уже делается, но кто-то где-то это игнорирует. wtf?!

а, йопт! вот тут у нас всё плохо с чтением ODC.

логика такая: при записи ODC делается подмена: `StdDocument.Document` записывается как `Document.StdDocument` — видимо, для совместимости. а читалка, соответственно, создаёт ровно то, что записано, вместо использования правильной фабрики.

опять мы налетели на проблему, которую уже обсуждали: в Stores иногда надо как-то сохранять не сами объекты, а фабрики, и создавать правильное. но тогда мы не сможем вызвать правильный Internalize…

окей, есть другая идея: попробовать конвертировать документ не при засовывании его в окно, а прямо в `OldView`. я так подозреваю, что это не было сделано для экономии ресурсов. опять же: у нас 2023-й, можно себе позволить немного побарствовать.

ооооохлол! всё, исправление — три буквы: в StdConfig заменить:

на:

всё остальное уже сделали за нас. ;-)

Так не надо делать, потому что StdDocuments не требуется использовать, если документ не планируется показывать.
Документ преобразуется в StdDocuments только при желании его показать.

да, всё верно, копировать вид, если его не требуется показывать — это совершенно непонятная трата ресурсов

Попытаюсь понять, зачем вообще там Views.View копируется. Я это перенёс на автомате из кода Антона, но не совсем осознавал, зачем копировать отображение.

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

так надо делать, иначе ничего не будет нормально работать. это преобразование никому не мешает, оно стоит пол-копейки. зато больше не делается копий view при создании окна.

или так, или куча кода, которая предполагает, что в окне открывается тот же view, который мы туда передали, сломается.

потому что в новом документе нам для view нужен новый контекст, а там уже сидит старый контекст. без копирования не выйдет.

поскольку раньше старый код всё равно не работал — не было смысла делать копирование при импорте. сейчас старый код работает как надо, и единственный вариант сделать нормально — это импортировать документы через StdDocument, и делать копию. ну реально, это стоит почти ничего, зато мы перестаём нарушать «контракт по-умолчанию»: что если мы загрузили что-то через `OldView()`, и потом открываем с этим чем-то окно, то в окне будет именно тот view, который мы загрузили.

право слово: среда делает копии при записи документов — пусть делает и при загрузке. в 2023-м году на скорость и расход ресурсов это уже никак не повлияет, зато мы сохраним совместимость с кодом, который раньше работал, а теперь вдруг отчего-то работать перестал.

К слову у меня предложение отказаться от StdDocuments. Создаётся значительное усложнение архитектуры. Скролбары и оверлэи лучше перенести в StdWindows, ИМХО.

если мы делаем копии при сохранении, то это скорее всего документы, которые мы показываем пользователю, их мало. Но ODC - это ведь универсальный формат, и не только для документов, которые показываются пользователю

я над этим размышляю (и заодно над тем, чтобы StdWindows были чисто реализацией, а все нужные абстрактные интерфейсы жили в Windows). но тут надо хорошо подумать, посмотреть что получится при таком редизайне, и так далее. если я такое сделаю — то опять же: постараюсь тогда и на mainline портировать.

а пока я предлагаю поправить конфиг: это на данном этапе позволит иметь 100% совместимости со старым кодом за счёт того, что мы немножко разбазариваем совсем небольшое количество ресурсов. мне кажется, оно того стоит.

копия же делается как shallow, это очень дёшево. причём копия только самого верхнего view. так что это почти никогда не стоит почти ничего: правильные view с моделями (а это почти все) копировать очень дёшево. а view без моделей случай редкий, и обычно они тоже lightweight.

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

и добавлю оффтопом пару мыслей.

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

и второе: пошаговый отладчик для того, чтобы разбираться с чужим кодом, всё ещё не нужен. мой процесс понимания нужных кусков выглядел так:
1. вставляем в самый верхний уровень отладочные логи (специальные, в консоль, чтобы не триггерить перерисовки).
2. перекомпилируем изменённый модуль.
3. открываем новый экземпляр BBCB, не закрывая старый.
4. делаем действия, смотрим на логи, медитируем.
5. понимаем, куда вставлять логи глубже, идём к пункту 1.
6. кто-то забыл условие выхода из этого цикла. ;-)

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

когда, наконец, стало всё понятно — просто закрываем нафиг изменённые документы без сохранения, и пересобираем среду из консоли (чтобы устранить ошмётки экспериментов).

таким образом мы имеем рабочий экземпляр BBCB, в котором вносим временные изменения, и тестовый, где смотрим на результаты. конечно, процесс можно организовать и с помощью /USE-флагов, но зачем: и так довольно удобно получается.

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

кстати, когда я правлю компилятор, процесс выглядит очень похоже: рабочий экземпляр BBCB, где уже загружены модули старого компилятора, висит открытым пока я не закончу. также рядом болтается коммандер, который перекомпилирует компилятор (уф!), и проверяю я результат в соседней консоли, сборкой всякого тестового хлама. когда всем доволен — собираю систему с нуля уже новым компилятором, проверяю на работоспособность, и, наконец, закрываю рабочий экземпляр BBCB.