OberonCore

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

поделил архитектуру Lin на Lin, LinGtk и LinX11. всё неграфическое (и шрифтовой движок) спокойно остаётся общим, а бэкэнды, порты, etc. — уходит в свои подархитектуры. у X11 пока ничего нет (кроме биндов к xlib), но это дело наживное. ;-)

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

это я к тому, что в Lamentdev у меня, например, есть Lin и Win части. они даже не заметили, что нативная архитектура теперь не Lin, а LinGtk, ничего менять не пришлось: Просто Собирается.

кстати. в теории (хоть мне и лень это делать) LinX11 может спокойно пережить падение иксов, или по команде переселиться на другой Display: мне от иксов надо только главные окошки, все остальные ресурсы LC сам менеджит. а пересоздать окна — не проблема. так, по ходу, ни один тулкит не умеет.

хм. может и сделаю потом. чисто для троллинга: «а чо, чо, ваши любимые гуя так могут? ахахаха.»

Я пока не знаю к чему приведёт реформа с "один путь - один модуль", но чувствую, что временное неудобство сейчас с дублированием кода потом многократно окупиться. Главное — оно побуждает уменьшать платформенную зависимость, мне нравиться вектор, который задаётся. Не говорю, что ваша система много хуже, но сейчас не хочу менять коней на переправе. Надо обкатать текущую систему с раздельной и понятной компиляцией. Сейчас опробовал это на OpenBSD.

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

ну и какой смысл это всё дублировать? вот точно чтобы где-то в одном месте в них баг поправить, а в другом забыть. а если у меня будет LinSdl, например? или LinArcan? ещё дублей? по-моему, это очень, очень плохая идея.

и чтобы два раза не вставать: картинка. с виду это совершенно обычный BlackBox, но на самом деле это LC без Gtk, на чистом Xlib. оно пока не очень умеет в обработку событий мыши и клавиатуры, но умеет рисоваться, и умеет правильно реагировать на закрытие окна. что, тащемта, обозначает: базовый event loop, диспетчер и вся остальная низкоуровневая механика работают. «у́ра-у́ра!» закричали тут швамбраны все! (и не упали.)

мы бодалися с Xlib, много наших полегло… но почти всё более-менее работает. пока нет обработки клипборда, да `.Input()` проглючивает. но есть диалоги (on top), есть модалы (transient, autorefocus), можно мышетыкать и кнопостукать.

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

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

кстати, Иван Андреевич, у меня появилось мнение, что вы немного слишком упрощённо рассматриваете подсистему Host: как нечно неделимое, атом. а попробуйте посмотреть на среду чуть иначе.

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

Host/Lin, например, имеет базовую часть, которая не зависит от бэкэнда, и подходит и для консоли, и для различных рисовалок. далее есть Host/LinGtk, где лежит код для работы через gtk, и Host/LinX11, с кодом для чистых иксов. обе эти штуки склеиваются вместе инициализатором. HostBackends реализует несколько нужных интерфейсов: для HostPorts (пока что порты копипаста, но я их выделю в общее потом), для HostFonts…

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

и этому нуль-бэкэнду тоже не нужна копипаста основы Host/Lin, он просто реализует интерфейсы.

вот это rationale для моей идеи с архитектурами: мы всё ещё можем иметь сборки для всех архитектур в одном главном каталоге, и вдобавок разделять между разными целевыми архитектурами общий системно-зависимый код. в принципе, довольно много кода из Host/Lin вполне себе выделяется в Host/Posix, и может использоваться в том числе и на *BSD.

при этом если нам нужна только версия под GNU/Linux и X11, то можно просто выкинуть из Host всё, кроме подархитектур Lin и LinX11, например (и корня — Host/Mod). просто удалить — система продолжит работать как будто ничего не случилось. довольно очевидно, что субархитектура LinX11 требует базовой архитектуры Lin (стандартное соглашение по большим буквам), тут даже угадывать не надо.

вдобавок реализации штук типа того же драйвера MySQL, например, имеют архитектурно-зависимые модули импорта библиотеки мускуля в Lin и Win (они чуть-чуть разные), но весь остальной код — он одинаковый. и нам больше не нужны ни селекторы, ни копипаста: среда просто подхватит нужный модуль импорта автоматически.

такая же штука может быть и с ресурсами, кстати.

для пользователя в общем случае не изменилось ничего: если он не использует архитектуры в своих подсистемах — то всё работает как раньше; с той только разницей, что пути к файлам в Mod, Rsrc, etc. надо спрашивать у SubsManager, а не хардкодить. однако стандартные команды из StdCmds/StdApi в курсе про нововедения, и если им передать что-то типа "Mysub/Rsrc/MyResource.odc" — среда организует правильный поиск прозрачно для вызывающего кода. то есть, даже команды править не надо.

Если вернуться к истокам задумок оберон-микросистемс, то они сделали так чтобы не требовались какие-либо пакетные менеджеры для управления сборкой приложения. Удалил папку - нет подсистемы. Поэтому скажем Борис перенес наши наработки по плиточному интерфейсу в отдельный каталог, чтобы легче в рамках этой концепции осуществлять выделение MDI-сборки. Поэтому выделение хоста в отдельную директорию для каждой отдельной системы создаёт прозрачность как пакетного конфигурирования, так и процесса сборки приложения. Прозрачность и понятность выбраны приоритетом для нашей концепции кросс-платформенной разработки. Нет никаких переменных окружения, нет никаких опций сборщика или компилятора — только названия модулей. Удобно ли разработчику — менее удобно. Удобно ли пользователю — более удобно. Лучше думать о пользователях. А вот инструмент для синхронизации между модулями — это уже вопрос решаемый. Я пока использую возможность цветовой маркировки. Но думаю, что какое-то решение ещё может прийти. И нравится направление, которое задаётся. Очень тяготеет к сокращению этих самых платформенных частей, чтобы меньше синхронизировать надо было. У Дмитрия Викторовича сделано так, что макросы генерируют модули. Примерно так и Александр сделал автоматическую генерацию модулей. Думаю, что этот путь вполне нормальный.

Ну скорее я перенёс потому, что Tiler заслуживает отдельной подсистемы и уж точно не имеет отношения в Std.

Идея с Host, который универсальный, с делением на архитектуры интересная -- тут я не спорю. И несколько напоминает оминковский подход тем, что они предполагали под каждую платформу заменять этот самый Host (что в реальности оказалось неудобно для кросс-разработки, сами знаете). Однако, я пока проголосую за отдельные подсистемы для разных архитектур. Да, больше каталогов, но на такой случай можно предложить решение. Кстати, учитывая замечания arisu, можно вполне развести по подсистемам графические и не графические части хоста. Сам думал о таком.

Кстати, с моей точки зрения, было неправильным объединять интерфейсные модули и реализации Host в одном каталоге.

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

дык подархитектуры менеджерятся точно таким же образом.

в вашем варианте невозможно собрать под все архитектуры в одном каталоге. потому что давайте вернёмся к моему любимому примеру Mysql-драйвера хотя бы: там разные импорты для разных архитектур. а мы складываем собраные объекты и символьники в один и тот же каталог. всё, удобство кончилось, начались пляски с селекторами и запоминанием, под какую же архитектуру мы собирали в последний раз. конечно, это можно решить /USE-параметрами… или как у меня, одним коммандером: `DevCompiler.SetCrossArch Name`. в моём случае можно (и я так делаю) держать собраными все бинари для всех архитектур. и селекторов для мускуль-драйвера не надо (я их все там поубирал). по-моему, это намного прозрачней, чем оные селекторы. и, кстати, все инструменты сборки всегда в курсе, под что мы собираем — это может понадобиться в написании тулзов.

собственно, я из LinGtk сейчас компиляю LinX11 как раз через такой коммандер.

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

но ведь есть! см. мускуль-драйвер.

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

как я где-то писал уже, SubsManager в итоге показывает остальной системе отображение документов, подходящих для текущей архитектуры, из множества «все доступные документы». с точки зрения «вне BBCB» управление происходит не сложнее, чем было: удалили подсистему — её нет. зашли в каталог подсистемы, удалили Mod/Lin, Mod/Rsrs — всё, архитектурной части для Lin нет. по-моему, никакой менеджер пакетов тут всё ещё не нужен.


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

ещё больше подсистем в корне наплодится. ;-)


p.s.: я так упорно ною потому что мне кажется, что я очень плохо пояснил свою идею, и её до конца не понимают. ну, или просто потому, что считаю свой вариант более удобным не в ущерб простоте, и хочу всех в этом убедить, тоже может быть. ;-)

Уже рушится простота хотя бы тем, что вы добавляете понятие архитектуры в систему сборки. Модули же чисты от этого.

и про LC/X11: ненавижу реализовывать selection protocol в иксах. да, там целый протокол, с пульсами и ack. и мне ни разу не удалось реализовать его так, чтобы он работал со всем софтом (потому что разный софт, в свою очередь, реализует его тоже не всегда одинаково). эта проблема и в gtk есть, и в qt (в смысле, они тоже не со всем работают), так что сильно хуже не станет, конечно.

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

так и у вас она присутствует, только неявно. и вам удаётся get away with it только потому, что пока — по большой удаче — объектники и символьники от одной архитектуры подходят другой. попробуйте включить в стандартную поставку драйвер для мускуля, однако (у меня включен ;-) — и лафа сразу закончится: вам сразу придётся костылять. или делать почти полную копипасту подсистемы Mysql в MysqlLin и MysqlWin (а тут ещё и *BSD на подходе, ой).

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

p.s.: нет, вы, конечно, можете извернуться, сделав динамическую загрузку через `Dialog.Call()` (ну, или Kernel, неважно), и двойной индирект: модуль-прослойка, который хранит указатели из правильного модуля импорта. да, решаемо. красиво ли это? удобно ли? посто ли? мне кажется, что нет.

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

хотя иногда такой прикол имеет право на жизнь, конечно: LC вот на линуксах для реестра использует SQLite. но если в системе SQLite нет — то он прозрачно откатится на плоские файлы, потому что модуль для реестра на скулите просто не загрузится, и не сможет установить хук.

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

ну и раз я уже занимаюсь горячим сексом с клипбордом, то выделил нормально интерфейс в StdClipboard: нечего напрямую лазить куда не следует. заодно и «paste object»/«paste view» допилил. понятно, что это пока только для «внутреннего» буфера работает, но всяко лучше чем ничего (и потом можно доделать). а HostCmds аннигилировал, потому что этот модуль совершенно лишний: всё равно там сидели операции с клипбордом, которые были не реализованы в лин-архитектуре, да `OpenDoc()`, который использует примерно никто.

Да нет, я прекрасно понимаю смысл этой идеи. Тут мне недавно Евгений Эдуардович напомнил, что он что-то тоже подобное рассматривал ранее. И в общем-то, ещё раз повторюсь, сама идея мне нравится. Но мне кажется, что эту проблему нужно решать совершенствованием компонентной модели, а не раскладыванием по каталогам.

О, я тоже его аннигилировал на днях. StdClipboard посмотрю, перенесу правки.

я просто не придумал другого решения, которое не будет требовать танцев с бубнами. чисто по логике: каталоги уже используются и для подсистем, и для разделения документов по категориям. по принципу «не вносим ничего лишнего» я их использовал и для архитектур. в основном это всё спрятано в Host, и в остальном коде не болтается.

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

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

p.s.: в смысле, над идеальным решением можно думать сколько угодно долго, а вот рабочее мне надо было уже вчера. вышло что вышло. ;-)

ну, я в основном просто интерфейс HostClipboard весь вынес в хук, и сделал копию публичного API. так что в юзерском коде всех изменений — это везде поменять `HostClipboard.XXX()` на `StdClipboard.XXX()`. а сам хостовый модуль просто вешает хук теперь. то есть, омикам вот этого апи хватало — и ладно, не будем умничать, а тупо его скопируем. ;-)