Я голосую за Qt. База кода Qt хорошо разработана для отделения библиотеки "QtCore" от библиотеки "QtGui". «QtCore» включает в себя поддержку процессов / потоков, сигналов / слотов и подобного состояния, которое будет использоваться «независимо» от компонентов графического интерфейса. (Например, виджет "QSlider" является просто компонентом GUI, который представляет состояние, управляемое компонентом actual внутри библиотеки QtCore, что полезно для проверки границ внутри-a-value -range, который может быть красиво применен даже в приложениях без графического интерфейса, таких как системы управления оборудованием.)
Для некоторых проблем сигналы / слоты уникально предоставляют множество вариантов дизайна (гибкость). Это принципиально разрешает связь / сигнализацию между типами и объектами, которые не связаны напрямую (например, когда ни один не включает в себя заголовок другого). Хотя не все конструкции гарантируют это, он является динамичным и мощным для межпроцессного взаимодействия, систем управления оборудованием, гибко масштабируемых модульных систем и приложений с графическим интерфейсом.
Наконец, кроссплатформенное объединение «удобных» вещей, таких как процессы / потоки, очень хорошо, безопасность потоков через сигналы / слоты очень хорошо, чтение / запись поддержка кодеков, разбора файлов и мультимедийных файлов очень приятна, и в ней есть "QDesktop" - такие вещи, которые значительно упрощают вашу "иконку в трее" и другие специфичные для платформы реализации.
Qt не в все причудливо, когда вы не используете библиотеку QtGui. (Просто убедитесь, что вы используете «-= QtGui» в вашем qmake, если вы не хотите связывать QtGui.lib, не имеет значения.)
Станет ли Qt странным, если я попытаюсь сделать что-то без использования графического интерфейса
виджеты
Нет. Однако у него есть требования к сборке (например, «moc»).
Собственный (и, следовательно, довольно глубокий в ОС) излишек для
что-то подобное?
Нет, но в зависимости от вашего языка вам понадобится поддержка потоков, процессов, кодеков и т. Д. Итак, Qt может упростить это (поскольку они не обрабатываются непосредственно языками C / C ++, вам потребуется какая-то библиотека).
Учитывая, что приложение будет работать в фоновом режиме, и, таким образом,
наряду с другими приложениями, будет Qt и дополнительные слои
абстракция, которая принесет с собой, окажет пагубное влияние на
производительность оставшейся части сеанса пользователя?
Нет. Для межпотокового и межпроцессного взаимодействия это будет примерно так же быстро, как вы можете получить. Для GUI это будет наравне с любым GUI (но, вероятно, один из самых быстрых среди любого GUI).
Если я использую Qt, насколько трудно будет «вырваться» из оболочки Qt
для таких вещей, как размещение кнопки «приложение идти» в
соответствующее место на каждой платформе.
Довольно просто - это кроссплатформенное, но вы обладаете огромной гибкостью для привязки к платформе. (например, легко внедрить Qt в MFC-приложение, легко внедрить MFC в приложение Qt, легко смешать QML / Qt-Widgets и т. д.)