Платформа разработки приложений GUI

Question

Исходя из опыта C ++ и MFC, есть ли лучшая платформа (ремонтопригодность / настройка) для разработки GUI приложений?

Мы разрабатываем промышленные приложения (машинное зрение), где:
- Критически важен для производительности (в основном обработка изображений в CPU atm, но на очереди - GPU)
- Низкоуровневое аппаратное взаимодействие (собственное PCI-устройство, фрейм-граббер, карта движения)
Визуализация данных в реальном времени (изображения / статистический график)
-Будущая дорожная карта включает в себя сетевые возможности для распределенной обработки и удаленного доступа.

Кроссплатформенность для нас не будет важна, поскольку система работает в контролируемой среде (клиент заботится только о том, работает ли система и получает ли он свою продукцию).

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

Редактировать
Разъяснение по поводу «обработки изображений», упомянутых выше:
Я имею в виду «изображение» (2D информация в матричном формате), а не графика (обычно 3D векторизация). В настоящее время мы используем стороннюю библиотеку изображений (для обработки пространственной области, такой как сегментация, OCR / OCV, морфология, сопоставление с образцом) и включаем нашу логику результата.

Answer 1

Как фанат Qt я был бы упущен, не говоря об этом.

• Хотя кроссплатформенность не является одним из ваших критериев, это хороший бонус.
• Qt также имеет хорошую поддержку аппаратного видео через OpenGL (хотя я не уверен, что это поможет с аппаратным захватом).
• Это с открытым исходным кодом, так что вы можете получить ваши руки так грязно, как вам нравится.
• Это очень настраиваемый.
• Он активно развивается и имеет большое сообщество.
• Программисты MFC не должны испытывать особых трудностей при разгоне.

Вы также должны прочитать некоторые из этих вопросов и ответов:

Хорошая библиотека C ++ GUI для Windows https://stackoverflow.com/questions/610/gui-programming-apis

Answer 2

Если вам нужна обработка графики, критичная к производительности, то C ++ / DirectX или C ++ / OpenGL - ваши лучшие ставки.C ++ / DirectX, пожалуй, более удобен в обслуживании.

При этом ... в зависимости от фактической обработки, которую вы выполняете, вы можете рассмотреть вопрос о переносе частей вашего пользовательского интерфейса на более поддерживаемую платформу..NET Framework / WPF может делать довольно удивительные вещи, с хорошей реализацией шаблонов, таких как MVVM, и может быть удивительно легко обслуживаемым.То же самое касается сетевой стороны;WCF абстрагирует множество общих протоколов от кода, делая более чистый и более понятный сетевой код.Вы даже можете написать свой слой перевода между вашей неуправляемой обработкой и вашим управляемым уровнем в C ++ / CLI.

Как сказал , все это очень субъективно.Я не могу сказать достаточно по вашим пунктам, чтобы составить правильное мнение о том, можете ли вы перенести часть или даже всю свою обработку в .NET / C #.Стоит задуматься, но моя интуиция говорит мне, что это, вероятно, не лучшая ставка.

Answer 3

То, что я делал раньше при разработке научного приложения на C ++, заключалось в том, что оно будет полностью разрабатываться под консольным приложением.Консольное приложение может принимать различные типы команд с клавиатуры пользователя и выполнять соответствующие действия.Например:

image_processor > load input.png
image_processor > save out.png

Хорошо, что я могу на 100% сконцентрироваться на разработке алгоритмов, не беспокоясь о том, как вписаться в структуру GUI.Либо это MFC или QT.

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

Угадайте, что я использую для разработки графического интерфейса?Java Swing:)

Полагаю, я использую подход Unix.Посмотрите, что говорит Джоэл:

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

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