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

Ответ 1

• Следует ли отделить GUI от логики приложения?

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

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

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

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

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

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

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

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

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

EDIT:

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

Ответ 2

Следует ли отделить GUI от логики приложения?

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

• AJAX/браузерный интерфейс
• Trolltech/Nokia Qt
• Eclipse (SWT)
• Java Swing (hmm...)

Ответ 4

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

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

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

Ответ 5

1. Должен ли GUI быть отделен от логики приложения?

Да. Однако см. Ответ # 2

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

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

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

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

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

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

Нет.

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

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

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

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

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

Ответ 6

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

Ответ 7

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

Следует ли отделить GUI от логики приложения?

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

Причины полного его разделения:

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

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

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

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

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

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

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

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

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

Конечно. Если, что вам нужно, вы можете сделать с HTML5 и JavaScript, даже не рассматривайте традиционный графический интерфейс, просто сделайте вместо него webapp.

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

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

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

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

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

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

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

Ответ 8

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

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

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

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

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

Ответ 9

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

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

Windows и Linux! → Я бы использовал С++ или Java

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rgds Layne

Ответ 10

• Следует ли отделить GUI от логики приложения?

Да.

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

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

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

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

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

Лучшая идея, пока ваше приложение не нуждается в слишком тонкой степени контроля во время взаимодействия с пользователем.

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

IMHO добавленная сложность использования сокетов не стоит.

SciTE - довольно хороший пример простого кросс-платформенного приложения. Исходный код должен быть прост в использовании для программиста Windows. Я предлагаю вам загрузить исходный код и посмотреть, как две платформы (Windows и GTK) были обработаны той же базой кода.

Ответ 11

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

Следует ли отделить GUI от логики приложения?

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

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

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

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

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

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

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

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

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