ECS

А какой уровень кастомизации системы планируется в теории, где будет проходить верхняя граница? На оттенках дефолтных стилей кнопок или даже на их расположении в окнах?

Годнотища! Визуально напоминает убунту, даже баклажановый фон в наличии, хех. А какие планы на дальнейшую разработку? Какой прикладной софт поставлен в приоритет на реализацию? Будет ли это исключительно десктопная ОС или же намечена поддержка лоу-тир планшетов? Бтв это хороший пример, когда истинные гигачады молча созидают шедевры, а мелочные нормисы лишь грязнут в полемике на тему "правильности" методов разработки

Предназначен, я как раз это и предложил в последнем абзаце. Хотя разумнее будет пропатчить экранную либу и метод update, чтобы не добавлять оверхед на сверку таймингов при каждом invoke, т.к. фактических вызовов invoke довольно много на каждый update. Ещё было бы неплохо реализовать форсированную отсылку содержимого буфера раз в N сек, чтобы в случае потери пакетов (при выходе за радиус связи, например) синхронизировать изображение - по аналогии с ключевыми кадрами в видео-потоках Угу, тоже думал об этом, хотя тут остро встает вопрос о кол-ве используемых оттенков на экране. Аппроксимация цвета по индексированной палитре - тяжелая операция, и если 5-10 оттенков color.to8bit() проглотит без проблем, то полные 256 цветов нехило так нагрузят стриминговый хост перед каждой отправкой пакетов. Впрочем, тут надо смотреть на практике: вдруг профит от уменьшения размера пакетов будет ощутимее, нежели отсутствие компрессионных задержек... кодить надо. Кодить сложна!

Где стоит оська - там и будет комфортно. Если хочется именно удаленного управления с комфортом, то проще всего заюзать связку из сервера и беспроводного терминала, они предназначены как раз для этого. Если готов мириться с инпут-лагом и долгой отправкой картинки на планшет, то можно было бы написать полноценный RD-клиент. Проблема в том, что объемы передаваемых данных слишком велики для модемов, поэтому будет создаваться ощутимая задержка: (3 байта на цвет * 2 цвета (фон и текст) + минимум 1 байт на символ в UTF-8) * 80 пикселей по ширине * 25 пикселей по высоте ~= 13.6 кбайт на планшетный экран Можно было бы совсем запариться и передавать лишь изменившиеся пиксели (а не весь экран целиком), но для этого придется модифицировать библиотеку по работе с экранным буфером. Смотри сам, крч, стоит ли оно того

Речь идет о трансляции картинки на планшет в реальном времени, об аналоге удаленного рабочего стола? Если да, то возможность есть - достаточно переслать по модему содержимое экранного буфера, полученного через screen.getNewFrameTables(). Правда, производительность будет за гранью комфорта, т.к. опенкомповские модемы похожи на *пикча*

1) В 85 строке ты заюзал конструкцию discard variable, однако в луа _ является валидным именем для переменных. Следовательно, в каждой итерации цикла в _ записывается ссылка на таблицу дочернего элемента из layout1: 2) Однако в 90 строке ты прокидываешь якобы "пустую" переменную в метод transferItem, которая на самом деле не пуста: 3) Все это выливается в ошибку транспозера, ожидающего число 3 аргументом, а получающего таблицу виджета гуйки: Вообще я не особо вкурил, зачем нужно скармливать transferItem "никакую" переменную, но чо имею - то имею, судить не могу. А для итерации по дочерним элементам можно заюзать следующее: for index, child in pairs(layout.children) do child.onTouch = function() ... end end for i = 1, #layout.children do layout.children[i].onTouch = function() ... end end

О, другое дело, благодарю. Проблему анализа ошибок в либе System нашел и исправил, можно обновиться. А что касается кнопки - транспозеру подавался nil:

Запустил сырцы, ошибка другая, и проблема в отсутствующих локализационных файлах софта (они вообще задумывались или это копипаста с доки?) А почему ошибка другая - это интересный вопрос, т.к., судя по всему, у тебя неверно сработал парсер стектрейса, и система пытается отобразить ошибочную строку файла "(...tail calls...) /Users/hanmag/Desktop/..", которого, конечно же, не существует. Почему это произошло - фиг знает, надо чекать оригинальный стектрейс, чтобы пофиксить парсер. А как чекать - тоже фиг знает, т.к. у меня и стектрейс другой. Wtf крч

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

На самом деле железо ничего не стоит. Обратная совместимость основана на схожести обращения к системным API, в которых и заключается вся ценность ОСей, а железо - так, дополнение. За редким исключением прикладной софт не работает с железом напрямую, а дёргает буферизированные обёртки I/O и монтированные ФСки, вешает хуки на события и анализирует нажатия клавиш через соотв. библиотеки. В майноське и опеноське основные методы либ крайне схожи, что обеспечивает обратную совместимость, вот и всё Это комплекс взаимосвязанных программ? Да. Они управляют ресурсами компьютера? Да. Они организуют взаимодействие с пользователем? Да. Значит, это ОС. Но раз сам pavel1992x софистически утверждает обратное... Ядром опенкомповских ОСей является совокупность их библиотек, которые как раз и занимаются распределением процессорного времени (threads из openos или workspace из mineos), управляют памятью (кеш/выгрузка package) и работают с внешними ФСками (io/filesystem). И надо же, они предоставляют сервисы (API) доступа и к ФСке и сетевым протоколам! А ещё забавно, что у трёх наиболее распространённых ОС (openos/plan9k/mineos) ядра самописные, хотя и функционально схожие, т.к. они писались в одну эпоху без тонн юниксового легаси и многолетнего совершенствования аппаратной части. Однако ни о каком "одном ядре" тут речи быть не может А жаль, что не публикуют. В конкурентной среде рождаются наиболее качественные и доступные массам продукты, стимулированные развиваться естественным эволюционным путём

Ещё можно заюзать dofile вместо require - результат тот же, а либа каждый раз будет читаться из файла без кеширования

Зараза! Ну, тогда только ручная растеризация символов, да. Я от недалекого ума эту фичу напрямую через двумерные таблички реализовал. Может, у тебя получится более грамотное решение https://github.com/IgorTimofeev/MineOS/blob/master/Libraries/BigLetters.lua

local event = require("event") local unicode = require("unicode") local component = require("component") local screen = component.screen local gpu = component.gpu -- Отображаемый текст local text = "Hehe u cute" -- Разрешение по высоте, на основе которого будет подобрана "идеальная" ширина -- Т.к. строка всего одна, она как раз займет 1/3 высоты экрана local height = 3 -- Получаем компоновку мульти-блочного экрана и его пиксельную пропорцию -- Инфа по формуле, если интересно: https://computercraft.ru/topic/2413-kak-ubrat-chyornye-polosy-po-krayam-ekrana-opencomputers/ local aspectWidth, aspectHeight = screen.getAspectRatio() local proportion = 2 * (16 * aspectWidth - 4.5) / (16 * aspectHeight - 4.5) -- Рассчитываем разрешение по ширине на основе высоты и пропорции local width = math.floor(height * proportion) -- Чистим экран gpu.setResolution(width, height) gpu.setBackground(0x220000) gpu.setForeground(0xFFFFFF) gpu.fill(1, 1, width, height, " ") -- Рисуем текст по центру gpu.set(math.ceil(width / 2 - unicode.len(text) / 2), math.ceil(height / 2), text) -- Ждем интерактива от юзера while event.pull() ~= "touch" do end

Небольшой апдейт для ОС: Добавлено приложение Events, работающее по аналогии с OpenOS'евским dmesg Добавлена возможность установки event.interruptingFunction для пользовательской обработки прерываний по ctrl + alt + c Добавлена возможность установки кастомных кодов клавиш вместо ctrl + alt + c Добавлена поддержка precise режима для мониторов без форсированной установки этого режима на false Для магазина приложений добавлена поддержка иконок с разрешением < 8x4 пикселей Исправлен краш проводника при скроллинге в пустых директориях Оптимизирован экранный буфер для прямых вызовов к GPU через invoke без проксирования компонента, что чуть-чуть повышает скорость отрисовки И для местной прошивки EEPROM: Добавлена фича URL boot для выполнения пользовательских скриптов Добавлена поддержка авто-привязки к монитору при его подключении и отключении Добавлено ожидание появления "приемлемой" файловой системы в компьютере с соотв. оповещением, если при включении компьютера она не была обнаружена

Если чо, эт не "официальная" паста, за потенциальную вирусню спустя полгода ответственности не несу хд

Инсталлер на пастбине был снесён по причине *роскомназдор*. Юзай прямую загрузку с гитхаба: wget -f https://raw.githubusercontent.com/IgorTimofeev/MineOS/master/Installer/BIOS.lua /tmp/bios.lua && flash -q /tmp/bios.lua && reboot

https://github.com/IgorTimofeev/OCIFImageConverter/releases

Просто animate.Anim, без (). Со скобками ты передаешь в event.timer результат однократного выполнения функции Anim, а не саму функцию Anim для последующего выполнения

Старая версия не поддерживает ведра из-за ограничений палитры/разрешения, а из-за оконного UI она неюзабельна от слова "совсем". Проведу аналогию: Elden Ring имеет "точно такой же функционал" на GeForce 9800, что и на современных картах - но не думаю, что тебя устроит 1 кадр/сек в разрешении 320x240 Я вообще хотел в инсталлер впилить проверку на тиры железа, но потом подумал, что фиг с ним, пусть ставят, убеждаются сами

Я же написал выше: затем, что биос стал частью оси, которая не поддерживает более слабое железо

В какой файл, в исходник биоса? Зачем в него лезть? Чтобы подправить цветовую палитру? Кто в здравом уме и трезвой памяти захочет этим заниматься? У данного биоса задача элементарная: запустить майнось, работающую на Т3, и дать возможность восстановить её при форс-мажорных обстоятельствах. Среднему пользователю этого хватит с лихвой, а кодеро-боги всегда могут разработать кастомное решение под свои нужды Потому что я считаю, что лишь железо 3 тира способно обеспечить тот внешний вид ОСи, который концептуально задумывался, без ущерба для пользовательского экспириенса. Считаешь иначе? Твоё право, но уважать его я не буду, т.к. не люблю наглый пиар за чужой счёт

Ты спросил "чем данная ось планшетная" - я ответил. Зачем пытаться сравнивать два разных продукта? Повторюсь, планшетные ОС, в отличие от десктопных, не перегружены визуальным мусором, который на экранах с малым разрешением/диагональю выглядит неуместно. У них другой подход к позиционированию, другой принцип по работе с многозадачностью, single app view, все дела. Адаптированные планшетные ОС зачастую выигрывают по части UX у универсальных десктопных - surface/vivobook тому в пример. Отчасти по этой причине ирл до сих пор существует чёткое разделение между планшетами и ультрабуками, хотя железо первых уже лет 10 как позволяет запускать десктопные ОС. Хотя наверняка первичными факторами выступают коммерция и рыночные устои со времен, когда продукты на планшетных ОС стали прибыльны

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

Проблема в том, что ты записываешь данные о логине/пароле в оперативную память, которая по аналогии с реальной жизнью энергозависима - т.е. при выключении/перезагрузке компьютера она очищается. Ну и да, ты прав, логичным решением проблемы будет использовать ПЗУ вместо ОЗУ А вариантов хранения данных довольно много. Например, вот самый простой, когда логин хранится в отдельном файле а-ля login.txt local io = require("io") -- Запись local login = "MyNickName" local file = io.open("/login.txt", "w") file:write(login) file:close() -- Чтение local file = io.open("/login.txt", "r") local login = file:read("*a") file:close() Или вот более комплексный, позволяющий сохранять конфиги твоих разработок в виде сериализованных (сконвертированных в строку) луа-таблиц (массивов), а затем читать их из файла. В майноське, как и в 99% софта, реализован плюс-минус он: local io = require("io") local serialization = require("serialization") -- Запись local config = { login = "MyNickName", lastAuthorization = "09.04.2022 15:00:00", interfaceColor = 0xFF0000 } local file = io.open("/config.txt", "w") file:write(serialization.serialize(config)) file:close() -- Чтение local file = io.open("/login.txt", "r") local config = serialization.deserialize(file:read("*a")) file:close() Ну и полноценные СУБД со сложностью "за гранью богоподобия". Чисто для ознакомления, это не для нас, смертных: