Пользовательский интерфейс VPN-подключений
Данная статья описывает процесс реализации расширения для приложения «Настройки», которое позволяет управлять параметрами VPN-профилей подключений для собственных VPN-плагинов ConnMan. Руководство описывает только часть действий, которые необходимо выполнить для реализации полноценного VPN-расширения в ОС Аврора.
- Подсистема управления VPN-соединениями в приложении «Настройки»
- Схемы расширения приложения «Настройки»
- Реализация расширения приложения «Настройки»
- Структура проекта
- QML-плагин
- Локализация строк пользовательского интерфейса
- Проект расширения приложения «Настройки»
- Поддержка нескольких выпусков ОС Аврора
- Реализация документа для списка типов подключений listitem.qml
- Реализация документа для редактирования профиля подключений edit.qml
- Реализация документа для расширенного редактирования профиля подключений advanced.qml
- Реализация документа для просмотра параметров подключения details.qml
- Расширение с использованием внешнего менеджера конфигураций
Подсистема управления VPN-соединениями в приложении «Настройки»
Приложение «Настройки» реализовано по модульному принципу, что позволяет реализовывать расширения для поддержки новых типов VPN-подключений. Задачей каждого такого расширения является создание профиля VPN-подключения, включающего поля для соответствующего VPN-плагина ConnMan. В профиле VPN-подключения содержатся параметры для установления VPN-соединения: адрес сервера, имя пользователя и т. д.
Расширения для VPN-подключения представляют собой набор QML-документов, каждый из которых используется приложением «Настройки» на различных этапах работы пользователя по созданию и редактированию VPN-профилей. Все документы должны находиться в одном каталоге с названием, совпадающим с названием VPN-плагина для ConnMan.
Для реализации данных файлов расширения можно использовать все доступные QML-библиотеки, создавать собственные QML-документы для решения специфических задач. Основной библиотекой для создания данных файлов выступает Sailfish.Settings.Networking.Vpn, типы которой позволяют формировать VPN-профили.
Для решения задачи локализации пользовательского интерфейса применяется подход с созданием собственного глобального QML-плагина. В рамках данного плагина можно также разместить более сложную логику с использованием языка C++.
Схемы расширения приложения «Настройки»
Существуют две схемы реализации расширения: реализация всей логики по указанию параметров VPN-подключения внутри расширения и реализация отдельного приложения, менеджера конфигураций, для формирования параметров подключения.
В рамках первого подхода пользователь управляет всеми параметрами подключения внутри приложений «Настройки». Плюсы такого подхода:
- Пользователь использует одно приложение для настройки VPN-подключений.
- Количество компонентов для разработки меньше по сравнению с альтернативной схемой.
- Сложную логику, включая предварительное сетевое взаимодействие, можно реализовать в рамках QML-плагина.
- Пользователь взаимодействует исключительно с приложением, которое ему знакомо.
Основной сложностью при реализации данного подхода является необходимость в обработке всех параметров подключения в рамках расширения приложения «Настройки» и в рамках VPN-плагина ConnMan.
В рамках второго подхода пользователь формирует параметры соединения в отдельном приложении с графическим интерфейсом, менеджере конфигураций. Обычно эти настройки записываются в собственный формат подключения, который может быть использован VPN-клиентом напрямую. В рамках же VPN-расширений платформы передаётся лишь путь к данному конфигурационному файлу. Плюсы такого подхода:
- При реализации менеджера конфигураций можно повторно использовать бизнес-логику по работе с конфигурациями подключения из-под других платформ.
- В рамках расширений для реализации VPN-компонентов требуется передавать минимальный набор дополнительных данных: путь к конфигурационному файлу.
Основными трудностями при реализации данной схемы становятся:
- Необходимость в реализации ещё одного дополнительного компонента для поставки конечному пользователю, то есть менеджера конфигураций.
- При реализации менеджера конфигураций все компоненты пользовательского интерфейса будет необходимо реализовывать самостоятельно.
- Пользователю необходимо взаимодействовать как с приложением «Настройки», так и с менеджером конфигураций для настройки VPN-подключения.
- Пользователь может удалить конфигурацию VPN-подключения из менеджера конфигураций, не изменив профиль подключения в «Настройках».
При выборе схемы реализации оцените все плюсы и минусы каждого из подходов.
Реализация расширения приложения «Настройки»
Рассмотрим детали реализации подхода расширения приложения «Настройки», при котором вся логика по формированию профилей VPN-подключения выполняется исключительно силами расширения.
Структура проекта
Расширение для приложения «Настройки» состоит следующих компонент:
- QML-документы, образующие само расширение;
- QML-плагин, который обеспечивает локализацию для строк пользовательского интерфейса;
- набор файлов для локализации пользовательского интерфейса.
Для доставки каждого из них необходимо создать отдельный проект.
Таким образом при использовании системы сборки qmake структура проекта выглядит следующим образом:
vpn-provider
├── connman-plugin
├── settings-controls
│ └── settings-controls.pro
├── settings-translations
│ └── settings-translations.pro
├── qml-plugin
│ └── qml-plugin.pro
├── rpm
│ └── vpn-plugin-project.spec
├── vpn-provider
│ └── vpn-provider.pro
└── vpn-provider.pro
Корнем проекта является каталог vpn-provider,
в котором располагается одноимённый .pro-файл.
Данный файл должен описывать проект согласно шаблону поддиректорий
(subdirs)
и включать в себя другие каталоги.
Название проекта и следовательно каталога должно быть уникальным,
то есть вместо vpn-provider следует использовать название VPN-провайдера.
В подкаталогах располагаются соответствующие компоненты расширения. В подкаталоге rpm описывается процесс сборки RPM-архива для установки на целевые устройства.
В каталоге connman-plugin находится VPN-плагин для ConnMan. Детали его разработки приведены в соответствующем руководстве.
В подкаталоге vpn-provider должно находиться обычное приложение для ОС Аврора. Данное приложение не должно выполнять никаких действий, оно необходимо исключительно для успешного прохождения валидации. В рамках второго подхода данное приложение будет выполнять задачи менеджера конфигураций.
QML-плагин
В подкаталоге проекта qml-plugin должен располагаться QML-плагин. В его задачи входит:
- предоставление локализованных строк для пользовательского интерфейса;
- предоставление собственных QML-типов, реализованных на языке C++.
Подробное описание по созданию QML-плагина находится в официальной документации библиотеки Qt. Остановимся на важных аспектах, на которые следует обратить внимание при его реализации.
Установка данного плагина будет производится в глобальный набор QML-плагинов для платформы. Это означает, что все ресурсы данного плагина будут доступны в рамках любого приложения, которое устанавливается на мобильное устройство.
Из этого следует, что необходимо тщательно подойти к выбору наименования плагина, чтобы оно было уникальным в рамках мобильного устройства. Хорошим вариантом для этого является использование доменного имени компании. В рамках примера будем использовать имя ru.omprussia.vpnprovider.
В рамках .pro-файла указывается системный путь к установке данного плагина:
TEMPLATE = lib
TARGET = vpnprovider
CONFIG += plugin
OTHER_FILES += qmldir
MODULENAME = ru/omprussia/vpnprovider
TARGETPATH = $$[QT_INSTALL_QML]/$$MODULENAME
import.files = qmldir
import.path = $$TARGETPATH
target.path = $$TARGETPATH
INSTALLS += target import
Следует обратить внимание на формирование переменной MODULENAME.
Она должна состоять из частей названия QML-плагина,
где каждой части названия соответствует отдельный каталог.
Название QML-плагина также должно быть указано в файле qmldir:
module ru.omprussia.vpnprovider
plugin vpnprovider
В .spec-файл также необходимо добавить указание, что файлы QML-плагина необходимо включить в RPM-пакет:
%files
%{_libdir}/qt5/qml/ru/omprussia/vpnprovider/*
В рамках реализации QML-плагина необходимо добавить свой класс-наследник QTranslator, чтобы обеспечить использование файлов локализации пользовательского интерфейса. Пример реализации данного переводчика можно посмотреть в репозитории TrifleVpn.
Также следует отметить, что в рамках QML-плагина должен поставляться хотя бы один QML-тип. Если этого не сделать, то плагин будет считаться недействительным и будет выгружен, что повлечёт за собой также отключение транслятора.
Локализация строк пользовательского интерфейса
Процесс локализации расширения приложения «Настройки» схож с локализацией обычного приложения под ОС Аврора: в исходных кодах приложения содержатся файлы с текстовым представлением переводом, которые затем компилируются в бинарные файлы в процессе компиляции приложения.
Отличиями являются нестандартное расположение как файлов, которые необходимо локализовать, так и местоположение скомпилированных файлов локализации. Эти отличия требуют ручной настройки процесса компиляции и установки данных файлов.
В рамках примера переводы располагаются в каталоге settings-translations, в котором указана следующая конфигурация процесса сборки в .pro-файле:
TEMPLATE = aux
TRANSLATIONS = vpnprovider-vpn-plugin.ts \ # Default translation
vpnprovider-vpn-plugin-ru.ts \
vpnprovider-vpn-plugin-en_US.ts
for(t, TRANSLATIONS) {
TRANSLATIONS_IN += $${_PRO_FILE_PWD_}/$$t
}
qm.files = $$replace(TRANSLATIONS_IN, \.ts, .qm)
qm.path = /usr/lib/qt5/qml/ru/omprussia/vpnprovider/translations
qm.CONFIG += no_check_exist
qm.commands += lupdate -no-obsolete -locations none $$PWD/.. -ts $$TRANSLATIONS_IN \
&& lrelease -idbased $$TRANSLATIONS_IN
QMAKE_EXTRA_TARGETS += qm
INSTALLS += qm
PRE_TARGETDEPS += qm
QMAKE_CLEAN += "$$PWD/*.qm"
При адаптации данной конфигурации необходимо изменить название файлов-переводов в соответствии с названием приложения. Это название также необходимо учитывать в переводчике. Также необходимо изменить место установки .qm-файлов. Они должны устанавливаться в каталог QML-плагина.
Дополнительных изменений в .spec-файл не нужно, так как конфигурация, добавленная на этапе работы над QML-плагином включает в себя все файлы из соответствующего данному плагину каталога.
При выполнении локализации проекта рекомендуется использовать уникальные идентификаторы строк.
Для выполнения этой задачи необходимо использовать функцию
qsTrId()
с передачей ей уникального идентификатора строки.
Идентификаторы строк должны быть уникальными в рамках всей системы ОС Аврора. Для достижения этой задачи рекомендуется использовать название плагина в качестве префикса для данных строк. Пример использования префикса можно посмотреть на странице редактирования подключения TrifleVpn.
Проект расширения приложения «Настройки»
QML-документы для расширения приложения «Настройки» располагаются в каталоге settings-controls. В данном каталоге следует создать подкаталог с названием провайдера, который будет поставляться. Данное название должно быть уникальным и не совпадать ни с одним стандартным каталогом провайдера. В рамках примера будем использовать имя vpnprovider.
Каталог расширения после установки RPM-пакета должен располагаться в каталоге /usr/share/sailfish-vpn. Для этого необходимо сформировать соответствующий .pro-файл:
TEMPLATE = aux
QT -= gui
OTHER_FILES += \
vpnprovider/*.qml \
settings_files.files = vpnprovider
settings_files.path = /usr/share/sailfish-vpn/
INSTALLS += settings_files
При его адаптации необходимо изменить название каталога в переменных
OTHER_FILES и settings_files.
Данные файлы также необходимо добавить в RPM-файл,
добавив следующие строки в секцию %files .spec-файла:
%{_datadir}/sailfish-vpn/*
В каталоге должны находится QML-документы расширения. В настоящий момент поддерживаются следующие документы:
- advanced.qml — вызывается при вызове расширенных настроек соединения;
- details.qml — вызывается при просмотре параметров соединения;
- edit.qml — вызывается при редактировании настроек соединения;
- listitem.qml — элемент списка доступных плагинов VPN, динамически подгружающийся в системное меню при создании нового подключения.
Для реализации этих документов следует использовать QML-компоненты Sailfish.Settings.Networking.Vpn. Эти компоненты были специально разработаны для быстрого создания редакторов профилей VPN-соединений.
Поддержка нескольких выпусков ОС Аврора
QML-компоненты Sailfish.Settings.Networking.Vpn являются специфичными для конкретного выпуска ОС Аврора, т.е. между значимыми выпусками ОС публичный интерфейс данных компонентов может отличаться.
Для поддержки разных версий QML-компонентов в рамках одной кодовой базы необходимо усложнить структуру файлов расширения приложения «Настройки»: для каждого поддерживаемого выпуска создать отдельный каталог, в котором разместить QML-файлы соответствующей версии. Логика по выбору подходящего набора файлов размещается в конфигурации сборочной системы.
Предположим, что имеются QML-компоненты для поддержки третьей и четвёртой версии ОС Аврора. Для каждой версии требуется создать отдельный каталог:
settings-controls
├── aurora_3
│ └── vpnprovider
│ ├── advanced.qml
│ ├── details.qml
│ ├── edit.qml
│ └── listitem.qml
├── aurora_4
│ └── vpnprovider
│ ├── advanced.qml
│ ├── details.qml
│ ├── edit.qml
│ └── listitem.qml
└── settings-controls.pro
Для выбора нужного каталога в зависимости от версии в .pro-файл необходимо добавить определение версии ОС в рамках процесса сборки:
OTHER_FILES += \
aurora_3/vpnprovider/*.qml \
aurora_4/vpnprovider/*.qml
OSVERSION = $$system(cat /etc/issue | cut -d\' \' -f2)
VERSIONS = $$split(OSVERSION, ".")
VERSION_MAJ = $$member(VERSIONS, 0)
lessThan(VERSION_MAJ, 4) {
settings_files.files = aurora_3/vpnprovider
settings_files.path = /usr/share/sailfish-vpn/
} else {
settings_files.files = aurora_4/vpnprovider
settings_files.path = /usr/share/sailfish-vpn/
}
INSTALLS += settings_files
Если необходимо определить более точное деление между версиями,
то следует брать второй элемент из массива VERSIONS.
Для каждого поддерживаемого выпуска ОС будет необходимо поставлять отдельные RPM-файлы.
Реализация документа для списка типов подключений listitem.qml
Данный документ используется для отображения позиции в списке типов подключений, которые доступны пользователю для создания новых профилей. Он должен предоставлять название VPN-провайдера и его краткое описание.
Корневым элементом данного документа должен стать тип
VpnTypeItem.
Этому элементу необходимо указать свойства:
name— наименование VPN-провайдера.description— расширенное описание провайдера.
Для версии ОС Аврора 4:
canImport— поддерживается ли импорт профилей. Данное свойство рекомендуется в значениеfalse, так как отсутствует публичное API для прямого редактирования параметров профиля VPN-подключения.
Для версии ОС Аврора 3:
vpnType— идентификатор VPN-плагина. Он должен совпадать с типом VPN-плагина для ConnMan.
Реализация документа для редактирования профиля подключений edit.qml
Данный документ используется для формирования параметров VPN-профиля как в момент создания,
так и в случае редактирования.
Корневым элементом данного документа должен быть
VpnPlatformEditDialog.
Данному компоненту необходимо установить следующие свойства:
vpnType— тип VPN-подключения. Он должен совпадать с типом VPN-плагина для ConnMan.
Для версии ОС Аврора 4:
newTitle— название для диалога, запущенного в режиме добавления нового VPN-профиля.editTitle— название для диалога, запущенного в режиме редактирования существующего VPN-профиля.
Для версии ОС Аврора 3:
title— название для диалога. Рекомендуется выставлять значение в зависимости свойстваnewConnection, которое будет равноtrueв случае запуска при создании нового подключения.
Внутри корневого элемента должны быть размещены другие элементы, которые позволяют редактировать параметры подключения. Можно использовать как обычные компоненты Silica, так и компоненты Sailfish.Settings.Networking.Vpn.
Например для редактирования имени пользователя можно воспользоваться компонентом
ConfigTextField:
ConfigTextField {
id: vpnproviderVpnUsername
//% "Username"
label: qsTrId("vpnprovider-user_name")
}
Для работы с параметрами VPN-профиля необходимо при создании компонента:
- Вызвать метод
init(). - Считать значения свойств профиля с помощью метода
getProviderProperty(name).
При успешном закрытии диалога, в обработчике сигнала accepted:
- Записать значения полей ввода в свойства профиля с помощью метода
updateProvider. - Сохранить новые параметры профиля с помощью метода
saveConnection().
Базовая структура обработки сообщений приведена ниже.
VpnPlatformEditDialog {
// ...
Component.onCompleted: {
init();
vpnproviderVpnUsername.text = getProviderProperty(vpnprovider.User');
}
onAccepted: {
updateProvider(vpnprovider.User', vpnproviderVpnUsername.text);
saveConnection();
}
}
Реализация документа для расширенного редактирования профиля подключений advanced.qml
Данный документ используется для редактирования расширенного списка свойств VPN-профиля.
Его корневым элементом должна быть колонка, Column.
Данная колонка должна занимать всё доступное по ширине пространство родительского элемента.
Родительским элементом выступает компонент
VpnAdvancedSettingsPage,
который предоставляет методы для записи параметров VPN-профиля.
Содержимым колонки должны быть элементы,
которые позволяют редактировать расширенный набор параметров VPN-профиля.
Данные параметры не должны пересекаться с параметрами на основной странице редактирования.
На странице можно использовать такие же компоненты, как и при реализации документа
edit.qml.
Компонент также должен предлагать публичные функции setProperties и
updateProperties.
Метод setProperties вызывается в момент показа данного компонента.
Его следует использовать для установления состояния графических компонентов редактора
на основании параметров VPN-профиля.
Для получения значения поля следует использовать метод
getProperty(name).
Метод updateProperties вызывается для сохранения значений полей ввода в свойства VPN-профиля.
Для выполнения этой задачи следует использовать метод
updateProvider.
В качестве примера рассмотрим страницу с одним дополнительным свойством логического типа.
Column {
function setProperties() {
vpnproviderAllowSelfSignedCert.checked = getProperty(
'vpnprovider.AllowSelfSignedCert') === 'true';
}
function updateProperties() {
updateProvider('vpnprovider.AllowSelfSignedCert',
vpnproviderAllowSelfSignedCert.checked ? 'true' : 'false');
}
TextSwitch {
id: vpnproviderAllowSelfSignedCert
objectName: "vpnproviderAllowSelfSignedCert"
//% "Allow self signed certificate"
text: qsTrId("vpnprovider-allow_self_signed_certificate")
}
}
Реализация документа для просмотра параметров подключения details.qml
Данный документ используется для отображения информации о подключении.
Его корневым элементом должна быть страница
VpnPlatformsDetailsPage.
Этому компоненту необходимо указать значение свойства subtitle,
в котором расположить наименование VPN-провайдера.
Данная страница самостоятельно отобразит все свойства, которые были записаны в VPN-профиль во время его редактирования.
Расширение с использованием внешнего менеджера конфигураций
В рамках данной схемы расширения необходимо реализовать те же компоненты, что и в рамках первой схемы, но также придётся реализовать приложение — менеджер конфигураций и организовать взаимодействие между ним и расширением приложения «Настройки».
Схемы взаимодействия компонентов расширения
Рассмотрим схему, при которой менеджер конфигураций формирует параметры подключения в собственном формате VPN-клиента. Данных конфигурационных файлов должно быть достаточно для установления VPN-подключения. При таком подходе в рамках VPN-профиля будет храниться минимальный набор данных для работы VPN-плагина.
Данная схема по распределению обязанностей между компонентами обладает следующими преимуществами:
- Не надо реализовывать схему синхронизации параметров соединения между менеджером конфигурации и приложением «Настройки».
- Объём данных внутри VPN-профиля минимальный, что облегчает реализацию расширения внутри приложения «Настройки» и ConnMan-плагина.
Существенным минусом такого подхода является то, что пользователь может удалить конфигурацию внутри менеджера конфигурации, но не исправить соответствующий ей VPN-профиль.
Альтернативной схемой является передача всех параметров подключения в VPN-профиль. Преимуществом данной схемы является самодостаточность VPN-профиля, однако помимо проблемы удаления появляется также проблема синхронизации содержимого конфигурации и VPN-профиля.
Сценарий выполнения VPN-подключения
- Пользователь формирует конфигурацию VPN-подключения внутри менеджера конфигураций через его графический пользовательский интерфейс.
- Пользователь открывает приложение «Настройки» и формирует VPN-профиль подключения для нужного VPN-провайдера.
- В момент формирования VPN-профиля пользователь нажимает кнопку выбора внешней конфигурации VPN-подключения.
- Приложение «Настройки» запрашивает у менеджера конфигураций VPN-профиль путём отправки D-Bus запроса в менеджер конфигураций.
- При получении запроса менеджер конфигураций отображает диалог для выбора конфигурации из списка сформированных конфигураций.
- Пользователь выбирает нужную VPN-конфигурацию и подтверждает свой выбор в диалоге.
- Система отображает VPN-профиль с заполненным полем внешней конфигурации.
- Пользователь заполняет дополнительные поля, которые необходимы для полноценного формирования VPN-профиля, параметры VPN-плагина ConnMan. Пользователь завершает формирование VPN-профиля.
- Пользователь инициирует подключение согласно сформированному VPN-профилю.
- VPN-плагин ConnMan использует полученные параметры: запрашивает имя пользователя и пароль, одноразовый пароль, если это необходимо. Затем передаёт путь к VPN-конфигурации и дополнительные параметры VPN-клиенту.
В рамках данного сценария конфигурации подключения хранятся в домашней директории пользователя. Если в рамках VPN-профиля хранится путь к данной конфигурации, то необходимо удостоверится, что VPN-клиенту указанные файлы будут доступны на чтение в момент исполнения.
Реализация D-Bus сервиса менеджера конфигураций
В основе взаимодействия между приложениями «Настройки» и менеджером конфигураций лежит обмен сообщениями с помощью D-Bus. Менеджер конфигураций должен предоставлять службу для получения пути к VPN-конфигурации, а приложение «Настройки» будет обращаться к данной службе. Детали реализации такого рода взаимодействия в рамках приложений под ОС Аврора можно найти в соответствующем разделе документации. В рамках данного раздела рассмотрим ключевые детали реализации такого взаимодействия.
Сначала необходимо спроектировать интерфейс службы:
- определить название интерфейса;
- выбрать название метода для вызова менеджера конфигурации для получения VPN-конфигурации;
- сформировать набор данных, которые должны быть возвращены данным методом.
Название интерфейса должно быть уникальным в рамках платформы, рекомендуется использовать доменное имя организации вместе с названием приложения, например ru.omp.VpnProviderConfigurator.
Следующий этап — реализовать D-Bus-службу в рамках менеджера конфигураций. При старте менеджера конфигураций служба должна регистрироваться на сессионной шине D-Bus и ожидать входящих запросов от приложения «Настройки». Для реализации службы можно воспользоваться как QML-типом QDBusAdaptor, так и решением на уровне C++.
По умолчанию служба будет доступна исключительно в случае, когда приложение активно.
Для обеспечения поддержки запуска приложения при обращении к D-Bus-службе
необходимо разместить её описание в каталоге
$XDG_DATA_HOME/dbus-1/services.
Таким образом при поступлении запроса к описанной службе будет произведён запуск приложения.
Приложение должно размещать конфигурационный файл D-Bus-службы при первом старте.
Пример такой конфигурации приведён ниже:
[D-BUS Service]
Name=ru.omp.vpnprovider-configurator
Exec=/usr/bin/vpnprovider-configurator --select-configuration
Для разделения ситуации запуска из системы D-Bus и из списка приложений приложению передаётся
дополнительный аргумент.
В случае примера — это --select-configuration.
В рамках .desktop-файла данный аргумент приложению не передаётся.
В зависимости от наличия данного аргумента
менеджер конфигураций будет запускаться либо в режиме редактора, либо в режиме выбора.
Вызов менеджера конфигураций из страницы редактирования VPN-профиля
Для доступа к D-Bus-службе со стороны расширения приложения «Настройки» можно разместить
как в QML-плагине (реализовать взаимодействие на уровне языка C++),
так и на уровне QML-расширения (реализовать взаимодействие с помощью QML) с использованием типа
QDbusInterface.
Рассмотрим процесс реализации данной логики внутри QML-плагина. Для решения задачи потребуется описать новый QML-компонент, который будет предоставлять метод для получения информации от D-Bus-службы и два сигнала для обработки успешной и ошибочной ситуации при получении данных.
Данный QML-компонент необходимо создать на экране редактирования подключения edit.qml. На экране редактирования также потребуется разместить кнопку, по нажатию на которую необходимо вызвать метод для получения пути к конфигурации. Также в рамках обработки нажатия рекомендуется заблокировать кнопку, чтобы исключить повторное нажатие.
В рамках обработки успешного сигнала о получении конфигурации необходимо сохранить путь к конфигурационному файлу в соответствующий параметр VPN-профиля, отобразить название файла в соответствующем текстовом поле на странице редактирования подключения. В случае неудачного соединения необходимо отобразить соответствующее ошибке сообщение пользователю, чтобы он смог попытаться решить данную ситуацию. При получении любого из сигналов кнопку необходимо разблокировать.
VpnPlatformEditDialog {
property string vpnConfigurationData
function basename(str) {
return (str.slice(str.lastIndexOf("/")+1))
}
Connections {
target: vpnproviderConfiguratorAdaptor
onConfigurationReceived: {
vpnConfigurationData = config
vpnproviderConfig.enabled = true
}
}
VpnproviderConfiguratorAdaptor {
id: vpnproviderConfiguratorAdaptor
objectName: "vpnproviderConfiguratorAdaptor"
}
ValueButton {
id: vpnproviderConfig
objectName: "configValueButton"
//% "Select"
label: qsTrId("vpnprovider-config_button")
value: basename(vpnConfigurationData)
onClicked: {
vpnproviderConfig.enabled = false
vpnproviderConfiguratorAdaptor.getConfigurationData()
}
}
}