OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 16:07

Часовой пояс: UTC + 3 часа


Правила форума


Посмотреть правила форума



Начать новую тему Ответить на тему  [ Сообщений: 649 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13, 14 ... 33  След.
Автор Сообщение
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Четверг, 20 Апрель, 2023 06:09 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
также потихоньку добавляю SYSTEM.ADDRESS. идея такая, что это особое беззнаковое целое размером с указатель, которое не совместимо ни с чем кроме себя. с ним можно делать арифметику, его будет возвращать SYSTEM.ADR. в виде исключения — второй операнд арифметики может быть целой константой. то есть, `adr * 4` и подобные — можно; а `adr * i` нельзя, если `i` сама не SYSTEM.ADDRESS. ещё ему можно присваивать NIL, тоже в виде исключения.

также, наверное, добавлю SYSTEM.SIZET, совместимый с целыми соответствующего размера (знаковый). здесь идея такая, что его надо будет использовать там, где надо `size_t`, а следить, чтобы оно не утекало в другие инты — уже задача программиста.

соответственно, если надо адрес в целое — через VAL кастуем ADDRESS в SIZET. и наоборот, если надо наоборот. адресную арифметику делаем исключительно с адресами, а кто желает иначе — тот рукожоп.

на самом деле самое сложное тут — вычистить код после того, как SYSTEM.ADR начнёт возвращать ADDRESS: во многих местах среда довольно либерально использует для этого целые. собственно, почти везде, только в Kernel были попытки завести свой тип ADDRESS, но особо с этим никто не усердствовал.

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

нет, это всё ещё не значит, что я собираюсь делать кодоген под x86_64, я просто код хочу чуть-чуть почистить. хотя кодоген я бы сделал (тупо добавлением REX-префиксов в стратегические места, да косметическими правками), но у меня и системы-то на 64 бита нет, чтобы тестировать. sponsorship, anyone? ;-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Четверг, 20 Апрель, 2023 21:24 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
вроде бы впилил SYSTEM.ADDRESS, с поддержкой беззнаковых MUL/DIV/MOD и сравнений. ещё разрешил `INC(addr, intvar)` — это удобно для всяких `INC(adr, stride)`. в смысле, сложение-вычитание позволено делать не только с константами, но и с целыми переменными. деление и умножение нельзя (если надо — явно кастуем в ADDRESS, и тогда делаем).

из более-менее глубоких изменений — пришлось добавить в CPL486 `GenUMul()`, `GenUDiv()`. забавно, что сравнения для всего, что не Int — компилятор и так генерирует беззнаковые, даже и делать ничего не пришлось. как и почти со всем остальным: только сказать кодогену в паре мест, что `MachPtr` — это то же самое, что и `Int32`; а дальше кодоген справился сам.

пока что компилятор жестоко заточен на 32-битные указатели, и assert-ит `DevCPM.PointerSize = 4` везде. точно по правилам минималистичного программирования — не пишем лишний код, который «может когда-нибудь понадобиться». если понадобится — тогда и напишем.

дальше будет самая нудная часть: сделать, чтобы `SYSTEM.ADR()` возвращало ADDRESS, и после этого долго и печально править везде типы. добавлю ещё как хак `SYSTEM.ADRINT()`, наверное, чтобы не кастовать постоянно. или не добавлю, посмотрим.

а, да, коммит, гыг. вот.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Четверг, 20 Апрель, 2023 21:45 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
а, и кстати о беззнаковых целых. вместо впиливания их в компилятор — я просто добавил модуль UInts, с кодовыми инлайнами для разных беззнаковых операций над INTEGER. особого смысла иметь отдельные беззнаковые типы в компиляторе я не вижу, и пользы в них — я считаю — немного. в принципе, модуль добавлен чисто чтобы было чуть-чуть быстрее, чем преобразовывать в LONGINT'ы и потом с лонгами работать.

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

да, конечно: вся эта механика предполагает, что целые — 2-complement. поднимите руки те, кому за последние лет тридцать пришлось плотно работать с техникой, где 1-complement. ну поднимите, не стесняйтесь, я хочу на вас посмотреть: мне же интересно, где ещё остались такие динозавры!

кстати, надо бы добавить в язык встроеную функцию `CLAMP(val, lo, hi)`. очень удобная штука, органично дополняет `MIN` и `MAX`. вот только не могу решить, как лучше: `(val, lo, hi)`, `(lo, val, hi)`, или `(lo, hi, val)`? в принципе, форма `(lo, val, hi)` читается наиболее естественно (и позволяет логически вывести поведение в случае, когда `lo > hi`, чисто по читаемому порядку операций), но почти нигде не встречается.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 21 Апрель, 2023 05:50 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
естественно, идея править всю систему (переводя на несовместимые SYSTEM.ADDRESS) была сверхгениальной. поскольку мой слабый мозг не способен вместить подобную гениальность, то я вместо этого ввёл временный режим `MODULE xxx IN StrictAddress`, и буду делать это постепенно. без этой штуки адреса можно присваивать интам, и вообще во многих местах они взаимозаменяемы. `SYSTEM.ADR` (и компания), тем не менее, возвращают `SYSTEM.ADDRESS`, и для адресов — беззнаковая арифметика/сравнения.

задумался над вопросом, какой тип должен быть у результата DIV/MOD/LSH над адресом. по логике вещей — SIZET, но в некоторых местах удобно ADDRESS (для беззнака).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 21 Апрель, 2023 19:23 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
по ходу, кроме `SYSTEM.VAL` надо вводить `SYSTEM.CAST`. семантика `VAL` — пофиг, пляшем, соответственно она спокойно перекрасит тип любого размера в адрес и пойдёт спать. сейчас там хак, и для адресов `VAL` работает именно как `CAST`, но это неправильное смешивание двух семантик. так что буду вводить волшебное кастование, чтобы каст из/в инты неправильных размеров не проходил. возможно, стоит вообще разрешить только каст между адресами и `SYSTEM.SIZET`, чтобы поощрять правильное кодирование. а `SYSTEM.VAL` вообще запретить для адресов (чтобы отлавливать потенциальные ошибки «ой, я перепутал вал и каст»).

если что: нет, даже ежели вдруг когда-то я сделаю 64бит кодоген, размеры стандартных типов я всё равно менять не буду. считаем, что они в ультрапаскале прибиты гвоздями раз и навсегда. 2^31 для длины чего угодно вполне достаточно; а если недостаточно — то самое время делать отдельную структуру данных со своими курсорами.


кстати (совсем нет), в файловом апи не хватает операции `Truncate()`. опять вопрос: а если файловая система в такое не умеет? есть мнение, что именно `Files.File` трогать не надо, а надо вводить дополнительные операции через `Files.dir` (или вообще импортировать HostFiles для такого). rationale: файловый апи в BBCB красивый и минималистичный, не хочется его раздувать. в импортировании Host для каких-то очень часных случаев я тоже не вижу особой проблемы — просто надо модули с таким импортом хорошо изолировать.

откуда вообще про `Truncate()` вопрос возник? а из Utils с сайта Зина: там есть реализация кучи на деревьях и внешнем хранилище, и она использует обсечение. при этом лезет напрямую в винапи — а вот это уже фуфуфу. я добавил `Truncate()` в HostFiles вместо этого.

алсо, HostFiles и HostFiles64 для каждой из подсистем — почти полная копипаста друг дружки в плане reader/writer/buffering. оно, конечно, компоненты и всё такое, но это тот случай, когда я вижу смысл попробовать выделить абстрактный интерфейс для буферизированого i/o в отдельный модуль, а писалки и читалки конкретизировать обращениями к OS API уже. есть мнение, что такой интерфейс и сам по себе может пригодиться.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 22 Апрель, 2023 22:02 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
arisu писал(а):
и вот двоеточие меня в плане читаемости тут не устраивает: ну слишком легко его при чтении не заметить. как минимум — мне легко
А идею про вставку несохраняемых знаков вы здесь не рассматривали?

arisu писал(а):
оригинальный компонентный паскаль на всякий случай всё ещё поддерживается в полном объёме через `MODULE xxx IN ComponentPascal`.
По идее, всё должно быть наоборот - любое изменение языка по IN, а по умолчанию обычный КП.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 22 Апрель, 2023 22:09 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
arisu писал(а):
кстати, надо бы добавить в язык встроеную функцию `CLAMP(val, lo, hi)`. очень удобная штука, органично дополняет `MIN` и `MAX`.
И насколько часто эта штука встречается? Если нечасто, то выглядит слишком надуманно в сравнении с кристально понятным MIN(MAX(lo, val), hi), которое можно научить оптимизировать компилятором.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 22 Апрель, 2023 22:29 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
arisu писал(а):
да, конечно: вся эта механика предполагает, что целые — 2-complement. поднимите руки те, кому за последние лет тридцать пришлось плотно работать с техникой, где 1-complement. ну поднимите, не стесняйтесь, я хочу на вас посмотреть: мне же интересно, где ещё остались такие динозавры!
Вы как-то слишком сузили контекст. Я не работаю с обратным кодом, но предпочитаю работать с числами на высоком уровне так, чтобы была неважна система кодирования - симметричный диапазон и переполнение как ошибка. Я рассматриваю зависимость от системы кодирования в высокоуровневом коде как ошибку в проектировании.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 24 Апрель, 2023 00:09 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Comdiv писал(а):
А идею про вставку несохраняемых знаков вы здесь не рассматривали?
я всё ещё не убедил себя в том, что стоит полностью плюнуть на чисто текстовое представление исходников, и более широко эксплуатировать встроеные views. в идеале оно должно быть именно так, но на практике — пока BBCB отсутствует под четыре актуальные архитектуры (x86, x86_64, ARM32, ARM64) — я всё-таки останусь с текстом как единственным универсально переносимым форматом. я, например, хочу в будущем сделать ульрапаскалевский фронтэнд для Fox; если мне ещё и читалку odc придётся там костылить — задача резко усложняется дополнительной работой.

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

так что думал, но серьёзных аргументов «за» пока не нашёл.

Comdiv писал(а):
По идее, всё должно быть наоборот - любое изменение языка по IN, а по умолчанию обычный КП.
это зависит от целей проекта в целом. язык реализации LC — это Ultra Pascal; соответственно, язык, рекомендованый к использованию по умолчанию в LC — тоже UP. совместимость в плане «просто берём код от оригинального BBCB и меняем там ничего» — цель важная, но вторичная. в принципе, она сейчас решается путём дописывания уточнения в исходник, после чего даже куча интересного старого кода из linref вполне собирается. даже мой древний код из 2004-го собрался и заработал.

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

LC — это, всё-таки, не просто сборка, а вполне полноценный форк, со своим путём развития. в принципе, полностью как рекомендует Вирт: делаю язык и систему под свои задачи, адаптируя существующий дизайн.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Понедельник, 24 Апрель, 2023 00:45 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Comdiv писал(а):
arisu писал(а):
кстати, надо бы добавить в язык встроеную функцию `CLAMP(val, lo, hi)`. очень удобная штука, органично дополняет `MIN` и `MAX`.
И насколько часто эта штука встречается? Если нечасто, то выглядит слишком надуманно в сравнении с кристально понятным MIN(MAX(lo, val), hi), которое можно научить оптимизировать компилятором.
в моих задачах довольно часто, откуда и возникло желание. тут вопрос не столько в оптимизации кода, сколько в том, что `MIN(MAX(…))` всё-таки при чтении надо интерпретировать. ну, или перестать воспринимать как отдельные команды, и приучиться читать как целый глиф — а я не люблю глифы без нужды.

Comdiv писал(а):
Вы как-то слишком сузили контекст. Я не работаю с обратным кодом, но предпочитаю работать с числами на высоком уровне так, чтобы была неважна система кодирования - симметричный диапазон и переполнение как ошибка. Я рассматриваю зависимость от системы кодирования в высокоуровневом коде как ошибку в проектировании.
а здесь у нас классическая задача, у которой нет единственно правильного решения. я приверженец точки зрения, которая говорит не забывать о том, что код в итоге исполняется на вполне конкретном железе с вполне конкретными характеристиками. соответственно, при написании кода важно — в том числе — помнить, сколько бит в целом, как оно представлено «на железе» и прочие подобные штуки. и не бояться использовать это знание если оно действительно надо для оптимизации кода. иначе мы получаем современную сишечку, в которой вполне однозначно отображающиеся в машинный код операции на уровне языка являются UB, и компилятор вынужден делать кучу pattern-matching эквилибристики, чтобы превратить «правильный по стандарту код» обратно в пару машинных команд.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Четверг, 27 Апрель, 2023 06:31 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
более-менее относящееся к прошлой дискуссии. штука, которую невозможно (без огромнейших мучений или ассемблера) реализовать в оригинальном BBCB: минимальный PCG32. там референсный сишный код использует умножение с переполнением, а BBCB с FPU для 64бит на этом трапается. на LC — возможно (хоть и не очень красиво, побитового XOR для 64-х бит не хватает):
Код:
   PROCEDURE XorU64 (a, b: LONGINT): LONGINT;
   VAR l, h: SET;
   BEGIN
      l := BITS(SHORT(a)) / BITS(SHORT(b));
      h := BITS(SHORT(SYSTEM.LSH(a, -32))) / BITS(SHORT(SYSTEM.LSH(b, -32)));
      (* this abomination masks the high bits of l *)
      RETURN ASH(LONG(ORD(h)), 32) + SYSTEM.LSH(SYSTEM.ROT(LONG(ORD(l)), 32), -32)
   END XorU64;

   PROCEDURE (VAR ctx: Context) NextRef* (): INTEGER, NEW;
   VAR
      oldstate: LONGINT;
      xss, rot: INTEGER;
   BEGIN
      oldstate := ctx.state;
      ctx.state := oldstate * 5851F42D4C957F2DL + ctx.inc;
      xss := SHORT(SYSTEM.LSH(XorU64(SYSTEM.LSH(oldstate, -18), oldstate), -27));
      rot := SHORT(SYSTEM.LSH(oldstate, -59));
      RETURN SYSTEM.ROT(xss, -rot)
   END NextRef;

проверено электричеством^w методом: «переберём 2^32 результатов, сравнивая код на CP и результат ассемблерного кода от GCC».

а, да: оригинал ещё и не поддерживает сдвиги для LONGINT.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 29 Апрель, 2023 08:47 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
добавил поддержку цвета фона для текста. а почему бы и да: иногда полезно.

для сохранения заабузил поле атрибутов "fingerprint", которое сто лет как не используется. система пишет туда нолик, а при чтении просто игнорирует. соответственно, если там нолик (или отрицательное число) — то фон остаётся прозрачный; а если положительное — то фон будет `fprint - 1`.

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

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

p.s.: починил.


Вложения:
2023_04_29_08_40_16_241x123.png
2023_04_29_08_40_16_241x123.png [ 2.48 КБ | Просмотров: 1277 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Воскресенье, 30 Апрель, 2023 14:01 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
наконец-то собрался и впилил поиск/замену с регулярками; заодно поправил пару мелкобагов в движке регулярок. иногда мне их не хватает (хоть и не так часто, как ожидалось), но в основном это для тестирования движка: всё-таки там абсолютно удолбаный сишный код в оригинале, с кучей goto.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Вторник, 02 Май, 2023 08:34 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
добавил опцию «показывать порядок контролов». код довольно грязный и сделан через анус (я фиг знает, зачем я решил, что это свойство, а не просто дёрнуть флажок), так что на коммит не ссылаюсь.


Вложения:
2023_05_02_08_31_12_419x261.png
2023_05_02_08_31_12_419x261.png [ 10.42 КБ | Просмотров: 1110 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Четверг, 04 Май, 2023 08:17 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
вынес реализацию buffered i/o в HostIOBuffers, и переделал HostFiles/Lin на неё. эти буфера живут как минимум в четырёх местах (HostFiles и HostFiles64, для Lin и Win), и я не вижу ни одной причины не сделать из них общий хост-модуль, который каждая реализация уточнит своими методами для дискового i/o. вытащеная реализация внутри хранит все файловые смещения как LONGINT, так что подходит для всех случаев.

вообще, мне не нравится и то, что HostFiles64 — копипаста. есть мнение, что стоит сделать в Files поддержку 64-битных смещений и размеров через дополнительные методы, типа `Length64()`, `NewReader64()`, и ты пы. в Files они будут делать `HALT(unimplemented)`, а хостовые реализации могут заимплементить, если захотят. один фиг идея «просто сделаем `IMPORT Files := Files64` и всё магически заработает» кривая и не работает.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Четверг, 04 Май, 2023 09:06 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
а фиг там, зачем такие извращения? ввёл вместо этого стандартные типы `Files.Size` и `Files.Offset`, и сделал их LONGINT'ами. для старого кода добавил `Length32()`, `Pos32()` (с проверкой диапазона). починил модули среды, чтобы вызывали 32-бит-апи. и выкинул Files64/HostFiles64/Stores64, потому что нафиг они нужны теперь. для документов больше двух гигов всё равно хипа не хватит, так что 32-битный апи в среде ок. а прямая работа с файлами теперь 64-битная, и если применять правильные типы — то всё красиво (и заодно код лучше самодокументируется).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 05 Май, 2023 10:18 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
касаемо дискуссии о необходимости ручного .Close: НИНУЖНА. только что налетел на баг из-за того, что кто-то (и нет, не я: это код омиков, индексатор из линрефа) решил экономить ресурсы путём закрытия файлов после сканирования. среда оказалась не готова к тому, что открытая в редакторе текстовая модель может иметь закрытую файловую переменную (потому что такого не должно быть никогда). эффект чудесный: бесконечные трапы.

соответственно, я переименовал метод `File.Close` в `File.ForceCloseFile`. да, имя уродливое специально. среда вызывает эту штуку только в нескольких местах (и я не уверен, что даже там это надо, оно больше похоже на остатки старого кода), там я поправил. считаю, что пусть старый код, который пытается так невежливо закрывать файлы, лучше сломается: тогда программист будет вынужден его перепроверить. заодно написал в документации к Files, что не надо среде помогать таким образом: она и сама неплохо справится.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 05 Май, 2023 15:08 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
однако, задолбало. ESC закроет меню, а не диалог.

из диалога можно открыть главное меню по хоткею (если хоткей не занят самим диалогом), но при нажатии ESC закрывался сам диалог, а не меню. то есть, Ctrl+F, Alt+F (нечаянно, при пустой строке поиска) — и открывается меню «File». естественный позыв — сразу нажать ESC, чтобы закрыть меню и вернуться в диалог поиска, но… но фиг там плавал, закрывался как раз диалог, а не меню. не представляете, как адово меня это задолбало. больше такой фигни не будет, теперь всё работает как и ожидает пользователь (я, то есть). естественно, если главное меню неактивно, то по ESC закроется — как полагается — сам диалог.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Пятница, 05 Май, 2023 18:13 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
очень я привык к кейкомбам типа Ctrl+Q, Ctrl+F для поиска выделеного слова, например — а потому добавил к менюшкам поддержку подобных комбо. ссылку на коммит не даю, потому что мои "StdMenus" давно уже не очень похожи на то, что в mainline. но в принципе — ничего сложного, просто в матчере хоткеев докинул кода для комбо, да в парзере шорткатов бью шорткат на кусочки, с трубой в качестве разделителя. шорткаты пришлось хранить в новом поле, потому что в стандартной Item всего восемь символов на шорткат, не хватит на длинные комбы. хак, конечно — но работает, чего там.

надо бы как-нибудь ещё сделать инструмент, который проверяет на конфликты шорткатов в меню.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox: Lament Configuration
СообщениеДобавлено: Суббота, 06 Май, 2023 09:58 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
поскольку LC умеет возвращать список системных шрифтов, то TextFntTools из linref внезапно стала более-менее юзабельной. поэтому я их засунул в стандартную подсистему — а почему бы и да.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 649 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13, 14 ... 33  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB