Универсальный GUI

Здравствуйте! Меня зовут Халитов Кирилл, я аспирант из МГУДТ (Московский государственный университет дизайна и технологии (МГУДТ) ). В моей диссертации возникла задача упростить процесс создания интерфейса для локального и веб-приложения и в итоге получился сабж.

Введение


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

Кроме того, в связи с бурным распространением интернета популярным направлением разработки ПО стала разработка веб-приложений или веб-сервисов. Веб-приложение является полезным дополнением к клиентской прикладной программе (приложению). Обычно веб-приложение даёт возможность удалённого использования мониторинговой системы. Это означает, что пользователь не привязан к месту расположения аппаратной части мониторинговой системы и может использовать её из любой точки мира, где есть рекомендуемое интернет-соединение. Важно заметить, что разработка веб-приложений в значительной степени отличается от разработки клиентских приложений и это в свою очередь создаёт некоторые проблемы. В частности, это проблема создания универсального графического интерфейса пользователя (GUI). Чтобы клиентское приложение и веб-приложение были реализованы в едином графическом стиле, необходимо приложить достаточно усилий как разработчику интерфейса клиентского приложения, так и разработчику интерфейса веб-приложения. В конечном счёте величина усилий одного или другого разработчика будет зависеть от того, интерфейс какого приложения будет задавать общий стиль.

Современные способы построения интерфейсов


Рассмотрим наиболее популярные в настоящий момент способы построения интерфейсов клиентских приложений на языке C++, как наиболее используемом для разработки ПО, для ОС Microsoft Windows (MS Windows) и ОС Linux. Главным средством разработки ПО для MS Windows является MS Visual Studio [1]. Эта интегрированная среда разработки (IDE) позволяет разрабатывать ПО на разных языках программирования, но основными языками, конечно, являются C++ и C#. Для разработки интерфейса приложения имеются два основных средства — Windows Forms (WinForms) и Windows Presentation Foundation (WPF). Большая часть существующих приложений для MS Windows разработана с использованием WinForms, однако с появлением более современных версий ОС (MS Windows 7, 8), система WPF становится более популярной. Кроме того, последние версии MS Visual Studio позволяют использовать язык разметки HTML5 для построения интерфейсов, близких по стилю к нативным веб-приложениям. Однако стоит заметить, что коммерческая лицензия MS Visual Studio является платной, как и лицензия MS Windows, что несомненно является недостатком для низкобюджетных проектах.

Если говорить о низкобюджетных проектах, то тут наиболее подходящим вариантом является ОС Linux. Помимо того, что большинство дистрибутивов этой ОС являются абсолютно бесплатными, в том числе и для коммерческого использования, также имеется ряд бесплатных средств для разработки качественного ПО для ОС Linux. Самым распространённым средством для разработки ПО на языке С++ является кроссплатформенный инструментарий Qt [2]. Важно подчеркнуть, что Qt позволяет разрабатывать приложения не только для ОС Linux, но и для MS Windows, Mac OS X, Android и других UNIX-подобных ОС. Разработчики Qt предлагают как бесплатную для коммерческого использования, так и платную лицензию с дополнительными возможностями. Но исходя из современной практики разработки ПО с помощью этого инструментария, бесплатной лицензии оказывается больше чем достаточно.

Если проводить аналогию с MS Visual Studio, то в Qt мы имеем IDE Qt Creator. Здесь альтернативой WinForms являются так называемые виджеты (Qt Widgets), а альтернатива для WPF — Qt Quick. Также в Qt Creator имеется возможность создания интерфейсов на основе HTML5. Но наиболее интересным модулем инструментария является встраиваемый веб-движок WebKit, который лежит в основе всех современных веб-браузеров. Подобный модуль имеется и в MS Visual Studio, но он имеет ряд ограничений, и тем более нас больше интересуют низкобюджетные средства, которые позволяют уменьшить издержки при создания программного продукта. Веб-движок — это ядро браузера, он отвечает за правильное отображения веб-страниц. Модуль Qt WebKit позволяет создавать интерфейс клиентского приложения с использованием техники разработки интерфейсов веб-приложений. В основе создания интерфейса веб-приложения лежит устоявшийся стек технологий. Он включает язык разметки HTML (HTML 4, 5), каскадные таблицы стилей (CSS 2, 3) и скриптовый язык JavaScript с богатым выбором дополнительных библиотек (каркасов). Отдельного внимания заслуживает тот факт, что скорость появления новых полезных каркасов для языка JavaScript стремительно растёт, а это делает разработку, насыщенных функционалом приложений, более быстрой и удобной.

Теперь решение проблемы создания универсального GUI лежит на поверхности, но это только на первый взгляд.

Традиционный способ: Qt WebKit + Qt-костыли


Рассмотрим традиционный способ создания универсального GUI с помощью модуля Qt WebKit на примере модуля визуализации данных системы акустического мониторинга, разрабатываемой в рамках кандидатской диссертационной работы [3]. Под системой акустического мониторинга подразумевается система, включающая аппаратную и программную части. Аппаратная часть системы состоит из сенсорной сети акустических датчиков, данные с которых обрабатываются на микроконтроллере и отправляются по какому-либо интерфейсу (UART, IEEE 802.X и др.) на персональный компьютер (ПК). Программная часть состоит из набора прикладных программ, работающих как на локальном ПК (клиентское ПО), так и на удалённом сервере (серверное ПО).

Традиционный метод подразумевает использование межпроцессного


Рис. 1. Традиционный метод реализации универсального GUI

взаимодействия по средствам встроенного механизма Qt. Здесь подразумевается взаимодействие между основной логикой клиентского приложения, изображённой на рис.1 как Обработчик данных, и GUI-элементом. Одним из недостатков такого подхода является то, что код для реализации GUI на языке JavaScript будет иметь специфические функции, которые будут актуальны только для клиентского Qt-приложения. Для серверного приложения, отвечающего за GUI, нужен будет другой, специфичный для серверной реализации, код. Например, в случае использования PHP-скрипта для реализации основной логики серверного приложения, понадобится реализация межпроцессного взаимодействия с помощью какой-либо другой технологии (AJAX или WebSocket). Отсюда следует ещё один недостаток, а именно использование дополнительного языка программирования для реализации основной логики серверного приложения и разработка нового алгоритма межпроцессного взаимодействия.

Более интересный подход: Qt WebKit + WebSocket


Для решения этих проблем предлагается новый метод, основанный на использования упомянутой выше технологии WebSocket. Суть метода заключается в том, чтобы унифицировать метод межпроцессного взаимодействия между основной логикой приложения и GUI, как на клиентской стороне, так и на серверной. В этом случае появляется возможность использования JavaScript кода для реализации универсального для обеих сторон GUI.


Рис. 2. Новый метод реализации универсального GUI

На рис. 2. видно, что теперь для межпроцессного взаимодействия, как для клиентской, так и для серверной части используется технология WebSocket. То есть теперь мы имеем один универсальный JavaScript код для разных приложений. В этом случае необходимым условием является серверное приложение, основная логика которого реализована с помощью Qt, на не совсем привычном для веб-разработчиков, языке C++. С одной стороны такой подход к реализации серверного приложения усложняет задачу для узкоспециализированного веб-разработчика. Но с другой стороны мы имеем универсальные части кода, которые позволяют нам сэкономить время на дублировании одних и тех по смыслу алгоритмов на разных языках. Важно также подчеркнуть, что для использования технологии WebSocket необходима дополнительная библиотека, которая имеется в интернете в свободном доступе или включается по умолчанию в более поздние версии Qt.


Рис. 3. Локальное (справа) и серверное (слева) приложения, запущенные на ОС Ubuntu 14.04

На рис. 3 приведён пример реализации нового метода создания универсального GUI для ОС Ubuntu 14.04. Как видно на рисунке, в конечном итоге мы получаем универсальный интерфейс, как для локального приложения, запущенного в качестве исполняемого файла ОС, так и для серверного приложения, запущенного в современном веб-браузере. Так как для разработки ПО используются кроссплатформенные инструменты, это позволяет говорить о простой переносимости программного продукта на другие ОС в будущем.

Список литературы


1. Qt Documentation [Электронный ресурс]. Режим доступа: qt-project.org/doc
2. Visual Studio Library [Электронный ресурс]. Режим доступа: msdn.microsoft.com/en-us/library/vstudio
3. Молодые учёные – развитию текстильно-промышленного кластера (ПОИСК — 2014): сборник материалов межвузовской научно-технической конференции аспирантов и студентов с международным участием. Ч. 2. – Иваново: Иванов. гос. политехн. Ун-т, 2014. — С. 25 [Электронный ресурс]. Режим доступа: ti.ivgpu.com/poisk/file/part_2.pdf

P.S. Единственное, что на картинке бросается в глаза — это разные шрифты, но мне, честно говоря, тогда было не до них.

P.P.S. Можно ли запатентовать этот способ, чтобы на защите было чем козырнуть кроме свидетельства о регистрации ПО?
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 11

    0
    >P.P.S. Можно ли запатентовать этот способ, чтобы на защите было чем козырнуть кроме свидетельства о регистрации ПО?
    Уже нет. Патентовать можно только неопубликованные технологии.

    Скажите, пожалуйста, в чем разница с фреймворками www.webtoolkit.eu/wt или qtwui.sourceforge.net/ (qtwui я только нагуглил и на практике его не видел)?
      +1
      P.P.S. Можно ли запатентовать этот способ, чтобы на защите было чем козырнуть кроме свидетельства о регистрации ПО?
      Какой способ? В статье показан самый стандартный подход, разве что был смысл использовать QtQuick вместо WebKit, то есть по сути вы собираетесь патентовать вашу лень. Я так в своём курсаче через WebKit встроил редактор с подсветкой кода Ace ибо на QtQuick пока никто не сделал редактор с автодополнением и выбора у меня просто не было.

      P.S. en.wikipedia.org/wiki/Model_View_ViewModel
        0
        Вообще не вижу смысла использовать QtQuick, ведь весь интерфейс можно сделать на проверенных frontend веб-технологиях в widget-версии WebKit.
        Радует, что в Qt 5.3 добавили модуль QWebSocket и теперь не придётся использовать libwebsockets.

        Может быть, если пишешь чисто desktop-версию приложения с web-based интерфейсом, то и целесообразней использовать qt-мосты, но если хочется чего-то универсального и для desktop и для web, то лучше, мне кажется, использовать описанный мной подход с использованием WebSocket.
          0
          Обращаться к элементам документа в WebKit можно и без сокетов, напрямую дёргая нужные функции используя QtWebKit.experimental, хотя это справедливо для QML, в виджетах не смотрел.

          Что касаемо архитектуры приложения как таковой, ничего не мешало вам сделать так (где GUI это либо обычный браузер, либо хитрый, то есть окошко без кнопок):
          image

          Но тогда бы на вас просто косо смотрели, так как во-первых это стандартный путь, а во-вторых писать на Qt серверную часть смысла нет, так как хайлоада здесь не ожидается, а нужные либы, которых нет в Ruby/Python/Go/Node.js/etc, можно зацепить парой лишних строк. Разве что любовь к C++ вынудила вас писать так сервер. Но тогда Qt никак не приклеить к данной работе.
            0
            Конечно можно без сокетов, но мне этот вариант не подходил, так как я не хотел писать разный js-код для desktop- и web-приложений.

            Да, по вашей схеме нужен сервак на плюсах (что только усложняет мою задачу), а в моём варианте я использую только веб-сокет сервер(с приёмом данных по udp) на плюсах, а в качестве основного сервера я просто использую существующий apache.

            Вообще, главной задачей было сделать двустороннюю связь сенсорной сетью. Это я сделал.

            В будущем хочу связать сенсорную сеть напрямую с веб-сокет сервером по udp.
              0
              Я думал вообще избавится от qtwebkit и использовать cef, но я пока всё-таки хочу работать в одной инфраструктуре qt.
        +1
        К, сожалению, идея не нова. Какой транспорт использовать и как приложения писать… Веб технологии стремительно пытается занять ту нишу, где раньше были native виджеты. В похожем направлении движется и firefox os
          0
          Идея не нова, но я таких примеров не нашёл, когда искал способ построения универсального интерфейса.
          0
          А в CUBA.Platform есть технология, которая для одного и того же кода на Java позволяет скомпилировать Desktop и Web приложения. Причём обращения к среднему слою скрыты за вызовами сервисов и на вид ничем не отличаются от локальных вызовов. Очень советую посмотреть.
          • UFO just landed and posted this here
              –2
              Значит подход вполне себе ничего.

            Only users with full accounts can post comments. Log in, please.