OberonCore

Так в том и дело, что это для немодальных неGTK окон сделано. Там у Антона появляются панельки над документами. И пока пользователь везде на нажмёт на сохранить или несохранить, ББ не закрывается.

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

Посмотрите, там Антон написал такую заметку в конце модуля StdCmds.
"Closing windows and exiting BlackBox"

В файле LinDialog вот эту строчку можно закомментировать
StdCmds.stdDirtyHook := DirtyHook;

а в StdTiles вот так написать
StdCmds.stdDirtyHook := DirtyHook;

Я проверил, будет работать, но неправильно правда, так как не отлажено. Что-то надо менять, а я не знаю что. Так как до конца за ненадобностью не вник. А Антон пользуется своей сборкой, поэтому это в этой не отлажено. Может быть он свою потом выложит, посмотрите у него. Ну и ли совместными усилиями это починим со временем.

посмотрел: там и происходит один из описаных мной вариантов: `GuardedClose()` может вернуть состояние `deferred`, которое надо явно обрабатывать. то есть, как раз таки переписывать все циклы (и не только циклы, тащемта) с учётом этого нового состояния (которое обрабатывается в `StdCmds.Exit` в цикле). это состояние, кстати, просто игнорируется в некоторых других местах, поэтому немодальные данетки и не работают универсально. ровно то, о чём я и говорил: существующий код не совместим с таким подходом, его надо полностью переписывать. и если у кого-то в проекте есть подобный цикл по окнам — такой проект просто сломается с немодальными данетками, и его тоже надо будет переписывать в этой части.

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

Brache. Нашел через https://oberoncore.ru/bbcc/ominc_subsystem_reg, а дальше там ссылка на веб-архив (https://web.archive.org/web/20070705094 ... Brahe.html).

Спасибо! Вещь кросс-платформенная и рабочая.

еще картинка, как оно там устроено

Я думаю, что если это включить в Блэкбокс, то постепенно редактор будет всё лучше. Модулей там не так много, а рисовалка достойная.
Мы полностью заменим векторные рисунки на Brahe, а растровые на Png, и тогда будет кросс-платформенно всё смотреться, и без старых вещей.

Выскажитесь за и против, кто что думает.

Прямо весь редактор в ББ? Он там, конечно, когда-то был, но стоит ли всё втыкать в ББ?

Он там состоит весь из 19 небольших модулей. Можно их, конечно пробовать объединить в 4-6. Там на каждый типовой объект по модулю. И как-то не получится выкинуть часть...

Мне ещё понравилось, что это как пример такого хорошего законченного проекта расширения. Даже в Obx его можно описать как-то, если добавить так.

Мне на первый взгляд нравится идея интеграции Брахе, я сам подумывал об этом, но давно, и времени нет на все. Не знал, что он был для ББ - думал, что только в Систем 3. Разделять на "только для чтения" и "для редактирования" - стоит ли овчинка выделки? Ведь нужно отрезать все Restore от всех HandleCtrlMsg, т.е. разрезать модули внутри, а не по границе модулей даже. Это все нужно тестировать потом.
А иметь редактор схем в составе АРМ программиста - кмк это передовая весчь! Потому как позволит не только в документацию, но и в программы вставлять схемы. На киллер-фичу не потянет, конечно, но вообще это большое преимущество и вполне себе отличительная черта. Я уже трезвонил, что этим пользуюсь, но написал свои три мини-вида для этих целей - с удовольствием выкину и перерисую в брахе, если она окажется в ББ и окажется рабочей.

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

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

Это вы описали или то, что я назвал эмуляцией модальности, или подобие того, что в кооперативной многозадачности делают типа ProcessOneMessage()

Как-то ведь жила целая Oberon, Oberon System 3, Oberon V4 без модальности...

В чате и личных беседах свелось к тому, что сделать надо один модуль с моделью и отображениями, чтобы не маячила целая подсистема для этого. А редактор (контроллер для видов с меню и расширенной документацией) будет в виде расширения уже ставится. Такой вариант будет кросс-платформенным и достаточно приятным, что можно будет снабжать интенсивно документацию рисунками и пояснениями, занимать они будут очень мало места, в отличие от растров, и главное их можно будет подправлять, дорабатывать. Пока четверо человек (я, Борис, Антон и Александр) высказались "за" нативный ББ-формат из сторожил Блэкбокса. Вопрос только получается в деталях, как оно лучше сделать.

в таком виде, в принципе, я тоже «за».

p.s.: только не забыть тексты сделать локализуемыми, тогда можно будет (при должной сноровке) надписи в картинках автоматически переводить.

ну, типа того, да. но это ж и есть, в принципе, «модальное окно», они примерно так и работают. ;-)

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

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

Эмулировать модальность окна - почему бы и нет. А вот кромсать систему, чтобы реализовать Vıews.ask Files.ask - не хочется

Про нативный ббформат я не высказывался. Я полагаю, если будут сделаны виды для векторных рисунков, то и сохраняться они будут как принято в бб, и.е. как виды, без каких-то дополнительных форматов. Разве нет?