Продолжение истории
Что ж, backend у нас уже есть. Давайте создадим для него некий простейший интерфейс и сразу же включим всё что получилось в ифраструктуру системного конфигуратора.
Хочу сразу отметить что в этом месте alterator меняется сейчас как никогда часто, поэтому возможны некоторые несостыковки при прочтении этого текста месяца эдак через два.
Всё сказанное относится к сборке 1.99-alt41.
Как вы, должно быть, помните каждый диалог имеет свой идентификатор и есть карта которая даёт соответствие между этими идентификаторами и файлами описаний.
Назовём наш диалог «/simple_i18n».
Вот как выглядит для него карта:
Помимо понятного уже (/simple_i18n file «/usr/share/alterator/ui/simple_i18n/i18n.scm») появилось ещё несколько невразумительных конструкций. Не вдаваясь пока в подробности расскажу для чего они:
(/acc-hook view /simple_i18n)
Эта фраза означает, что мы вешаем наш диалог по имени «/simple_i18n» на «крючок» к ALT Linux Control Center и он появится в списке предлагаемых модулей.
Дополнительные параметры:
acc-iсon «/usr/share/alterator/ui/simple_i18n/i18n.png»
Иконка которая будет отображаться рядом с шагом в Control Center. Если иконку не указывать, то будет использована некоторая стандартная.
description, (i18n:tr “Simple i18n config” “alterator-simple_i18n”)
Описание которое будет использоваться для имени модуля в Control Center и не только в нём, а вообще где это может потребоваться.
Мы сделаем простейшее окно, которое просто выведет нам список доступных локалей, когда пользователь будет выбирать ту или иную из них, мы будем её выставлять в системном конфигурационном файле с кодировкой UTF-8.
Вот тут настал момент истины. Нам надо из диалога исполнить и обработать результат woo-команд «/i18n/available action=list» и «/i18n/current action=write lang=локаль.UTF-8».
Делается это следующим образом.
(woo-list «/i18n/available») – вернёт список ответов, но он будет выглядеть примерно так:
Поэтому надо пройтись по ответу и «выдернуть» нужные нам имена объектов из полного их описания. Для этого есть готовая функция woo-read-names, которой передаются в качестве параметров, имя «каталога объектов» и список ответов на нашу woo-команду.
Итак, (woo-read-names «/i18n/available» (woo-list «/i18n/available») – даст нам список строк
'(«Russian locale for Ukraine» “Russian locale for Russia”), который можно будет уже передать в listbox.
(woo-write «/i18n/current» lang «локаль.UTF8») – соответствует, как можно догадаться, командена модификацию
Приступим, вот первая версия диалога:
Что-то тут явно не хватает? А конечно же надо бы какую-нибудь кнопку для того чтобы принять изменения.
Но мы не будем сознательно делать эту кнопку, нам её предоставит «рамка» в которую вставляется наш диалог в системном конфигураторе. Достаточно просто сказать какое действие мы хотим сделать при нажатии на кнопку по имени «Принять».
Сначала на русском языке скажем что нам надо сделать:
и обработать её результаты.
Чтение данных из локали осуществляется следующим образом:
В ответ приходит список ответов который в случае read состоит из одного, возьмём этот ответ:
Далее в ответе может быть перечислено множество атрибутов, нас интересует только один “stdname”, попросим именно его:
Ну и наконец можно выполнить запрос на запись.
Чтобы окончательно не убить вас разворачивающейся гирляндой, назовём всё что было перечислено выше функцией get-current-stdname и тогда долгожданный запрос на запись будет выглядеть так:
Добавим его в обработчик on-apply, который вызывается при нажатии кнопки «Принять» в окружающей нас «рамке», предоставляемой Control Center.
Объединим всё это в окончательную версию диалога:
Вот и всё, разложим получившиеся файлы следующим образом:
Запускаем acc и наблюдаем свой первый модуль конфигуратора.
Хотите получить standalone версию модуля, которая будет работать без acc? Нет ничего проще, запустите: /usr/bin/alterator-standalone /simple_i18n
Продолжаем неустанно совершенствоваться в Scheme – основном языке программирования alterator.
Вы уже видели в предыдущий раз, что локальные переменные можно объявлять в теле функции, пользуясь тем же самым define
Однако есть ещё несколько интересных и полезных приёмов работы. Воспользуемся тем, что параметры функции по сути те же локальные переменные.
Тогда пример выше, можно было бы сделать следующим образом:
Попробуем понять что же произошло. Мы создали функцию с параметром, который назвали 'a', поместили в неё всё что нам необходимо, и после этого запустили её придав параметру требуемое значение '5'. Всё, как говорится, гениально и просто.
Попробуем ещё, вместо:
мы можем написать:
Данный приём настолько популярен, что имеет общепринятое сокращение – let.
Приведённые выражения в сокращённом виде записываются так:
Если немного поразмышлять, то мы получили не просто способ объявления локальных переменных, а возможность делать блоки с локальными переменными в произвольном месте кода, например:
У этого приёма есть один существенный недостаток, поскольку формальные параметры инициализируются независимо друг от друга и в неопределённом порядке, мы не можем использовать одни из них для инициализации других, например в примере с двумя параметрами нельзя у задать равным x.
Но против лома всегда есть другой лом.
Применим одну маленькую хитрость – будем связывать переменные по очереди:
Тогда всё получится, на момент определения 'y', 'x' уже известен и проинициализирован.
Этот приём тоже очень распространён, а потому тоже имеет общепринятое сокращение – let*.
Продолжение следует ...?