OberonCore

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

Согласен, что это правильно будет. Чтобы по умолчанию стал режим открытия по ширине окна.

и ещё: нумпад досадно обойдён вниманием: его не распознают как стрелочки/home/end/pgup/pgdn. я, конечно, единственный на свете динозавр, который ещё со времён «искры-1030» выключает numlock, но… гтк же различает стрелочки и циферки там, так что можно просто докинуть константы в… а, блин, вот нет дифа, забыл куда. куда-то в лин.

p.s.: уже предвкушаю байтораздирающий восторг от попытки слияния моей локальной 2.0 и мастера…

Ну, если надо, то в Школьной сборке подсистема Мастер уже адоптирована под 2.0, можете от туда взять. Она там уже и кросс-платформенная. Для Linux тоже работает.

я про git master branch. ;-)

кстати. адаптированого под 2.0 и GNU/Linux версию persistent desktop ни у кого не завалялось? ну неудобно же, когда не запоминает!

и ещё. вот после убиения HostFiles, например, мне надо теперь импортировать LinFiles, чтобы выковырять из локатора path системно-независимо. только оно получается системно-зависимо, и мой код ни разу не соберётся на винде или бсд. воля ваша, но вы, кажется, что-то не то делаете с уничтожением хоста…

Так вот это важный момент. Мы специально сделали такую перетряску, это очень важный шаг для кросс разработки. Теперь появилась возможность в Windows собирать приложения для Linux, и в Linux собирать приложения для Windows. Такого с Host сделать раньше было нельзя, а если и можно, то только с кучей файловых трюков. Теперь же всё из коробки!

Для получения пути от локатора теперь есть платформенно-независимая команда.

Добавил это сюда https://wiki.oberon.org/blackbox20

спасибо! этого я не знал.

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

а для «и добавить к пути имя файла, и чтобы в конце правильный слэш поставило, если его нет» есть что-нибудь?

p.s.: ни за что не догадался бы искать это в Dialog.

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

ясно, спасибо. а как паллиатив, хоть что-нибудь? ну невозможно же, многие std и прочие системные модули не выгружаются, приходится рестартовать — и всё потерялось. и сразу: «я щаз взорвусь как триста тонн тротила, во мне заряд нетворческого зла…»

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

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

кстати, табам нужен скроллер. ;-) вы попали на любителя открыть 100500 табов и оставить их «на потом».

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

ну тогда, да, надо скорее доделывать SaveWorkspace...


Они скроллятся скроллером. Не идеально, но скроллятся.


Супер. Там пока много "в процессе". В частности сам SaveAction, про который было упомянуто. Так как он экспериментальный, то и код дублирован, чтобы старая реализация была "нетронута", как образец рядом. А так да, надо будет рефакторить потом.

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

Да, согласен. Скроллер - это как временное решение, которое было сделать быстрее всего.

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

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

p.s.: (мечтательно) и пунктик «выделить группу в отдельное главное окно»…

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

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

сообщаю об опасной ужасти в nix-версиях (как минимум в GNU/Linux): для вывода в консоль используется `printf()` с одним аргументом. это чревато: достаточно, чтобы в строке попался какой-нибудь «%s» — и всё, пошла плясать губерния. желательно бы везде это заменить на нечто вроде:

кстати, и вызов `Libc.fflush()` можно будет тогда убрать (или делать его перед `write()` — на случай, если какая-то внешняя библиотека тоже гадит в консоль, и делает это через `printf()`).

и заодно: предлагаю добавить к `MENU` в описании менюшек опциональный модификатор, чтобы можно было делать нечто типа: `MENU(WINDOWS)` — и эта менюшка появлялась только в видоверсии, например. удобно, когда исходники для всех систем лежат вместе, и не надо переименовывать бесполезные "Mdi" и "Com" туда и обратно. я у себя сделал такие модификаторы:

два последних — чисто для удобства, если надо менюшку временно отключить. "ENABLE" просто для консистентности.

destroy!, как говорится у них.

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

Был период, когда команды проверки охран из нового оконного меню завешивала блэкбокс (загружая оконные модули). Это очень сильно мешало в работе, поэтому я добавил достаточно гибкую систему включения и отключения меню, она может быть полезна для разных других проектов. Но потом сделали явную инициализацию оконных систем, и Блэкбокс перестал зависать, и ещё обнаружили, что в Блэкбоксе есть механизм инициализации меню из произвольного документа StdMenuTool.UpdateFromText, так что и для проектов нет нужды в какой-то системе, так как можно всегда добавить некого своего композитора для меню. И поэтому для сохранения простоты каркаса решили ничего не внедрять, оставить всё как есть и я откатил изменения назад. Так оно и будет, ничего не будем менять в меню. Пока хватает других проблем. Также не приветствую внедрения в Блэкбокс всяких дополнительных синтаксисов, ключей и т.п. Лучше все программировать на Компонентном Паскале, если это возможно.