OberonCore

предлагаю маленькое изменение в портовом `Input` (как минимум для GNU/Linux): тупо добавить туда «поспать». в подавляющем большинстве случаев эта процедура используется в tight loop для слежения за мышью, и жрала у меня около 90% CPU. если там в самом начале безусловно поспать три миллисекунды — то лично у меня потребление CPU падает до 6% (тестировал выделением текста мышью). разница огромная: вентилятор перестал адово раскручиваться, как только я нажимаю кнопку и таскаю мышь. ;-)

опыт (на моей технике) показывает, что спать меньше трёх миллисекунд — это 15%-20% CPU, а больше — потребление CPU падает очень незначительно. в принципе, этот параметр можно сделать регулируемым через глобал, но я не вижу смысла. то есть, я пробовал 13 миллисекунд — потребление CPU упало до 2%. поэтому не вижу смысла делать больше трёх. ну, можно пять, для надёжности, так сказать.



p.s.: я лично вообще себе туда воткнул 17. пока вроде бы ничего не сломалось, ест около 2% CPU.

Выглядит как весьма рациональное предложение. Сейчас ещё у коллектива спрошу отношение.

Микрокостыль?)) Если помогает, почему бы и не поставить.

да, костылик, конечно. по уму надо бы две функции: одну чтобы опросить состояние «вот прямо сейчас», и одну чтобы в цикле крутить. но это ломание апей, а костылик пока что позволяет обойтись без ломания.

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

p.s.: на днях постараюсь закинуть новый StdStdCFrames, там много всяких вкусных изменений (поиск по листбоксу набором текста, более близкая к виндооригиналу реализация комбо, со скроллируемым попапом если надо — но без редактора пока; редактор надо бы вынести в отдельный кусок, чтобы повторно использовать где надо, фикс с memory leak — там адовый лик, и прочая мелочь). опять таки: далеко не идеал, но «бета зен носинг». надо бы ещё напрячься и tree сделать…

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

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

Чтобы решению не быть не костылём, надо добавить Ports.SetInputDelay(ns: INTEGER) и соответствующую глобальную переменную для использования в реализациях. После чего пропатчить все циклы, где используется f.Input в блокирующем исполнении установкой соответствующих задержек.

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

просто `Input` в некоторых местах используется (не очень корректно, ну да что уж…) для получения, например, состояния ctrl/shift/alt, или единоразового получения координат. предлагаю `Input` оставить с паузой, которая через Ports глобально регулируется — таким образом даже контролы, которые не в курсе нововведений, будут отдавать CPU. а пропатчить места, где `Input` используется как раз не в цикле, и там делать `InputOnce`, которая паузу не держит (в StdStdCFrames, например, такое встречается).

Да, так лучше тем, что детали реализации не просачиваются в интерфейс. Но изменится интерфейс. Хотя там уже дополнено DrawRaster, поэтому он уже нарушен. Поэтому лично я считаю, что проблема достаточно серьезная, чтобы сделать этот самый InputOnce. Дело в том, что там ведь теперь у нас еще и InsistentActions крутятся внутри Input, поэтому эта точка в каркасе изменялась, и вызов InputOnce позволит наше нововведение легко обходить для тех задач, где эти действия нельзя вызывать по какой-то причине во время обработки петли ввода. Мы как бы дополняем эти InsistentActions — даём лекарство и антидот сразу к нему в случае передозировки.

Бедный Input, всем чего-то от него надо...



Чего ж тут некорректного, когда Input используется для выяснения координат указателя или состояния модификаторов? Все в строгом соответствии.

Предложенное добавление задержки в Input плохо именно тем, что это недокументированный побочный эффект.
Равно как и то, что добавлено в Input с подачи Джозефа Темпла для его хттп-сервера, а нами позже "причесано": вызов InsistentActions или как там в конце концов мы их назвали.
И то, и другое - недокументированный побочный эффект.

Джозеф, по крайней мере, понятно, из-за чего замутил воду. Из-за нецелевого использования ББ. ББ - однопользовательское приложение, а не серверная платформа. По причине гибкости, впрочем, оказалось, что и Джозефский сервер потянул. Введение InsistentActions - это попытка расширить целевые использования ББ, т.е. подправить ББ, чтобы он мог и серверные приложения тянуть "без натяжек".

Не оч понятно, для чего вам нужна пауза. Абстрактно, конечно, понятно - чтобы ЦПУ меньше загружался. А практически - не оч понятно. У меня на одной ЭВМ не жужжит, потому что жужжалки нет; на другой жужжалка есть, но действия мышью никак с жужжанием/нежужжанием не коррелируют. Вы прям надолго мышь зажимаете?

Не ожидал, что Иван будет готов


Гораздо корректнее, имхо, было бы
1) ввести
PROCEDURE Ports.PollModifiers (OUT mods: SET);
PROCEDURE Ports.PollPointer (f: Ports.Frame; OUT x, y: INTEGER);
То есть наподобие того, что arisu предложил InputOnce.

2) Изменить контракт Ports.Frame.Input: указать в документации, что "возможны искажения", т.е. побочные эффекты в виде вызова действий и задержек.

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

Не нравится, что тогда у кадра часть работы выносится из методов в процедурные вызовы. Всё же Ports достаточно чисто сделан в плане архитектуры, и не хотелось бы, чтобы решение выглядело "костыльно", на что обратил внимание Борис. А когда работа с объектом кадра рассыпается таким образом (то метод то процедура), что-то в этом от деградации строгости. Чтобы реализовать эти процедурные вызовы, наверное, придётся делать скрытые методы у кадра, опять же усложнение. Также мне очень нравится, что в решении InputOnce мы можем в документации написать, что "поведение Input изменено, однако всем, кому надо старое поведение могут использовать InputOnce". Ещё и патчить не придётся ничего. Но я готов был пропатчить, лишь бы никто не считал наше решение костыльным.

Подумал, что ещё надо добавить три вещи. Документацию надо поправить, тут сомнений нет, верно говорите. Патчить всё же придётся, а то я так написал "не придётся", но придётся меньше, чем каждый цикл. Ну и еще надо добавить, что претензий к InsistentAction нет — это очень хорошее было решение, убирающее опцию "Server mode", а то может вам показалось, что я как-то к ним предосудительно отношусь.

Пожалуй, я передумал. Узнавать координаты указателя и состояние клавиш - дело переопределяемой типовой процедуры. Таковая в платформенном модуле должна быть переопределена.
Но относиться она должна, конечно, не к кадру, а к райдеру, как и Input сейчас. Поскольку кадровые процедуры - не переопределяемы. А райдеры как раз переопределяются в платформенных реализациях.

Напротив, нет смысла делать переопределяемой процедуру Input, поскольку ее услуги четко определяются и фиксируются: получение координат, ожидание и выполнение неотложных действий.

Вот такое предложение:

Такое решение было бы прекрасно, поскольку, наконец, убрало бы вызов Services.actionHook.StepInsistent из платформенных LinPorts.Rider.Input, где он совершенно неуместен.

Еще один довод за переопределяемую процедуру: в системе может одновременно быть несколько реализаций Rider. Сейчас, конечно, это не так, но ничего в наших контрактах не мешает когда-нибудь взять и сделать это. Например, одно окно нарисовать на GDK, а другое - напрямик на X, как arisu собирался сделать.
------------------
Про какую строгость, Иван, вы пишете - не оч понятно. Типовые процедуры нужны в двух случаях, имхо: 1) когда требуется или допускается переопределение в расширениях и 2) когда хочется сгруппировать процедуры, чтобы они в интерфейсе рядышком перечислялись. Может, из стилистических предпочтений, а может, для ясности, если в модуле много разных типов определено.

Можно и объединить PollPointer, PollModifiers, но в тех случаях, что я пользовался Input вне цикла обработки TrackMsg - мне нужно было либо то, либо другое. В GDK все эти сведения добываются одним платформенным вызовом, а вот в WinApi - один для координат, и по одному для каждой клавиши. Но вряд ли это сильно повлияет на производительность.

С предложенным мной решением исправлять циклы, кмк, не придется.
А неотложные действия, да, хорошо что ввели. Правда, сейчас бы я их назвал не Insistent, а Inpostpondable - собсно неотложный.

Такая организация уже выглядит очень продуманно. Только надо ещё isDown считывать вместе с модификаторами, или сделать его одним из модификаторов, скажем isPressed, чтобы потом возвращать isPressed IN mods в поле isDown.

Строгость в том, что нет для кадров кроссплатформенной реализации запроса этих параметров (кроме самого Input...), чтобы помещать в процедурный вызов, пришлось бы что-то городить. Для интерфейсного модуля System это неприемлемо. Сделали через райдеры. Они открыто дополняют интерфейс. Получился больше порядок.

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

о, пока я спал, тут обсуждение. здорово!

задумка Антона Александровича мне тоже нравится: это примерно то, что я и имел в виду: старый добрый `Input` реализуется через вызов `InputOnce` и паузу. разбивать `InputOnce` на координаты и модификаторы удобней, согласен, потому что действительно именно всё вместе нужно не так часто, да и атомарность действия тут не критична. я так не предлагал чисто из-за некоторого понижения эффективности, но на самом деле мне это решение нравится больше, чем «монолитный» вызов.

в общем, если кому-то зачем-то надо знать моё мнение, то я категорчески «за». ;-)

а чтобы `Input` совсем отвязать от системы, предлагаю просто добавить тот же Services что-то типа `SleepTicks (count: INTEGER)`. LONGINT тут лишний, мне кажется, просто целого хватит. в конце концов, в Services уже есть `Ticks()`, так что особо чужеродно оно выглядеть не будет. тики в `Input` сделать просто константой: совершенно согласен, что кому будет сильно надо — тот просто перекомпилирует модуль, да и всё.

p.s.: я не «собирался», я всё ещё собираюсь отвязаться от GTK. так, мелкая придирка. ;-)

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

это я про случаи, когда, например, в `KeyDown()` контрола используется `Input` чтобы узнать про shift, ctrl, etc. почему омики не стали передавать в `KeyDown()` модификаторы — мне совершенно непонятно. по-моему, есть смысл ввести для контролов `KeyDownMod(ch, mods)`, которая в базовой реализации будет просто вызывать `KeyDown()`. так мы и API сохраним, и избавимся от потенциального десинка данных.

понятно, что это можно сделать просто перекрытием соответствующего «низкоуровневого» обработчика. но `MouseDown`, `KeyDown` — они удобные, и не хватает самой малости, чтобы `KeyDown` был ещё удобней. ;-)

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

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

Про KeyDown+ вы зацепляете совсем другую тему.

Дело в том, что StdCFrames - это не лишенный изящества выверт, целью которого было "завернуть" в полноценные Controls ущербные платформенные элементы управления. Задачу авторы решили, и решение довольно изящно, хотя и не лишено родовых недостатков.

Задача их, как я понимаю, была в том, чтобы приложение на Вин выглядело точь-в-точь как Вин-приложение, а на Мак - точь-в-точь как Мак-приложение. Была середина 90х, такова была мода.

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

Почему ущербны. Потому что интерфейс StdCFrames - это огрызок нормального полноценного интерфейса вида Views.View. Заметьте, например, что в Controllers.EditMsg есть .modifiers, а внутри .StdCFrames.Frame.KeyDown вам потребовалось вызывать f.Input. Если бы вы делали нормальный вид в ББ, то вам почти никогда бы не потребовалось вызывать f.Input, потому что оминки - как Тинькоф: они подумали обо всем.
У StdCFrames.Frame нет нормальных HandleCtrlMsg, HandlePropMsg, HandleModelMsg, HandleViewMsg. Это огрызок. Делать на этом интерфейсе виды и приборы управления - каторжная работа.

Заметьте тж, что StdCFrames - единственный случай, когда модуль из Std импортируется в System.
Раньше этот интерфейс реализовывался в Win/LinStdCFrames, а потом стали делать его универсальным, и мы согласились перенести реализацию в StdStdCFrames - это тоже вынужденное нагромождение. Короче, избавляться надо от этого атавизма.

И поскольку задачи "притвориться Виндофсом" или "Притвориться линуксом" или маком - уже не стоит, я предлагаю поэтапно избавиться от этой отрыжки-анахронизма и реализовать приборы управления как полноценные Views.View/Controls.Control. Они будут полноценными, переносимыми, ББ будет "герметичным", и в реализации не будет костылей и трюков типа вызова Input.

На этом пути есть сложность: нужно сделать так, чтобы читались старые odc (а в них - реализация типов из Controls, которая полагается на StdCFrames), сохранялись по-старому (чтобы не потерять форматную совместимость со старыми ББ), а работали бы - новые реализации.
Эту задачу я решил, в эксперименте, еще в ноябре 2021 года. Там нужны небольшие дополнения в Controls, которые не нарушают обратной совместимости. Но Иван горой встал против и не включил этот эксперимент в 2.0а.
Решение позволяет, как принято в ББ, подставлять разные директории с реализациями. Сейчас у меня готово поле EditField, списки, выпадающие списки. Прямо сейчас вот делаю булевы кнопки - похожи на галочки.

Мне, честно говоря, жаль тех усилий, которые вы вбухиваете в StdStdCFrames. На мой взгляд, сделать полноценные Controls.Control - и проще, и перспективней.

нет

А почему для выбора цвета нужна модальность?

Если вы сделаете, напр, Controls.Control, который будет привязываться к INTEGER и Dialog.Color и давать выбрать цвет - на основе такого прибора вполне можно сделать формы или выпадающие приборы.

Модальные данетки остались на вопрос о закрытии несохраненного документа. Но у меня - немодальная реализация этого диалога с пользователем. Даже две.

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

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

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

в основном потому что `Dialog.GetColor()`, например, так устроен (и другие `get`). ожидается, что они вернут готовый результат, а не вызовут какой-то колбэк. я пока не готов менять апи, а «изкоробочных» сопрограмм, чтобы его проэмулировать немодальными окнами — нет.

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

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

моё предложение просто встраивать этот вопрос в документ (типа оборачивать view, и требовать, чтобы пользователь ответил) особого энтузиазма не встретило. хотя в своём текстовом редакторе (не на CP/BBCB ;-) я делаю именно так: все промпты привязаны к фрэйму документа. тут есть небольшая проблема, правда, с документом, для которого открыто несколько видов, но она решаема.

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