OberonCore

ещё я сделал служебное сообщение PollHotkeyMsg, чтобы не мусорить в StdMenus проверками окон. оно рассылается примерно как обычный запрос хоткеев, и просто возвращает флаг. таким образом, если у нас есть форма — она съедает только «свои» хоткеи, а не все Alt+что-то. оно ещё не до конца допилено, но более-менее уже работает, можно глянуть у меня в репозитории.

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

почему не использовал уже существующее ControlPref? там модификаторы не передают, а менять стандартное сообщение я не хотел.

А, это да, он один. И, если я правильно помню, то так и хотели оставить. Поэтому надо делать такое составное отображение, которое заменить одинарное меню, на меню в выпавшим подменю.

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

Создание полноценных видов-приборов для Controls и сохранение/выкидывание StdCFrames - ортогональны. Мое решение на то и направлено, чтобы сохранить обе возможности. В т.ч. чтобы сохранить обратную совместимость на запись: иметь в 2.0 полноценные виды-приборы, которые будут сохраняться в документы. А на прежних версиях эти же документы будут прекрасно открываться с помощью StdStdCFrames.

Кто захочет хамелеонить под платформу - пусть сделает себе полноценную PlatformStdCFrames. Но в ББ нужны полноценные виды-приборы, реализованные без всяких костылей, одинаково выглядящие на всех платформах, т.е. универсальные. А то, что сейчас имеет место - это создание универсальных приборов-не-видов в ограничивающих рамках интерфейса StdCFrames.

Т.е. самое правильное было бы выкинуть StdCFrames и StdStdCFrames, поскольку негоже импортировать в SystemControls модуль из Std.

Но для обратной совместимости, и если оч важно сохранить для кого-то возможность хамелеонить под платформу - то можно оставить StdCFrames и выкинуть StdStdCFrames (сделав заранее замену полноценными видами-приборами).

Я переработал механизм оверлеев. Документы научил работать с видом-распашонкой: вид, который имеет обычный размер и распахивается на весь документ (или около того). Линейное меню вставляется как такая распашонка. Когда оно распахивается (об этом оно просит свой контекст через .Consider), то имеет возможность внутрь себя вставить вертикальное меню. Это упростило взаимодействие между линейным и вертикальным, т.к. в этой схеме все как в ББ - вид-контейнер (сборник) и вид-содержимое. Когда линейное меню обнаруживает щелк вне линии и вне вертикального меню, то просит через контекст перевести себя в запахнутый режим - т.е. из этой схемы исключен документ, который раньше в этом участвовал; короче, упростилось все.

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

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

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

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

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

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

(просто пробегая мимо) ужасно хочется портировать Doom. никто же не воспринимает ничего серьёзно, пока на этом не написали/запустили Doom.

Хочу обратить внимание на то, что Блэкбокс 2.0 "BlackBox Cross-Platform" — это максимально консервативный проект.

Пожалуйста не предлагайте нововведений. Любое концептуальное отклонение от 1.7.2 и текущей версии — это очень высокие накладные расходы.

Цель — устранить недочёты, выпустить стабильную сборку, зафискировать достижения:
1. Плиточный интерфейс
2. Кросс-компиляция и сборка
3. Библиотекарь
4. Растры
5. Настойчивые и безопасные действия

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

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

тогда, может, давайте сделаем отдельную тему «общий трёп про 2.0»? чтобы тут осталось только то, что к «2.0 in stone», а в той теме мы вкидывали идеи, и если они интересные — тогда можно будет под них и отдельные темы создавать? просто лично я иногда использую эту тему как idea dump, и оно, кажется, не очень в правильно получается.

Да, вот есть отличный подфорум "Вопросы дальнейшего развития BlackBox" там приветствуется свободный полёт мысли про будущее Блэкбокса
viewforum.php?f=127

А вот в этом форуме будет здорово завести тему под вашу персональную сборку, где будете делиться просто новостями любыми про свои достижения
viewforum.php?f=114

UPD: Ну и про 2.0 вы тут пишите, конечно! Я хотел только прояснить ситуацию, чтобы не было каких-то недопониманий, почему ваши иногда весьма дельные предложения могут не найти поддержки. Хочется работать, делать проекты в Блэкбоксе, а не бесконечно его переделывать. Поэтому нужна сборка без багов. А если переделывать всё постоянно, то это не произойдет никогда.

я имел в виду больше отдельную общую тему, куда можно вкидывать не очень оформленые идеи, иногда просто мысли, которые немного пофутболят — и они или сразу будут забракованы как «sorry, i was on high», или дорастут до отдельной темы с обсуждением. кажется, я опять не очень понятно написал…

да, я планирую сделать тему под Lament Configuration чуть позже, когда сочту, что первый technology preview готов к публичной демонстрации. такой план и был. я кинул вам и А.А. ссылки чуть раньше просто потому что оттуда уже сейчас можно выдёргивать полезные кусочки. ну, и тизерю её в разных темах специально, подогреваю интерес. ;-)

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

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

Заложил начало нового чата на тему
viewtopic.php?f=134&t=6894

да, вы правы, это очень важно. но есть ещё и такой нюанс: когда «консервативный 2.0» выйдет — то те решения, которые туда заложены, потом уже очень сложно будет поменять, по тем же соображениям совместимости. поэтому я и шатаю трубу, пока ещё есть возможность — с целью потенциальной минимизации количества родовых пятен, которые 2.0 потом будет вынуждена нести с собой просто потому что Так Исторически Сложилось.

конечно, это часто конфликтует с целью «сделать релиз, который можно использовать, а не залипнуть в цикле бесконечной разработки и перфекционизма». но на то у 2.0 есть люди, которые имеют final say, и не стесняются его say. это хорошо и правильно, проект без чёткого руководства никогда не будет сделан же. но шатать трубу я всё равно буду. ;-)

маленький технический вопрос по CFrames: если однострочное поле редактора по высоте вмещает хотя бы две видимых строки, вин-версия обрабатывает его как multiline, но просто не позволяет вставлять туда 0DX. мне это поведение эмулировать, или оставить одну центрированую строку?

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

в принципе, я тоже так считаю. так и оставлю, наверное.

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