Russian Qt Forum
Августа 29, 2025, 19:28 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Рекомендации по проектированию на Qt - есть ли что-нибудь?  (Прочитано 6201 раз)
Я.К.
Гость
« : Октября 02, 2011, 15:06 »

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

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

Где бы разжиться подобным?
Записан
asvil
Гость
« Ответ #1 : Октября 02, 2011, 15:43 »

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

Записан
Я.К.
Гость
« Ответ #2 : Октября 02, 2011, 15:46 »

Сможете капельку подробнее пояснить за QAction?
Записан
asvil
Гость
« Ответ #3 : Октября 02, 2011, 15:56 »

1. Если контролы представляю собой элемент меню или элемент тулбара, то применяется QAction. А точнее тулбары и меню состоят из QAction'ов.
Если контролы сложнее, то необходимо связывать сигналы изменения их свойств со слотами измения связанных свойств других контролов.
Записан
iroln
Гость
« Ответ #4 : Октября 02, 2011, 21:13 »

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

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

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


Я раньше GUI не занимался вообще, а сейчас появилась работа, связанная как раз с GUI. И я понимаю постепенно, что для создания красивых и правильных GUI программ должны быть прокачаны особые skills. Улыбающийся
Записан
blood_shadow
Гость
« Ответ #5 : Октября 02, 2011, 21:34 »

to iroln

1. Подкласс необходимого тебе виджета, в нем реализация необходимых слотов
2. Сигнал\слот можно разбить на группы твои Actions, и гасить либо активировать их как одно
целое, типа:
connect(this, SIGNAL(editActionsActivate(bool)), this, SLOT(activateEditActions(bool)));
думаю идея слота activateEditActions(bool) ясна
Записан
asvil
Гость
« Ответ #6 : Октября 02, 2011, 23:12 »

2ironIn

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

Сообщений: 11445


Просмотр профиля
« Ответ #7 : Октября 03, 2011, 11:54 »

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

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

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

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

2) enable/disable
Код
C++ (Qt)
void MyDialog::InterfaceEnableTab1( bool iEnable )
{
 EnableControl(ID_CTL1, iEnable);
 ...
}
 
Такой тупенький "код начинающего" часто оказывается выгоднее чем замысловатые "автоматы"

В общем нужно умело применять принцип KISS  Улыбающийся
Записан
iroln
Гость
« Ответ #8 : Октября 04, 2011, 11:42 »

Всем спасибо за ответы! Я в принципе сейчас так и делаю. Улыбающийся
В общем понимание всегда приходит с опытом.
Записан
Igore
Гость
« Ответ #9 : Октября 04, 2011, 12:02 »

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

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

Здесь http://doc.qt.nokia.com/4.7-snapshot/model-view-programming.html  Улыбающийся
Записан
iroln
Гость
« Ответ #10 : Октября 04, 2011, 20:19 »

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

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

Может что-то подобное можно реализовать через фильтрацию событий?
Записан
asvil
Гость
« Ответ #11 : Октября 04, 2011, 22:18 »

Сказывают что до WPF Qt не дотягивает, соответственно аналога роутинга команд нету.
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.032 секунд. Запросов: 19.