Главная » Записи с метками 'планы'

Архив метки: планы

Комментарии

Нет комментариев для просмотра.

Чего нет в “24-м релизе”

Всё перечисленное ниже не успеет войти в релиз 1.05.024 по очень простой причине – я уже работаю над следующим релизом. И немало в этом преуспел. Во всяком случае, сохранив внешнее сходство с релизом 1.05.024, новый будет гораздо более удобен. В первую очередь он станет ориентирован на людей, имеющих проблемы со зрением (испытал на себе, не могу без содрогания вспоминать). Здесь и настройка цветовой палитры, и приспособленность к “тёмной” и контрастной теме оформления экрана Windows, и учёт особенностей масштабирования (укрупнения) текста – от исходного 100%, через 125%, и до крупного 150%. И ещё много чего, перечисленного ниже.

Автоактивация без ввода персонального ключа

В новом релизе встроен механизм автоактивации, обеспечивающий работу с большинством подгружаемых плагинов без ввода персонального ключа активации. После установки всех пакетов CheckLog загружает все плагины, но небольшая часть из них остаётся “неактивной” до активации системы персональным ключом. Впрочем, с помощью большей части плагинов, работа с которыми поддерживается автоактивацией, система покрывает практически все потребности обычного радиолюбителя. Автоактивация не распространяется на наблюдательские позывные, содержащие знак “” в любой позиции, в таких исключительных случаях всё равно придётся запрашивать персональный ключ. Например, для позывного UA3050SWL ключ не нужен, а для позывного R2F-055 – необходим.

Унификация вывода сообщений на форме

Речь о выводе служебных сообщений в поле Progress на форме многих плагинов. До сей поры процедуры были специфичны для каждого плагина. Мне это надоело, поскольку при доработках приходилось разыскивать все такие места в исходных текстах плагинов (а их, как известно, уже 25 штук, причём в некоторых поддерживается несколько функций, более одного пункта меню). Вместо этого будет одна-единственная процедура, перенесённая из исходного кода плагинов в одну из общих библиотек. Соответственно, для изменений достаточно будет смотреть в одно-единственное место, где и править, и тестировать, и единообразно применять для всех возможных случаев.

Унификация вывода сообщений в файл ошибок

Файлы ошибок (*.err), формируемые при работе плагинов, были весьма лаконичны, однако сообщения в них подчиняются общему правилу: выводится позывной, для которого отмечена та или иная ошибка (предупреждение, исправление); потом идёт условный знак, определяющий характер ошибки; потом строка данных, по которым можно разобраться – что именно неправильно, как исправлено или как на это реагирует система. Никаких комментариев по поводу условных знаков в тексте файла сообщений об ошибках не было. Отныне в каждый файл, если он формируется, будет добавляться префикс – несколько строк, содержащих перечень использованных условных обозначений. Префикс состоит из строк, начинающихся символом “|” в первой позиции, поэтому при необходимости дальнейшей автоматизированной обработки ошибок его легко можно будет отличить от собственно содержательных строк. Ну, и не нужно будет всякий раз копаться в документации, в поисках значения того или иного условного символа – всё будет непосредственно перед взглядом пользователя. Кому надо – легко разберётся.

Подсистема синхронизации времени

При работе ряда плагинов (в частности, SrvWSJTX, обеспечивающим стыковку с программами цифровой связи WSJT-X, WSJT-Z, MSHV, JTDX) и собственно для проведения таких связей важно, чтобы часы локального компьютера были хорошо синхронизированы с “мировым временем”. Обычная практика – ставить на компьютер какую-нибудь дополнительную программу (вроде NetTime), которая следила бы за временем и периодически выполняла бы синхронизацию его с общедоступными эталонными серверами. Но здесь, как говорится, “есть нюанс”: такая программа может “зависнуть”, или потрерять связь с Интернетом, или не выполнить очередную (плановую) синхронизацию. Пользователь в таких случаях имеет все шансы не заметить сбой, и продолжать по своей наивности надеяться, что у него всё в порядке. Заменяя эти внешние программы встроенной подсистемой, ядро CheckLog обеспечивает:

  • надёжную синхронизацию времени как с общепринятыми (из серии *.nettime.pool.ntp.org), так и любыми другими, задаваемыми в настройках, серверами;
  • возможность синхронизации как в момент старта ядра, так и периодически, с заданным интервалом (5, 10, 15, 30 или 60 минут), который можно подобрать исходя из параметров соединения с Интернет и быстродействия компьютера;
  • простой и понятный визуальный контроль успешности последней выполненной синхронизации, в том числе – и при работе модального плагина.

Поддержка “тёмных” и контрастных тем Windows

Я как-то заметил, что при нестандартных вариантах “раскраски” интерфейса Windows отдельные элементы интерфейса CheckLog отображаются как-то “криво”, снижая общее впечатление от высоких качеств системы. Этот недостаток удалось преодолеть, поскольку я наконец-то разобрался с тем, как Delphi (Embarcadero) надстраивает собственную “обёртку” вокруг интерфейсных элементов Windows. Всего-то неделя чтения документации MSDN, и всё стало на свои места: теперь все элементы интерфейса CheckLog будут вести себя так, как если бы они были “родными” элементами интерфейса Windows. Для ядра поддерживается даже смена темы оформления Windows “на лету”, с моментальной подстройкой. Для плагинов несколько сложнее, поскольку, с точки зрения операционной системы, каждый плагин запускается не в системном контексте ядра, а в своём собственном. И этот контекст не является полностью самостоятельным, а подчинён контексту ядра. Поскольку сообщения Windows о переключении темы интерфейса обрабатываются и “гасятся” в контексте ядра, до плагинов они уже не доходят. Городить какой-то дополнительный механизм ретрансляции сообщений Windows по иерархоческой лестниуе контекстов мне не хочется, поэтому только так: плагин учитывает изменения темы только в момент своего запуска, и уже не реагирует на них во время работы. Надеюсь, что это маленькое неудобство не повлияет на удовольствие, получаемое от общего дизайна системы.

Сигнал готовности к приёму по UDP

Теперь левая “синяя” лампочка, появляющаяся в строке состояния на форме Majordomo (и на формах плагинов, если это предусмотрено) отражает состояние встроенного UDP-сервера, принимающего UDP-сообщения от других программ (в ом числе – и от других компьютеров, если это необходимо). Нет лампочки – UDP-сервер выключен. Есть лампочка – включен, причём мигание лампочки означает готовность включенного сервера, а постоянное свечение каким-то другим (не “синим”) цветом сигнализирует об ошибке. Устранимые ошибки исправляются, и мигание в таком случае возобновляется. При неустранимой ошибке лампочка продолжает светиться постоянно, и тогда потребуется операторское вмешательство (например, перезапуск Majordomo, или плагина, или ядра CheckLog).

Ретрансляция UDP-сообщений

Речь опять про WSJT-X, WSJT-Z, MSHV, JTDX и подобных им. Волею своих авторов, эти программы умеют отправлять UDP-сообщения только по одному IP-адресу. Что, с точки зрения протокола UDP/IP, несколько… хм-м-м… странновато. Поскольку возможности, предоставляемые протоколом, авторы таких программ не умеют (или не хотят) использовать как полагается, без непонятных ограничений. Эту особенность учитывает (в новой редакции) плагин SrvWSJTX, которому (через настройки SrvWSJTX.ini) можно “объяснить”, кому передавать полученные им UDP-сообщения. В том числе – другим программам, в том числе – и на других компьютерах. Я, например, легко организовал работу трёх экземпляров CheckLog, на трёх компьютерах. На первом CheckLog работал “в связке” с WSJT-Z, ведя полный протокол проведенных QSO. На втором CheckLog+SrvWSJTX были подняты в простом режиме “локального наблюдения” за работой первого экземпляра, но без записи проводимых QSO в журнал. Наконец, на третьем CheckLog+SrvWSJTX были запущены над журналом радионаблюдений (ну есть у меня еще и наблюдательский позывной UA3050SWL), и там все проводимые на первой системе QSO автоматически заносились в соответствующий журнал, как радионаблюдения за работой позывным R2ADF. Это так, для примера, в порядке баловства. Более практическое применение – в условиях учебного класса, где один из компьютеров (например, учительский) работает в активном режиме, проводя радиосвязи… а все остальные, получая автоматически ретранслируемые этим компьютером сообщения от программы цифровой радиосвязи, дают возможность на каждом из компьютеров класса реально наблюдать за работой радиостанции, не толпясь “за спиной” учителя-оператора. Насколько я понимаю, для подобной организации процесса найти другие адекватные средства весьма сложно.

Другой подход к повторной отправке подтверждений

При двойном клике мыши на записи журнала связей, либо при вызове через главное меню Logbook → View current QSO открывается форма с подробной информацией об этой записи. В ней выаодятся сведения об отправленных и полученных подтверждениях. Прежде нажатие кнопок Drop … marks вызывало сброс как для отправленных, так и для принятых подтверждений. Теперь можно сбрасывать только отправленные, и только в том случае, когда нет принятых. Это решение делает возможным повторную отправку подтверждений, в первую очередь – mQSL, для которых в сопроводительном письме ещё и указывается, что оно посылается повторно, так как на ранее отправленное (с указанием даты отправки) подтверждения так и не получено. То есть становится возможным периодически напоминать “интересным” корреспондентам о необходимости подтверждения QSO/SWL, чтобы “дожимать” результаты по редким в эфире странам и территориям.

Обновление инструкций, встроенная Help-подсистема

Подобная работа требует слишком много времени, причем – в режиме “пошли все на фиг, я тут думаю!”. Вряд ли смогу себе это позволить, когда не сделан (и не выпущен в публичное пространство) новый сайт, на который будут перенесены все функции, включая файловый архив, on-line документация, средства обратной связи и прочая, и прочая, и прочая… С сайтом тоже, как очевидно, работы всего-то “начать да кончить”, а сроки поджимают. Хорошо, что на данный момент я практически закончил всё, что связано с программированием собственно системы, ядра и плагинов. Теперь гоняю получившийся комплект на практических задачах, работаю в эфире, обновляю справочники, обмениваюсь подтверждениями… Меня-то устраивает, но время от времени замечаю какие-то мелочи, противоречащие систематическим правилам и моему личному чувству перфекционизма. Приходится, скрепя сердце, отрываться от остальных дел… править, проверять… ведь сказано же: “Хочешь сделать хорошо – делай сам”. Так что помощников даже для тестирования и формулировки замечаний не найти, то ли все обленились, то ли помирать (не дай Б-г!) уже собрались и отходят от всяких дел.

“Подтяжка” разметки таблиц при изменении масштаба

Как известно, Windows умеет менять масштаб изображения на экране, делая более комфортной работу пользователей со слабым зрением. Стандартно поддерживаются режимы: 100% (без увеличения, 96 dpi), 125% (укрупненно, 120 dpi), и 150% (крупно, 144 dpi). Изменяются как картинки, так и шрифты. А вот с таблицами может быть проблема – шрифт в колонках укрупнился, а границы колонок “не разъехались”. В новом релизе такого уже не будет, все изменения масштаба будут пропорционально отражаться и в разметке таблиц.

Контроль версий загружаемых библиотек

CheckLog в работе использует динамически загружаемые библиотеки, которые должны располагаться в корневой папке системы (там же, где и исполняемый код ядра CheckLog.exe). На данный момент таких библиотек три: libeay32.dll, ssleay32.dll (используются при обращениях к веб-ресурсам по протоколу https), и UnRAR.dll (при необходимости извлечь содержимое RAR-архива). Если вдруг версии этих библиотек окажутся несоответствующими (например, устаревшими), то некоторые функции системы либо не будут работать, либо работать будут с ошибками. Информация о версиях библиотек будет доступна на закладке System формы About.

Новый логотип и новая заставка при старте

Чуть более лаконично, чуть лучше читаемо… Всё ж таки надо менять не только набор функций, но и (хоть иногда) заботиться и о “бантиках”, то есть о внешнем виде и визуальной узнаваемости продукта. Кстати, визуальные изменения затрагивают не только логотип и заставку… тем интереснее должно быть дождаться выхода в свет этого релиза.