О прикручивании графического интерфейса

А зачем нужно разделять? И при чем тут QApplication::exec?

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

>А зачем нужно разделять? И при чем тут QApplication::exec?

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

>Строго говоря, большинству приложений консольная реализация не нужна. Нужен интерфейс и библиотека для доступа к функциональности.

Консольная реализация чего не нужна? Отображения данных? Некоторым нужна, и консольная, и графическая.

Предположим, есть класс интерфейса, сделанного на QT. Разве так: class UserInt *userint = new class QTBasedInt окно отобразиться? Нет!

> Хотелось бы разделить приложение на часть, ответственную за основную логику работы, и часть, ответственную за представление информации пользователю. Что выбрать в качестве средства реализации графического интерфейса?

tcl/tk. Оно как раз для таких случаев предназначено.

Очень глупый онанимус. Вали обратно в свой виндовз, тут тебе не место.

Когда поймёшь, что такое unix way - возвращайся.

Попробуй guile/gtk. Это в том случае, если Tk кажется не шибко красивым.

Здравствуйте.

Можно использовать любую библиотеку GUI.

Всё будет сосредоточено на том какое приложение вам нужно создать.

В обычном случае можно разделить GUI и сердцевину и осуществить обмен между ними.

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

Непонятным для меня пока что остается интеграция уже созданного GUI интерфейса в проект, созданный на C/C++. Есть ли такая возможность для GTK, Tcl/Tk, QT?

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

Что думать? Фильтровать данные, группировать, усреднять. Поскольку много данных не покажешь, а если и покажешь, то пользователь их все-равно не сможет осмыслить.

Что именно не понятно?

Обычно из гуишной программы дергают библиотечные функции: вызвали getData, получили данные, показали; пользователь изменил данные, сохранили через setData.

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

http://doc.trolltech.com/3.3/qapplication.html#QApplication-2

В этом смысле поучителен проект http://www.licq.org/

Сама аська в LICQ графики не имеет. Графические интерфейсы подключаются как плагины (.so модули). Есть текстовый плагин, qt, gtk. По причине наибольшего качества, qt-плагин самый популярный.

>Сама аська в LICQ графики не имеет. Графические интерфейсы подключаются как плагины (.so модули). Есть текстовый плагин, qt, gtk. По причине наибольшего качества, qt-плагин самый популярный.

Вот! А каким образом создать этот .so модуль из уже созданного графического окна на основе того же QT?

Вас интересует создание .so модулей вообще или непонятно, как создавать окна из функций модуля? Во втором случае не вижу принципиальных отличий от обычной программы, т.к. обычная программа, можно сказать, тоже модуль, с функцией main.

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

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

Все правильно.

> Вызвав из модуля функцию создания окна, она так же не завершится до момента закрытия пользователем окна...

Почему не завершится? Должна завершиться.

>Почему не завершится? Должна завершиться.

Вы не могли бы привести примерный код функции, два вызова которой создадут две кнопки, например?

Не надо ничего интегрировать. Мухи отдельно, котлеты отдельно. В Unix-ах главный механизм интеграции - пайпы.

Вы хотите сказать, что программа, имеющая интерфейс на основе QT, и на основе Motif, обязана работать через пайпы?

Такие примеры есть в документации. Почитай --- может после вопросов станет меньше.

>Именно второй случай. Отличия есть, так как для отображения виджета в main () используется QApplication. Он вызывает метод exec (), и следующий за ним оператор не будет выполняться до тех пор, пока пользователь не закроет окно приложения... Вызвав из модуля функцию создания окна, она так же не завершится до момента закрытия пользователем окна...

Все правильно. А что мешает вызвать нужную не-GUI функцию из MainWindow уже?

>Все правильно. А что мешает вызвать нужную не-GUI функцию из MainWindow уже?

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

> Так реализация всей логики, и не относящейся к интерфейсу, перенесется в MainWindow.

Что ты называешь логикой, не относящейся к интерфейсу?

> А ведь это не хорошо, интерфейс по сути - вторичен...

Как вторичен? Зачем он тогда нужен?

>Что ты называешь логикой, не относящейся к интерфейсу? Как вторичен? Зачем он тогда нужен?

Способ обработки, хранения данных, к примеру. Это не компетенция интерфейса. Интерфейс же может быть реализован посредством некоторого набора API, использовать который могут и графическое окно, реализованное на основе любой библиотеки, и консоль. Есть этому примеры?

> Способ обработки, хранения данных, к примеру. Это не компетенция интерфейса. Интерфейс же может быть реализован посредством некоторого набора API, использовать который могут и графическое окно, реализованное на основе любой библиотеки, и консоль.

Кто кого использует? Не понял.

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

> Есть этому примеры?

vim, emacs.

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

Как сделать программу, интерфейсом которой было бы QT-окно? (Почувствуйте разницу - не "как написать QT приложение"). Еще раз, трудность в его, окна, создании!

> Как сделать программу, интерфейсом которой было бы QT-окно? (Почувствуйте разницу - не "как написать QT приложение")

Это как так? Qt окно есть, а qt приложения нет. QApplication что-ли свой написать? Оно тебе надо?

QT-интерфейс должен быть плугином к программе.

>Не надо ничего интегрировать. Мухи отдельно, котлеты отдельно. В Unix-ах главный механизм интеграции - пайпы.

Посмотрел реализацию плугинов в lisq. Вы правы, спасибо.

>Не надо ничего интегрировать. Мухи отдельно, котлеты отдельно. В Unix-ах главный механизм интеграции - пайпы.

Посмотрел реализацию плугинов в lisq. Вы правы, это делается через нити и пайпы. Спасибо.