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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет.

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

4. Хорошо ли иметь GUI на базе браузера?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rgds Layne

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

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

Да.

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

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

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

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

4. Хорошая ли это идея иметь GUI на основе браузера?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Полностью кроссплатформенный
• Отсутствие установки программного обеспечения на компьютеры пользователей
• Все клиенты всегда используют последнюю версию графического интерфейса пользователя
• Веб-среда графического интерфейса пользователя на самом деле лучше работает с чем традиционные среды графического интерфейса пользователя
• Нет необходимости выделять графический интерфейс в отдельный процесс
• По-прежнему можно использовать из сценариев (например, используя программу 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

Я нашел ответ на свой вопрос. На самом деле это был вызов синхронизации (async = false), который вывел IE из себя. Я убрал это и скорректировал код, и сейчас все работает нормально.

Похоже, NetBeans добавил его несколько второстепенных версий назад: http://blogs.oracle.com/netbeansphp/entry/sftp_support_added .

Только что подтвердил, что эта поддержка в версии 6.8, которую я запустил.

Intelisense будет работать одинаково, если у вас есть все завершаемые объекты в области проекта, он не будет извлекать библиотеки на сервере. Загрузите локальную копию любых библиотек сторонних производителей, которые могут понадобиться вашему проекту, и добавьте их в путь включения проекта, чтобы получить полное завершение кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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