Рекомендации по проектированию на Qt - есть ли что-нибудь?

[Я.К.]

Есть ли в природе какие-нибудь рекомендации по тому, как лучше писать Qt-приложения?
Сейчас то, что я пишу, вполне работает, но остаётся стойкое чувство, что оно работает через ректальную задницу.
 
Интересуют, например, такие банальные вопросы:

• Как правильно отрабатывать несколько контролов, отвечающих за одно и то же свойство
• В каких случая использовать Q_PROPERTY
• Как грамотно разделять GUI и логику
• Как грамотно должны быть связаны главное окно и куча диалогов, плавающих на экране

Где бы разжиться подобным?

[asvil]

1. QAction
2. Когда сучность имеет свойство, которое может читаться и опционально изменяться. В простейших случаях Q_PROPERTY это обертка над геттер/сеттерами.
3. Уволить всех менеджеров и избавиться от пользователей, которые в 99% случаев не знают чего хотят, предлагают поменять логику/интерфейс 10 раз в день.
4. Чем слабее связь, тем лучше, если вы стремитесь к переиспользованию кода. Простейший случай:
связь "главное окно А, подчиненный диалог Б".
А создал Б
А задал свойства Б
А показал Б
когда Б закрылся, А считал из Б необходимые свойства.

[Я.К.]

Сможете капельку подробнее пояснить за QAction?

[asvil]

1. Если контролы представляю собой элемент меню или элемент тулбара, то применяется QAction. А точнее тулбары и меню состоят из QAction'ов.
Если контролы сложнее, то необходимо связывать сигналы изменения их свойств со слотами измения связанных свойств других контролов.

[iroln]

Тема вообще интересная. Я думаю, уважаемый Я.К. всё же имел желание узнать, как правильно архитектурно проектировать Qt приложения. Я когда-то тоже интересовался на эту тему, так сказать, искал "Best practices" при разработке Qt приложений, но так ничего не нашёл. В итоге пришёл к выводу, что Qt приложения нужно проектировать и разрабатывать как любые другие приложения с объектно-ориентированным дизайном с использованием шаблонов проектирования и т.п.

Может поделитесь, как вы поступаете в следующих случаях:
1. Есть главная форма приложения, например, с табами. Если подразумевается, что функциональность табов не создаётся динамически во время выполнения программы, то выносите ли вы функциональность табов в отдельные виджеты? Если выносите, как организуете взаимодействие с главной формой, через созданный интерфейс виджета и сигналы-слоты?
А если не выносите, а, скажем, весь GUI табов создаёте в Qt Designer в одной форме, то как потом определяете все слоты, в одном файле главной формы, или разбрасываете по другим файлам (классам) и как-то налаживаете их взаимодействие?
В одном файле (классе) располагать все слоты естественно не удобно, их может быть очень много, получается класс огромных размеров, спагетти-код и т.д. Как поймать тот уровень абстракции, чтобы слоты находились в разных классах, при этом всё было логически правильно без излишних затрат на взаимодействие объектов между собой (низкая связность).

2. Управление свойством isEnableв контролов. Как вы управляете этим свойством групп элементов (когда надо зажигать, гасить разные контролы в зависимости от текущего состояния программы)? Создаёте какие-то менеджеры состояний, которые управляют состоянием контролов (гасят, зажигают нужные контролы), или действуете как-то иначе?


Я раньше GUI не занимался вообще, а сейчас появилась работа, связанная как раз с GUI. И я понимаю постепенно, что для создания красивых и правильных GUI программ должны быть прокачаны особые skills.

[blood_shadow]

to iroln

1. Подкласс необходимого тебе виджета, в нем реализация необходимых слотов
2. Сигнал\слот можно разбить на группы твои Actions, и гасить либо активировать их как одно
целое, типа:
connect(this, SIGNAL(editActionsActivate(bool)), this, SLOT(activateEditActions(bool)));
думаю идея слота activateEditActions(bool) ясна

[asvil]

2ironIn

2. Создавал механизм основывающийся на фокусе ввода, фокуспроксях, кастовал виджеты, чтобы [де]активизировать экшены, в обрботчиках экшнов опять кастил фокусные виджеты, с помощью invokeMethod вызывал слоты совпадающие с именем экшна, и в итоге вам заморачиваться всей этой фигней не рекомендую.

[Igors]

Если говорить о "реально больших" диалогах, то я пришел к таки выводам

1) Выделение в отдельный класс нужно делать только если начинается copy/paste, напр:

- табка повторяется в 2 или более диалогах
- есть 2 или более одинаковых "групп контролов" (напр листбокс и кнопки + -)

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

2) enable/disable

Код

C++ (Qt)
void MyDialog::InterfaceEnableTab1( bool iEnable )
{
  EnableControl(ID_CTL1, iEnable); 
  ...
}
 

Такой тупенький "код начинающего" часто оказывается выгоднее чем замысловатые "автоматы"

В общем нужно умело применять принцип KISS 

[iroln]

Всем спасибо за ответы! Я в принципе сейчас так и делаю.
В общем понимание всегда приходит с опытом.

[Igore]

• Как грамотно разделять GUI и логику

Где бы разжиться подобным?

Здесь http://doc.qt.nokia.com/4.7-snapshot/model-view-programming.html 

[iroln]

Кстати, а есть ли в Qt что-то подобное "Commanding" из WPF?
http://msdn.microsoft.com/en-us/library/ms752308.aspx

Я на WPF сам не программирую, но коллеги говорят, что роутинг команд решает все проблемы с разработкой сложной логики приложения и управления контролами, не запутывая код и не создавая "спагетти".

Может что-то подобное можно реализовать через фильтрацию событий?

[asvil]

Сказывают что до WPF Qt не дотягивает, соответственно аналога роутинга команд нету.