OberonCore

Ни за что не поверю что в gtk одно окно не может иметь несколько дочерних
Руками нужно приделать только заголовок для них (чтобы тягать мышкой можно было) и скроллбары. Вот и MDI в полной красе.

Закладки - это просто ужас.

А зачем MDI вообще нужен? На нём что-то завязано? Если нет, то пусть будут обычные окна.

В BB на MDI завязано всё. Весь интерфейс там MDI. Без MDI либо докинга, с обычными свободно болтающимися окнами будет полный баррдак.

Докинг - это прилипание? Тоже не нужно.

Просто без MDI встаёт вопрос о способе работы с самой средой. Если не пытаться придумать что-то новое, то самым подходящим на данный момент кажется плавающая панелька, как в Delphi. Из неё можно и справку вывести, и новый документ создать. А в config можно задавать её показ при запуске.

Достаточно, чтобы она состояла из двух частей:
1. строка заголовка. Стандартный элемент, присутствующий почти у всех окон. За него можно перемещать окно.
2. строка меню. Тоже стандартный элемент. Показывает меню Blackbox.

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

MDI в полном смысле в линуксе нет. Эту возможность не поддерживает X-Window.
Некоторая эмуляция на тему, вполне удачная, есть в Qt.
Без МДИ это выглядит примерно так: верхняя панель с меню в виде полоски и отдельные окна документов.

Сам МДИ в ББ... по всей видимости его появлением мы обязаны Макам. Первый ББ создавался под них, а там одно меню вверху экрана на все приложения, которое динамически меняется по конкретику. Поэтому работа в ББ чем-то смахивает на работу с рабочим столом МакОС. Рискну предположить, что использование МДИ было наиболее простым способом переноса среды под Винду.

Однако МДИ стал и отдним из препятствих при переносе на Линух. На его особенности многое завязано.

Далее. В ГТК собственная система обработки событий, достаточно изощерённая. И связать то, что есть в ББ с этими механизмами (корректно связать!) - не есть простая задача.

И ещё одна проблема. Подсистема Хост, в отличии от всего остального, крайне сумбурна. Её по-хорошему следует переписать. В т.ч. и для винды.

Гм. Разве в X-Window нету дочерних окон? Вроде есть.
А больше от него ничего и не требуется.

"Чтобы тягать мышкой можно было" тоже нужно руками приделывать.

Дык, я же ж написал про загловок За него и тягать. А вот про рамку для этих окон я, кстати, забыл.
Помнится я как раз такую штуковину делал. MDI в не MDI окне. Правда под виндой. Но это не важно, ибо от платформы не зависит.

Там всё довольно просто.

Развивая идею, можно превратить одно окно(Gtk, Иксы - не важно) в ББ-контейнер(Container) особого типа, который будет эффективно и платформонезависимо содержать в себе меню, и MDI, и хоть чОрта лысого. Опять же, от системы нужен минимум(сообщения), ну и, может быть, механизм вырывания контролов аля CFrames.

Поддерживаю. И это, по-моему, не так уж сложно сделать.

Хотя это противоречит исходной "фишке" Блэкбокса: чтобы на каждой платформе сохранялся родной look-and-feel.
Так и черт с ней, с фишкой. Какой там look-and-feel на линуксе, вот и будет ... нормальный!

Ну вот для Look&Feel есть CFrames(для тех, кто не в курсе - это такой механизм обёртывания системных контроллов во фрейм ББ, вон, в win-версии так оно и работает(правда, почему-то, не привинтили режим реагирования на "наезд" мыши, т.н. hover, но это дело наживное)).

К сожалению, MDI это далеко не только дочерние окна.

Ещё менюшка общая, да. Но это, как и бордюры окон, заголовки, их перемещение и ресайз, вне компетенции X11.

Тут есть терминологическая путаница.
В Windows есть понятие "child window". Это окно, которое насильно затолкано внутрь родительского окна. Но это - окно, причем самостоятельное.
В X Window System правильнее говорить о child widget, т.е. о widget'ах, которые встреных в окно. Заниматься самостоятельной отрисовкой кучи widget'ов - муторное занятие имхо.

Я бы отметил ещё одну проблему. Блэкбокс насквозь заражён "вирусом" COM. Чтобы прочувствовать это предлагаю провести такой опыт (разумеется, приняв меры предосторожности):

1. В модуле Kernel переименуйте процедуру Release.
2. Исправьте все модули-клиенты, вызывающие эту прцедуру (OleServer).
3. Откомпилируйте исправленные модули.
4. Пересобирите Блэкбокс стандартной командой с динамически загружаемыми модулями.
5. Запустите на исполнение вновь собранный Блэкбокс.

И вот тут начнутся чудеса. Error 03. Kernel.Release not found (imported from OleData).

6. Открываем модуль OleData и видим в секции IMPORT, что он вообще не импортирует модуль Kernel.

Что тут можно сказать? Это не просто "недокументированная возможность", а грубое нарушение спецификации языка.
Интересно, как эти "особенности" учитываются при портировании Блэкбокс под Linux?

Тягать можно за что угодно. Но это же надо собственный менеджер окон встраивать.

Процедура Release относится, как и неск. других процедур Kernel, к обеспечивающим во время выполнения. Пример: Kernel.New, которая динамически связывается с теми местами кода, где вызывается NEW. Release вызывается для объектов COM. А эти объекты описываются в модулях с IMPORT COM (псевдомодуль). Всё локализовано. И любой псевдомодуль компилятора по определению расширяет язык.

Командира! Компилятора -- шайтан, однако

Назначение процедуры Release мне понятно. Непонятно мне другое, зачем надо было так сильно привязывать реализацию Блэкбокс к технологии COM. На уровне компилятора. Котлеты, мухи -- всё в перемешку! Как это разгребать при портировании системы? Кроссплатформенность страдает. "Пополамный полумух", например, использует объектную модель SOM, которая лучше, чем COM.
Интересно, в Линукс COM как-нибудь представлена? Ответьте, кто юзает. Если нет, то:

В неграфическом плане вообще не мешает... Из ядра выкидывается эта часть. Компилятор вообще можно не трогать.
В графике кое-где вплетено, но тоже отслаивается. Графику вообще переписывать надо, подсистему Host.