OberonCore

Получше вас понял. Давайте так попробуем, ок. В целом - это логично, чтобы не портить SSD, если кто-то настроил /tmp на HDD или RAM диск. Их нельзя зарегистрировать, поэтому они всё равно сохраняются только копированием.

кстати. а почему в `Views.ScrollFrame()` битмаповый скролл не обрабатывает случай, когда у нас окно-тайл? в смысле, если открыть detached window — то текстовый документ скроллится копированием видимых частей, и отрисовкой только повреждённых/новых. но в `ScrollFrame()` нюанс вложеных окон не обрабатывается, и окна-тайлы при скролле всегда рисуются заново. но ведь их вполне можно тоже скроллить копированием, от этого ничего не должно поломаться.

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

то есть, там, где `msg.allowBitmapScrolling := FALSE;` я сделал `msg.allowBitmapScrolling := TRUE;`. таким образом превратив битмаповый скролл из opt-in в opt-out. это должно быть быстрее, чем инвалидировать весь ultimate root, как происходит сейчас.

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

p.s.: но у меня в LC полностью своя рисовалка на своём же заднем буфере. возможно, были какие-то нюансы с использованием такого скролла средствами host OS? кто-нибудь из уважаемых коллег помнит? там вполне очевидно код читали и меняли, но обработку вложеных окон не добавили. просто для надёжности, или с этим были баги?

кстати.

ы? кто тихушкой протолкнул в репозиторий частный хак для какой-то своей подсистемы? ;-)

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

Насколько часто вызывается BroadcastViewMsg ? Может просто вот так оставить?

постоянно, потенциально много раз за один оборот цикла обработки событий.

не стоит, мне кажется. нигде в документации не сказано, что какое-то из сообщений view может произвольно и неконтролируемо влиять на параметры в других модулях. за такие шутки в приличном обществе принято бить канделябром. ;-)

Не будьте так строги, там по факту код, который не был подвержен финальной ревизии автором. Поэтому в версии для публикации всё могло бы быть лучше. Отчасти ревизия была в `blackbox20dev20dirty`, там более чистый вариант. От туда я ещё не осилил перенос обработки русских клавиш меню, и может ещё что-то полезное там есть. По крайней мере ползунок на откреплённых окнах не раздваивается.

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

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

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

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

Да, это полезно всё в рамках концепции воркспейсов вписывается. Ещё и если на нескольких мониторов много разных отцепленных окон открыто. То надо это восстанавливать успешно.

ещё предложение: в ядре имеет смысл блокировать сигналы прерывания от пользователя, пока идёт сборка мусора. потому что если мы вдруг стукнем Ctrl+C во время сборки — то в общем случае куча будет в неопределённом состоянии. также, если мы трапнулись в процессе сборки — имеет смысл сразу вываливаться в ОС, по той же причине. для этого лично я завёл в Platform процедуры, которые вызываются при входе и при выходе из сборщика, где блокирую/разблокирую нужные сигналы.

подумал: слушайте, а если StdDocuments.Document агрегировать в Documents.(Std)Document, и создавать лениво? пока не надо в окно показывать — там NIL. если надо — уведомляем системный документ, а он другой фабрикой создаёт Std, и просто роутит ему все нужные события дальше? таким образом избегаем постоянного копирования, и в то же время имеем возможность достраивать документ как нам надо. вроде бы агрегирование — это модно и рекомендовано лучшими собаководами.

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

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

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

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

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

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

Так вы анализатор перед компиляцией запускайте, он показывает если переменная используется до инициализации.

он, к сожалению, не лучшим образом работает, особенно с глобалами и вложеными процедурами (он не понимает порядка вызовов, и не врубается в data flow с вложеными).

ну и лень, опять же: у компилятора вся эта информация тоже есть, он и сам может. я, в принципе, начал делать такой линтер, он даже частично работает. у меня в компиляторе есть механизм для пристёгивания разных линтеров, в том числе на лету. один даже в поставке есть: детектор пропущеных RETURN, лучше чем стандартный. просто делать много всего (у меня ж и проекты на самом BB, а не только допилка BB ;-).

Восстановлена поддержка OpenBSD и FreeBSD.

Проверил на

FreeBSD 12.1 i386

OpenBSD 6.8 i386

На всякий случай на Ubuntu 16.04 тоже проверил...

Прошу, у кого какие есть системы, пожалуйста, проверьте.

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

Починил выделение документов. Там была проблема, что сообщения не все контейнеру уходили. А если все отправлять, то была какая-то несбаллансированная отправка сообщений. Поэтому убрал некоторые вызовы обновлений, опрос статуса окна для взятия цвета. Пометил зелёным отличия от 1.7.2 в модуле StdCmds, Views, Services... . Начал переносить clipper для обрезки лишнего у документа. Уменьшил использование StdWindows, позиционируя его как реализацию, а не новый интерфейс.

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

И ещё сделать, чтобы форма при вызове команды "открыть как инструментальный диалог", открывалась в отдельном окне.

а это очень просто: они открываются как SubWindow. штука в `StdTiles.DoOpen()`: когда мы открываем уже открытый документ (т.е. пересоздаём его), он получает тот же домен, что и View (логично), а в этом домене уже есть секвенсор (что опять логично). а логика такая: если открываем что-то, у чего уже есть секвенсор — то это дубликат уже открытого окна, и никак иначе. поэтому получаем не «настоящее» окно, а SubWindow. нужен новый параметр в `DoOpen()` — «игнорировать наличие секвенсора», и передавать туда TRUE в комманде отцепления. и будет телемаркет.

p.s.: также если мы пересоздаём документ, надо отмечать процесс пересоздания как «не записывать в секвенсор», через недокументированый флажок `3`. иначе ундушку загадит ненужными операциями, которые даже отменить тольком нельзя (и ненужно).

p.p.s.: кстати, такую же хрень надо делать в сохранении («не записывать» вместо «скрытое»). так чище и правильней. я вам тогда наврал, что надо `invisible`, надо вот этот недокументированый флаг. хотя по-уму, это должен делать `StdDocuments.ExportDocument()`, когда делает копию документа. и тогда не понадобится никаких хаков в `StdCmds`.