Как написать графический интерфейс для большого кроссплатформенного проекта C ++?

Question

У меня большой кроссплатформенный (C ++ и Linux) проект C ++, для которого я хочу создать графический интерфейс.

У меня есть несколько очень общих вопросов об основных принципах GUI для такого проекта:

1. Следует ли отделять графический интерфейс от логики приложения?
2. Если он разделен, как должны взаимодействовать логика и графический интерфейс? Являются ли сокеты TCP / IP хорошим вариантом? Каковы другие возможности?
3. Хорошо ли иметь графический интерфейс на языке, отличном от C ++? Если да - на каком языке?
4. Это хорошая идея иметь графический интерфейс на основе браузера?
5. Несмотря на то, что основная логика проекта является кроссплатформенной, я могу решить, что графический интерфейс будет только на основе Windows (.NET?), И он будет взаимодействовать с логикой на соответствующей машине Win / Linux через Socket или аналогичный метод. , Это хорошая идея?

Answer 1

1. Следует ли отделить графический интерфейс от логики приложения?

   Да, определенно ....

2. Если он разделен, как должны взаимодействовать логика и графический интерфейс? Являются ли сокеты TCP / IP хорошим вариантом? Каковы другие возможности?

   ... но не это много. Сокеты будут излишними (исключение: см. Вопрос 5). Обычно вы разделяете классы на GUI и бэкэнд-части. Классы GUI затем вызывают методы бэкэнда.

3. Хорошо ли иметь графический интерфейс на языке, отличном от C ++? Если да - на каком языке?

   Если это так, вам придется интегрировать два языка, поэтому я бы рекомендовал писать все на одном языке. Но чтобы ответить на ваш вопрос, вы могли бы, например, создать привязки Python для своего бэкенда и написать GUI на Python (с PyGTK, PyQT или wxWidgets).

4. Является ли хорошей идеей иметь графический интерфейс на основе браузера?

   Это зависит от того, как вы хотите развернуть свое приложение. Если он должен быть установлен на каждом клиентском компьютере, веб-интерфейс не имеет смысла. Если вы хотите разместить его централизованно, вы можете выбрать веб-интерфейс.

5. Несмотря на то, что основная логика проекта кроссплатформенная, я могу решить, что графический интерфейс будет только на основе Windows (.NET?), И он будет взаимодействовать с логикой на соответствующей машине Win / Linux через Socket или похожий метод. Это хорошая идея?

   Я думаю, что это имеет смысл , только если серверная часть должна быть какой-то защищенной (то есть не должна быть установлена ​​на компьютерах пользователей) или если у вас есть подход, подобный тонкому клиенту, как в вопросе 4 Написание кроссплатформенных графических интерфейсов гораздо проще, чем написание кроссплатформенных бэкэндов (на мой взгляд), поэтому вы должны делать обе части кроссплатформенными. Кстати, графические интерфейсы на основе .NET не только для Windows - Mono уже поддерживает, например, большое подмножество Windows Forms (но, к сожалению, не WPF).

EDIT:

По поводу вашего вопроса Mono: Mono в основном стабилен, но еще не все реализовано. Чтобы быть уверенным, вы можете запустить Mono Migration Analyzer (MoMA) , чтобы выяснить, не будет ли что-то работать в Mono. Но я думаю, что тот факт, что так много компаний успешно используют Mono в производственных средах, означает, что вы должны хотя бы рассмотреть Mono как вариант!

Answer 2

(1) Обычно да, это позволяет поддерживать бизнес-логику и пользовательский интерфейс отдельно. Это также позволяет позже иметь, например, как пользовательский интерфейс SaaS на основе браузера, так и режим локальной сети в стиле рабочего стола, и при этом общий логический код приложения.

(2) Не использовать сокеты TCP / IP. Обычно приложение и графический интерфейс взаимодействуют друг с другом, используя передачу событий и / или сообщений. Например, когда приложение хочет уведомить GUI о том, что что-то происходит, оно создает синтетическое событие, которое затем помещается в очередь событий GUI. Если приложение также основано на событиях, графический интерфейс пользователя может связываться с ним, публикуя события. Для неблокирующих, быстрых операций GUI может напрямую вызывать логический код приложения, но тогда должен быть гарантирован быстрый возврат вызова. Для более медленных операций вам все равно нужен отдельный поток для их обработки. Этот поток может быть тем, который обрабатывает события на стороне приложения, или вы можете порождать его как рабочий поток при необходимости.

Продукт нашей компании имеет пользовательский интерфейс поверх Eclipse IDE, но часть логики приложения написана на C ++. Эти две части взаимодействуют через CORBA, то есть в основном с механизмом асинхронных событий. Мы были довольны этим решением.

В меньшем масштабе приложения с графическим интерфейсом обычно разделяют пользовательский интерфейс и логику приложения, используя абстракции, такие как Model-View-Controller (MVC).

(3) Всегда сложно интегрировать компоненты, написанные в двух разных компонентах. Я думаю, что вы должны это делать, только если у вас есть очевидное преимущество для платформы. Например. мы получаем выгоду от компонентов Eclipse IDE, тогда как приложение получает выгоду от простой скорости C ++.

(4) Основанные на браузере графические интерфейсы великолепны, но интеграция с бизнес-логикой страдает задержкой, а режим веб-серверов без сохранения состояния делает архитектуру громоздкой, если у вас действительно есть приложение в стиле настольного компьютера. Графический интерфейс на основе браузера хорош для приложений «программное обеспечение как услуга», потому что они не требуют установки пользователем и могут быть обновлены разработчиком продукта по желанию, но если вы не планируете предлагать свой продукт как продукт программного обеспечения как услуга (например, Salesforce).

(5) Если логика вашего приложения кроссплатформенная, я бы попытался сделать кроссплатформенный интерфейс. В противном случае для тех платформ, где вы поддерживаете только логику приложения, вам может потребоваться установить две операционные системы: одну для запуска пользовательского интерфейса и одну для запуска логики приложения. Есть хорошие кроссплатформенные фреймворки пользовательского интерфейса, по крайней мере

• AJAX / пользовательский интерфейс на основе браузера
• Trolltech / Nokia Qt
• Затмение (SWT)
• Java Swing (хмм ...)

Answer 3

Следует ли отделять графический интерфейс от логики приложения?

Должно быть, потому что виджеты пользовательского интерфейса - это просто типы объектов, и одно из правил ОО гласит, что каждый объект должен быть доверен с обязанностями, которые он может выполнить. Диалог не знает много о сериализация например.

Если он разделен, как должны взаимодействовать логика и графический интерфейс? Являются TCP / IP розетки хороший вариант? Что другие возможности?

Это зависит от того, сколько разлуки вам нужно. Я использую асинхронные сообщения для общения, а затем я могу использовать разные транспортные уровни без особых изменений. TCP / IP позволил бы вам использовать графический интерфейс на отдельной машине от ядра, но он имеет более высокие издержки, чем например, передача сообщений в окнах.

Это хорошая идея, чтобы графический интерфейс язык отличается от C ++? Если да - какой язык?

В идеале вы должны использовать как можно меньше языков, если вам не нужны технические возможности определенный язык. GUI - это больше проблема с библиотекой, чем с языком, так что если вы можете найти очень хороший Библиотека пользовательского интерфейса C ++ (подсказка: Qt), вы должны закодировать всю свою программу на C ++.

Это хорошая идея иметь GUI на основе браузера?

Может быть, но вы должны думать о требованиях, а не об идеях. Ваши клиенты хотят взаимодействовать с ваша программа из браузера? Могут ли они позволить себе дополнительные расходы и время разработки? У вас есть ноу-хау?

Хотя основная логика проекта является кроссплатформенным, я могу решить, что GUI будет только на базе Windows (.NET?) И он будет общаться с логика на соответствующем Win / Linux машина через сокет или подобное метод. Это хорошая идея?

Это может быть хорошей идеей, но посмотрите ответ на # 3. Также учтите, что вы собираетесь работать с клиент-серверной программой, которая значительно сложнее, чем отдельная программа. Наконец, вам нужно изучить все плюсы и минусы зависимости .NET по сравнению с использованием библиотеки пользовательского интерфейса C ++: что дает вам .NET, чего нельзя получить с помощью wxWdigets, Qt, gtkmm и т. Д.

Answer 4

Я согласен с комментаторами, которые сказали «недостаточно информации», но в зависимости от ваших потребностей вы должны уделить МНОГО внимания интерфейсу веб-браузера.

Если потоковые данные в реальном времени и мгновенное удовлетворение интерактивности не важны, веб-интерфейс может быть довольно простым, без AJAX и просто тривиальным CGI на основе форм и динамически генерируемым HTML. Имейте в виду ту часть, которая существует, когда браузер обновляется для вас за счет денег других людей, а также любых изменений в Windows, Linux, Mac или других системах.

Ваши пользователи уже находят это знакомым. Вы можете найти программистов, чтобы сделать работу. Библиотеки уже существуют практически на всех основных языках, чтобы при необходимости встроить веб-сервер в приложение. Или вы можете запустить какой-нибудь централизованный сервер.

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

Некоторые люди могут сказать, что это не подходит для автономных версий приложения, но я говорю, что это хорошо для автономных версий, если вы добавляете некоторую защиту (запускайте встроенный веб-сервер, на который запросы принимаются только в том случае, если они поступают с локального компьютера). Жизнь пользователя можно упростить, запустив браузер из приложения или сообщив пользователю, куда идти в сообщении при запуске (URL http://localhost:7654 или что-то еще, а не их вечное назначение :-)).

Answer 5

Мой ответ очень общий, поскольку вы ничего не сказали о своем заявлении.

Следует ли отделять графический интерфейс от логики приложения?

В коде, безусловно. Запуск в отдельном процессе, возможно, на отдельной машине, также может быть хорошей идеей, но это действительно зависит от ваших требований.

Причины полностью отделить его:

• Запуск приложения в качестве демона или системной службы (в фоновом режиме), пока графический интерфейс не запущен
• Удаленное управление приложением по сети
• Возможность нескольких независимых реализаций GUI с использованием разных языков программирования (например, iPhone?)
• Поддержка автоматического управления (сценариев) без графического интерфейса
• Осуществить разделение позже, если это не было сделано изначально, практически невозможно

Причины, почему бы не отделить:

• Требуется сериализация всех операций ввода-вывода, что усложняет реализацию
• Незначительное снижение производительности при передаче очень больших объемов данных (это никак не влияет на типичное приложение с графическим интерфейсом)

Если он отделен, как должны взаимодействовать логика и графический интерфейс? Являются ли сокеты TCP / IP хорошим вариантом? Каковы другие возможности?

HTTP является популярным выбором и позволяет избежать большинства проблем с брандмауэрами и тому подобным. В C / C ++ вы можете использовать libcurl для запросов http / https и Boost.CGI (еще не принят к Boost) или одну из других библиотек CGI на стороне сервера.

Другие опции для IPC включают общую память (Boost.Interprocess), сокеты UNIX и другие сетевые протоколы. Однако я не рекомендовал бы их, если не передаются очень большие объемы данных.

Хорошо ли иметь графический интерфейс на языке, отличном от C ++? Если да - на каком языке?

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

Хорошо ли иметь графический интерфейс на основе браузера?

Определенно. Если то, что вам нужно, можно сделать с помощью HTML5 и JavaScript, даже не рассматривайте традиционный GUI, просто вместо этого сделайте его веб-приложением.

Преимущества:

• Полностью кроссплатформенный
• Нет установки программного обеспечения на компьютеры пользователей
• Все клиенты всегда используют последнюю версию GUI
• Платформы Web GUI на самом деле лучше работать, чем традиционные рамки GUI
• Нет необходимости выделять графический интерфейс в отдельный процесс
• Возможно использование из скриптов (например, с помощью программы curl из скрипта оболочки)

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

Несмотря на то, что основная логика проекта является кроссплатформенной, я могу решить, что графический интерфейс будет только на основе Windows (.NET?), И он будет взаимодействовать с логикой на соответствующей машине Win / Linux через Socket или подобный метод , Это хорошая идея?

API кроссплатформенных библиотек GUI несколько ужасны. В настоящее время Qt довольно неплохо выглядит, и его API довольно хорош, хотя и сильно влияет на ваше приложение. Попробуйте ограничить любое использование Qt строго графическим интерфейсом. Другой вариант для настоящего нативного кроссплатформенного графического интерфейса - это wxWidgets, который лучше интегрируется с другим кодом C ++, но имеет очень неприятный и подверженный ошибкам API.

Для веб-интерфейса вы должны рассмотреть Wt, высокоуровневую среду C ++ AJAX с интерфейсом, похожим на Qt, но использующим современные методы C ++ вместо того, чтобы захватывать ваше приложение, как это делает Qt.

• http://www.wxwidgets.org/
• http://www.webtoolkit.eu/wt

Answer 6

Если вам нужен хороший пример кроссплатформенного решения с графическим интерфейсом, которое свободно и хорошо написано, могу предложить вам посмотреть wxWidgets ( 1 )Я надеюсь, что это помогает

Answer 7

Некоторые пользователи уже дали несколько хороших ответов на ваши вопросы, поэтому я хочу дать вам несколько советов, как мне управлять своими проектами.

В: На какой ОС должно работать мое приложение?

Windows и Linux! -> Я бы использовал C ++ или Java

В: Важна ли скорость выполнения?

Да! (расчеты, графики, доступ к системным ресурсам ...) -> С точки зрения скорости C ++ часто быстрее (не всегда)

В: Требуется ли файл конфигурации?

A: Да! Я должен установить некоторые пользовательские и системные значения. -> Может сохранить конфигурацию в реестре, но так как мы также хотим использовать наше приложение на Linux, давайте использовать xml (rapidxml было бы хорошим решением для C ++)

В: Требуется ли база данных?

A: Да, у меня есть некоторая информация / расчеты, которые мне нужно сохранить (локальные / глобальные). -> Локальный: я бы использовал sqlite -> Если вам просто нужно сохранить сравнительно немного информации, пожалуйста, подумайте о более быстром способе хранения этой информации (xml?!)

В: Как мне структурировать свое приложение?

A: ВСЕГДА держите свой графический интерфейс отдельно от "логической" части -> Позволяет позже изменить код, и вы сможете использовать его и для других проектов. + уже упомянутые причины.

В: Как мне структурировать мой графический интерфейс?

A: Подумайте, для чего должно использоваться ваше приложение и что должны делать пользователи. Ах, и, пожалуйста, не создавайте слишком глубокую иерархию, которая означает, что пользователю не нужно открывать 10 окон, чтобы открыть окно, которое они хотят иметь. То же самое касается вашего кода, это не мудрое решение иметь слишком много объектов, которые создают новый объект.

object->object->object->object->object->object->object->object

В: Должно ли мое приложение взаимодействовать с приложением сервера?

A: Да? Вам придется использовать сокеты! Но имейте в виду, что связь через сокеты не очень быстрая и безопасная, поэтому не используйте их, если вам не нужно.

В: Я не уверен, как начать (мы группа разработчиков)

A: Когда я начинаю новый проект, я думаю обо всех этих моментах (возможно, о некоторых других) + Чтобы увидеть, какие классы и методы мне нужны, я начинаю с создания UML-диаграммы, которая поможет мне понять, где Я должен начать, и диаграмма также поможет мне отслеживать мои классы и методы и как они связаны друг с другом. UML-диаграмма также поможет вашим партнерам или клиентам понять, как будет структурировано ваше приложение.

Для больших проектов я бы использовал C ++ & wxWidgits или, может быть, Qt. (Только моя точка зрения)

Rgds Лэйн

Answer 8

1. Должен ли графический интерфейс быть отделен от логики приложения?

Да. Тем не менее, см. Ответ № 2

2. Если он разделен, как должны взаимодействовать логика и графический интерфейс? Являются ли сокеты TCP / IP хорошим вариантом? Каковы другие возможности?

Я считаю, что на этот вопрос лучше всего ответить, выбрав среду графического интерфейса, MFC, .NET, wxWidgets, Qt,…. Платформа, которую вы выберете, будет безболезненно заботиться как об отделении, так и об общении.

Не пытайтесь заново изобрести колесо. Разработчики фреймворков вложили в свои реализации гораздо больше идей и испытаний, чем вы когда-либо могли себе позволить.

Обратите внимание, что вопрос № 1 предполагает, что вы спрашиваете об отделении логики в одном приложении. Однако более поздние вопросы предполагают, что вы можете подумать о двух отдельных приложениях, возможно, даже работающих на разных машинах.

Я считаю, что использование графического интерфейса в совершенно отдельном приложении всегда приводит к чему-то медленному и негибкому. Однако, если вам не нужны скорость и гибкость, особенно если у вас уже есть базовое приложение, работающее с простым интерфейсом консольного типа, это может быть лучшим способом.

3. Хорошо ли иметь графический интерфейс на языке, отличном от C ++? Если да - на каком языке?

номер

Если вы работаете в команде программистов из одного человека, вы будете слишком усердно заниматься, пытаясь освоить два языка. Если вы команда из нескольких человек, зачем усугублять проблемы общения, создавая две разные культуры?

4. Это хорошая идея иметь графический интерфейс на основе браузера?

Нет, если вы можете избежать этого. Если вам нужен графический интерфейс на основе браузера, тогда вы об этом узнаете. Если вам это не нужно, то будьте проще и пропустите.

5. Несмотря на то, что основная логика проекта кроссплатформенная, я могу решить, что графический интерфейс будет только на основе Windows (.NET?), И он будет взаимодействовать с логикой на соответствующей машине Win / Linux через Socket или подобный метод. Это хорошая идея?

Тот же ответ, что и # 4

Answer 9

лучше использовать Python в качестве базового языка графического интерфейса пользователя, а QT - в качестве платформы графического интерфейса пользователя. если вы разделяете графический интерфейс и базовую программу на отдельные процессы, вы можете использовать эти механизмы для связи:

1. сигналы и слоты от Qt
2. модуль подпроцесса на python
3. местные розетки.
4. использовать файлы [записывать конфиги в файл и сигнализировать другой процесс для обновления]

но лучше создать один процесс и вызывать ваш базовый язык напрямую из python и взаимодействовать со структурами данных родного языка. Вы, кошка, используете глоток для этой цели. но поскольку вы не можете вызывать функции Python из C ++, вы можете использовать пул в Python для некоторых изменений в общих данных и делать что-то на основе этих изменений. Я испытал два пути. когда я использовал python для графического интерфейса и управления, это очень экономило время.

Answer 10

У тебя много хороших ответов, но я все равно напишу свои

Следует ли отделить графический интерфейс от логики приложения?

Я думаю, что это лучшее. Таким образом, вы можете справиться с этим проще, когда дело доходит до модификаций. Кроме того, используйте среду графического интерфейса пользователя, которая является мультиплатформенной и имеет привязки для других языков, таких как GTK + или Qt.

Если он отделен, как должны взаимодействовать логика и графический интерфейс? Являются ли сокеты TCP / IP хорошим вариантом? Каковы другие возможности?

Сокеты - хороший выбор или через потоки, если это локальная связь.

Хорошо ли иметь графический интерфейс на языке, отличном от C ++? Если да - на каком языке?

Я думаю, что это не лучший вариант. Если возможно, используйте один и тот же язык для всего.

Хорошо ли иметь графический интерфейс на основе браузера?

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

Несмотря на то, что основная логика проекта является кроссплатформенной, я могу решить, что графический интерфейс будет только на основе Windows (.NET?), И он будет взаимодействовать с логикой на соответствующей машине Win / Linux через Socket или похожий метод. Это хорошая идея?

Не на мой взгляд, это добавляет сложности, обычно ненужной, но если вам действительно нужно это делать, да, сокеты - лучший вариант.