Проектирование и написание интерфейса

[lega4]

Когда начал изучать Qt, довольно бросилось в глаза, что в книжках "интерфейс" проектируется, так сказать, прямо в коде

Код

C++ (Qt)
...
Qlabel* lbl=newQLabel("Hello");
lbl->show();
...
 

После визуального проектирования в Delphi или MSVS это довольно непривычно, но, с другой стороны, имеет смысл. Но сейчас вот начал писать приложение не "хелловорлд", а чуть более серьезное, с десятком элементов управления: label'ы, lineedit'ы, кнопки. И возник такой вопрос - как это принято делать в Qt?
1. То же визуальное проектирование, к примеру, на вкладке "Дизайн" Qt Creator'a. Рисуем формочку, потом ее "натягиваем" на наше окошко (как, кстати?) и все хорошо.
2. Пишем в коде все эти QLabel* MyLabel14=new QLabel("Hello"). Если так, то вопрос тот же - как это принято делать? Ручками объявлять два десятка лейблов с разными именами или заводить массив указателей на QLabel* и в нем в цикле просоздавать нужные элементы?

[Пантер]

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

[kambala]

можно в дизайнер набросать контролы и выставить свойства, а их лейаут делать в коде - потом будет удобнее (и быстрее) добавлять/удалять/перемещать элементы интерфейса

[Igors]

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

[lit-uriy]

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

Что-то про нарисованное я не понял, что нарисованное?
Удобство динамически загружаемого ui-файла я понимаю, а вот засовывания его в ресурсы совсем не понимаю.
Т.к. динамически загружать мы уже не можем (всё в бинаре) дак зачем же совать ui-файл в ресурсы?

[lit-uriy]

lega4 в Qt существует несколько способов использования ui-файлов:
1) Прямое использование класса созданного uic (например, как член класса-окна)
2) Использование множественного наследования (от виджета и класса формы)
3) Динамическая загрузка ui-файла с помощью QUiLoader

Ну и без ui-файлов можно создавать интерфейс.

А выбирается тот способ, которым в данный конкретный момент удобнее.

ui-файлы, как в дельфях - статика. Весь динамизм интерфейса создаётся в коде.
Можно часть сделать в дизайнере, а часть в коде

[Igors]

Удобство динамически загружаемого ui-файла я понимаю, а вот засовывания его в ресурсы совсем не понимаю.
Т.к. динамически загружать мы уже не можем (всё в бинаре) дак зачем же совать ui-файл в ресурсы?

3) Динамическая загрузка ui-файла с помощью QUiLoader

ui-файлы, как в дельфях - статика. Весь динамизм интерфейса создаётся в коде.
Можно часть сделать в дизайнере, а часть в коде

Неясно что у Вас "статика" а что "динамика"   Я имел ввиду простую вещь, пример

Код

C++ (Qt)
void MyDialog::SetupUI( void )
{
// загружаем что наваяли в дизайнере (со всеми созданными там сигналами и.т.п)
	QFormBuilder builder;
	QFile file(QString(":/UI/MyWidget.ui"));
	file.open(QFile::ReadOnly);
	QWidget * w = builder.load(&file, this);
	file.close();
	if (!w) Error("Can't load resource MyWidget.ui");
 
// подгоняем размер диалога под созданный в дизайнере
	setMinimumSize(w->minimumSize());
	setMaximumSize(w->maximumSize());
 
// заполняем члены класса - виджеты с которыми хотим что-то делать
	mEdit1 = GetEditByName("Edit1");
	...
}
 
QLineEdit * MyDialog::GetEditByName( const char * name )
{
	QLineEdit * e = findChild <QLineEdit *>(name);
	if (!e) Error(QString("Can't find QLineEdit resource\n") + name);
	return e;
}
 

[GreatSnake]

Удобство динамически загружаемого ui-файла я понимаю, а вот засовывания его в ресурсы совсем не понимаю.
Т.к. динамически загружать мы уже не можем (всё в бинаре) дак зачем же совать ui-файл в ресурсы?

Никто нам не запрещает запихнуть все *.ui в .qrc и потом его скомпилить и влинковать в бинарник.
Ведь QFile всё равно откуда читать файл из ресурсов или отдельного файла.

[lit-uriy]

>>Никто нам не запрещает
к чему это, я не понял.

[lit-uriy]

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

[Igors]

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

Нет помех делать это с загруженным виджетом так же как и с созданным без всякого дизайнера. Загрузка бесполезна если приложение создает виджеты о которых само заранее не знает (типа "создавать UI на лету") - но это случай редкий. Гораздо чаще надо скрывать/показывать куски UI что определены и значит могут быть сделаны в дизайнере

[GreatSnake]

Удобство динамически загружаемого ui-файла я понимаю, а вот засовывания его в ресурсы совсем не понимаю.
Т.к. динамически загружать мы уже не можем (всё в бинаре) дак зачем же совать ui-файл в ресурсы?

Сорри, сразу не понял, что имелось в виду.
Считаю огромным плюсом динамической подгрузки ui-файла то, что перегрузив QUiLoader::createWidget(), я могу управлять созданием виджетов. Например, при определенных условиях мне на форме нужен или QLineEdit или QComboBox, QCheckBox или QLabel и т.д.
Таким образом, я могу пере-использовать одну форму во многих случаях.
При статической линковке ui такое делать, имхо, невозможно.
И в таком случае уже не важно влинкован ui-файл в ресурсы или грузится отдельно.

[kolob]

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

[lit-uriy]

kolob, при наследовании, в заголовочнике нового класса ты обязан написать:
#include "ui_form.h"
А ведь этот заголовочник включается в другие файлы. Если проект большой, то перекомпиляция при каждом изменении ui-файла занимает значительное время.

В случае же агрегации через указатель, можно использовать в заголовочнике нового класса только предобъявление (forward declaration). Это существенно ускоряет компиляцию, т.к. перекомпилировать нужно только один cpp-файл (нового класса).

[kolob]

lit-uriy а могли бы дать ссылку туда где можно про это почитать и как это использовать. В ассистенте такого я не видел.