Russian Qt Forum

Приветствую заглянувших.

Поматалыкался я немного с жуткими интерфейсами с меню тройной вложенностью и осенила меня мысль. А потом появился и вопрос.

Имеются ли средства для генерации кода по ui файлу?

Простой поиск по инету ничего похожего не дал, но ведь идея то неплоха. Сделав интерфейс в Qt Designer'e, получить на выходе болванку класса с необходимыми тебе связаными функциями и форматированием.

Дык QtDesigner этим сам и занимается, не? Для русской версии - Форма - Показать код.

вообще Qt создает код.
при компиляции создается файл ui_<название ui формы>.h
Там весь код хранится.

Не в том смысле, что просто код формы для динамического создания - нет.

А в смысле аля сделал меню с 3 уровнем вложенностью и десятками кнопок.

А после генерации получил класс-наследника от QMainWindow с слотами, связанными с этими компонентами, с красивыми комментариями аля

Чисто механические действия - создание слотов, связывание слотов с виджетами. Чтобы это сделать нид как минимум помудохаться минут 5-10. Что в свою очередь не очень гуд.  

PS мысль свою выразил я понятно? или нет?

PPS спасибо за ответы, но немного не то. Это я уже знал :)

Нет, не понятно. Правой кнопкой на элемент->"перейти к слоту" это надо?

Господин Patrin Andrey я говорю о Designer. Не путайте о его интеграции в креаторе, о которой вы, по всей видимости, говорите :)

Хотя по смыслу наверно похоже (в креаторе не работал). Посмотрел - да, в принципе оно.

Но. тыкать в меню/подменю/подменю из подменю это ... Сами поймете думаю :)

Т.е. утилиты такой нет походу, окромя её жалкого подобия в креаторе. Жаль, очень жаль.

PS Жалкое потому, что нельзя "перейти к слоту" action'a, нельзя выделить группой, нельзя... много чего нельзя. Но самый главный минус - привязанность к креатору :D

Action'ы вполне можно создавать в дизайнере и переходить к их слотам.

Я с налёту не смог. Но в любом случае по одному щелкать не вариант :)

uic file.ui outfile.h

lit-uriy почитайте тему. Пожааалуйста.

PS ну или хотя бы 4 сообщение.

Верес, нет, нету такой возможности о которой ты говоришь...

ЗЫ: Может тебе нужно, чтобы оно еще спело и станцевало? :)

Прощупываю почву для создания.

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

Мне б лучше, если б оно ещё и водить умело :D

PS очень кстати круто заляпать меню, навесить картинки и... И через 3 секунды получить код для вставки, связанный со всеми необходимыми сигналами :D

Нда.
Такие системы лучше обслуживаются метаданными.
У меня свыше 700 не системных-пользовательских пунктов в меню + пол сотни системных.
Мне даже пришлось поисковую систему сделать, показывающую где в каком меню нужный объект висит.
Разумеется с возможностью запуска из поиска.

У вас уже промышленный масштаб серьёзной системы :)

А серьёзные системы требуют серьёзных подходов.

А как у вас реализованы вызовы пунктов?

В 1С есть такой проект OpenConf. Там один мастер внедрил в среду разработки скриптовую систему, обвязал объекты среды разработки в COM-оболочку и сделал доступными их через скрипты. Парни столько скриптов понаписали - интеллиценз, вимкомплит, куча конструкторов на все случаи жизни.
Разработка упростилась в разы. Чего и вам желаю.
Т.е. писануть скрипт который парсит xml файл ui и *.cpp и *.h файлы и добавить в них вызовы, переменные и слоты вполне возможно.
Надо бы в креаторе такую фичу замутить - сорцы то открыты.

Элементарно запускается. В первой колонке путь к объекту: "Обработка.УправлениеНастройками1Спп32хх"
Оборачиваешь в системную команду: ОткрытьФорму("Обработка.УправлениеНастройками1Спп32хх");
У меня правда реализовано с пом. доп обработки, которая сначала права на использование объекта запрашивает, а потом уже открывает.

Я собственно и заморачиваюсь на системы типа http://www.prog.org.ru/topic_23822_0.html
Потому что знаю, любая система, введенная в эксплуатацию имеет шанс разрастись в монстра,
управлять которым можно будет только с помощью специальных инструментов.

Bepec, я тут маленько пофлудю, надеюсь "частично в тему"

В добрые старые времена на Mac  (когда еше никаким линухом и не пахло) все и всегда грузили диалоги из ресурсов. Диалог рисовался интерактивно, редакторы были - и не один. Загрузив диалог знали что контрол 1 - напр button, 2 - EditText и.т.д. Известны были только ID, по ним можно было взять handle контрола и дальше с ним самому разбираться. И все прекрасно работало, программист никаких трудностей не испытывал если руки у него росли как надо.

А теперь - подайте то, принесите это. И текст сгенерите, и чтобы красиво оформлен, и попку подмойте.. В итоге - безрукое создание, умеющее только собирать, подключать и, по существу, ничего более. Зажрались. А ведь никто не мешает делать как раньше - есть QFormBuilder, и сигналы он хранит, и пропердии (не то что раньше - ID и все). Рисуйте себе в дизайнере на здоровье, потом только контролы в свои переменные загрузите. Чужой код (какой угодно хороший) всегда будет источником проблем по той простой причине что чужой. Его лучше не иметь.

to panAlexey:
Хорошо, что у вас имеется готовая система :) Спасибо за пожелание.
Одно плохо в идее с креатором - креатор :D (моё ИМХО)

to Igors:
В тему ваш флуд, в тему :)
Я всё ждал когда это скажут - "пишите на ассемблере, а то превратились в тупых сборщиков из лего".

Дело не в "красиво оформлено" и не в "подай принеси" и даже не в "зажрались" :)

А дело в автоматизации рутинной работы :) Я ещё не дошёл до создания скриптового движка для связывания экшенов.
Но необходимость обработать 20/30/40 пунктов меню заставляет подумать об автоматизации написания кода. 40 раз писать к примеру "void on_action_trippleKillEnemy_triggered(bool);" в h. А потом 40 раз в cpp. А потом ещё и держать в голове (или дополнительно 40 раз писать комментарии) где эти пункты находятся - как бы плохо.

Igors - предложите другой способ написания обработчиков для action'ов и мы с вами его обсудим.

2 Верес,

блин, а я что-то до сих пор не въехал, зачем это надо...

Т.е. ты хочешь, типа: набросал на UI контролы, назвал их как тебе нужно, жмакаеш некую
магическую кнопочку "сделать мне волшебство" и на выходе получаешь класс...

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

Блин, я недогнал...

to kuzulis:

Собственно начало этой темы положили action'ы. У которых мне нужен был только один слот - нажатие.

Т.е. набросал action'ы на QMenu в дизайнере, задал им имена. Сохранил ui.
Врубил скриптип - чух мара пух - получаю кусок кода для h и cpp. И там и там имеются комментарии аля "//файл->открыть", обозначающие месторасположение контрола.

Для примера и более полного понимания - вот жаба скриптик.
Способ применения - задать ему в параметрах командной строки обрабатываемый ui. В ui должны быть action'ы.

На выходе текстовый файлик test.txt создаваемый рядом со скриптом, содержащий в себе код.

PS соответственно он работает на W7 64, а вот на линуксах как js запускать я и не подозреваю.

PPS а вырасти это может, если запал не пропадёт, в довольно простую систему с выбором создаваемых слотов для групп контролов.

А почему бы всё не упростить и вешать слоты не на каждый QAction, а один слот на один QMenu::triggered( QAction* action )?

И получить один огромный смешанный свич? Который в конце концов сведётся к вызову функций, реализующих функционал?

Т.е. как я вижу, получается аля
Вижу только недостатки такого подхода. Как то неявность для стороннего программиста, большее (на 1, но всё же) количество функций (кстати проще подключать на QMenuBar).

м?

PS хотя в принципе и такое развитие событий возможно, создание по ui файлу данного свича.

Почему огромный? У тебя что в меню огромное количество пунктов ??? Если > 20, то кривой дизайн.
И в любом случае всё "сведётся к вызову функций, реализующих функционал".

Привязываемся не к "какой-то_признак", к QAction::objectName().

Может и проще, только бессмысленно, ибо только определённое меню знает какой QAction был выбран.

А разве не написано, что только главное меню должно быть подписано на сигнал.

Да, меню огромное. > 20/30/40 с уровнем вложенности 3.

Но. Мне даже из 10 пунктов будет приятнее видеть отдельные функции для реализации, чем одна большая.  (мой юный и непосредственный взгляд  ;))

Да, кривой дизайн. Дизайн не мой. Дизайн заказчика.

Да, я бессилен в этом направлении.

Где ???

Тебе в любом с лучае придётся писать туеву кучу слотов на каждый пункт. От этого никуда не деться.
То, что я предлагаю, имхо, должно как раз упростить всё.
Можно явным перебором по названию QAction, либо через QMetaObject::invokeMethod() опять же по имени QAction дергать определённый слот.

made by assistant QMenuBar

Видимо мы не понимаем чуть друг друга. Последовательность моих действий:
1) создать QtGui класс, создать в ней меню из 5 action'ов.
2) запустить скрипт на ui. файл.
3) скопировать вывод в h, cpp.
4) реализовать функционал.

Вот вывод уже готового скрипта, который я выкладывал ранее.
Т.е. куева туча слотов создана, уже связана с формой. Мне остаётся только скопировать это в h, cpp и реализовать/объединить если необходимо функционал.

хороший скрипт сам должен писать в файлы.

я предпочитаю давать слотам норамальные названия, отражающие что они делают.

Kambala, я ж произвёл все действия только что и исключительно для примера. Дабы прояснить все страсти.

Да, скрипт недоделанный. Да, он к тому же не умеет читать комментарии из-за UTF8.

Да, я тоже предпочитаю давать нормальные названия.

Да, я в js не очень силён. Даже скорее не то чтобы не силён, а просто идея реализации полноценной утилиты у меня пока на задворках сознания сидит.

Да, я устал, разнервничался и хочу домой. Не придирайтесь к словам и примерам пожалуйста.

Я говорю совсем про другое. Можно всё сделать автоматом непосредственно в самом приложении без всяких скриптов.
Достаточно чтобы меню имело уникальное название и элемент меню в рамках своего меню тоже имел уникальное название.
Далее после создания QMenuBar-а и всех его подменю пробегаешься по всем подменю и вешаешь на каждое меню слот на QMenu::triggered( QAction* action ), в котором по имени меню и полученного action формируешь название слота и через QMetaObject::invokeMethod() вызываешь этот слот. Понятно?

Проще тебе написать мааленький примерчик, чем говорить, тогда уж точно все станет понятно.  :)

К этому сообщению приложен скрипт. Времени его искать снова нет. Пользуйтесь.

Да пожалуйста:

C++ (Qt)
#include <QApplication>
#include <QMainWindow>
#include <QMenuBar>
#include <QStatusBar>
#include <QMenu>
#include <QUiLoader>
#include <QFile>
#include <QMetaObject>
#include <QDebug>
 
class Actions : public QObject
{
	Q_OBJECT
public:		
	Actions( QMainWindow* mw )
	: QObject( mw )
	, sb_( mw->statusBar() )
	{
		foreach( QMenu* m, mw->menuBar()->findChildren< QMenu* >() )
		QObject::connect( m, SIGNAL( triggered(QAction*) ),
			this, SLOT( invokeAction(QAction*) ) );
	}
 
private:
	QStatusBar* sb_;
 
private Q_SLOTS:
	void invokeAction( QAction* a )
	{
		QMenu* menu = qobject_cast< QMenu* >( sender() );
 
		if( !menu->actions().contains( a ) ) // ignore submenu actions
			return;
 
		QString func_name = sender()->objectName();
		if( func_name.startsWith( "menu" ) )
			func_name.remove( 0, 4 );
		func_name.replace( 0, 1, func_name.at( 0 ).toLower() );
		QString action_name = a->objectName();
		if( action_name.startsWith( "action" ) )
			action_name.remove( 0, 6 );
		action_name.replace( 0, 1, action_name.at( 0 ).toUpper() );
		func_name += action_name;
 
		if( a->isCheckable() )
			QMetaObject::invokeMethod( this, func_name.toLatin1().constData(),
			Qt::QueuedConnection, Q_ARG( bool, a->isChecked() ) );
		else
			QMetaObject::invokeMethod( this, func_name.toLatin1().constData(),
				Qt::QueuedConnection );
	}
 
public Q_SLOTS:	
	void fileNew()
	{
		sb_->showMessage( "fileNew() invoked..." );
	}
	void fileClose()
	{
		sb_->showMessage( "fileClose() invoked..." );
	}
	void fileQuit()
	{
		qApp->exit( 0 );
	}
 
	void openFile()
	{
		sb_->showMessage( "openFile() invoked..." );
	}
	void openUrl()
	{
		sb_->showMessage( "openUrl() invoked..." );
	}
 
	void viewNormal( bool set )
	{
		sb_->showMessage( QString( "viewNormal(%1) invoked..." ).arg( set ) );
	}
	void viewFullScreen( bool set )
	{
		sb_->showMessage( QString( "viewFullScreen(%1) invoked..." ).arg( set ) );
	}
};
 
int main( int argc, char* argv[] )
{
	QApplication a( argc, argv );
	QFile f( "mw.ui" );
	QUiLoader loader;
 
	QMainWindow* mw = qobject_cast< QMainWindow* >( loader.load( &f ) );
	if( !mw )
	{
		qDebug() << "Can't load " << f.fileName();
		return 1;
	}
 
	Actions actions( mw );
 
	mw->show();
 
	return a.exec();
}
 

Подгружаемый mw.ui

XML
<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
 <class>MainWindow</class>
 <widget class="QMainWindow" name="MainWindow">
  <property name="geometry">
   <rect>
    <x>0</x>
    <y>0</y>
    <width>800</width>
    <height>600</height>
   </rect>
  </property>
  <property name="windowTitle">
   <string>MainWindow</string>
  </property>
  <widget class="QWidget" name="centralwidget"/>
  <widget class="QMenuBar" name="menubar">
   <property name="geometry">
    <rect>
     <x>0</x>
     <y>0</y>
     <width>800</width>
     <height>26</height>
    </rect>
   </property>
   <widget class="QMenu" name="menuFile">
    <property name="title">
     <string>File</string>
    </property>
    <widget class="QMenu" name="menuOpen">
     <property name="title">
      <string>Open</string>
     </property>
     <addaction name="actionFile"/>
     <addaction name="actionUrl"/>
    </widget>
    <addaction name="actionNew"/>
    <addaction name="menuOpen"/>
    <addaction name="actionSave"/>
    <addaction name="actionSave_As"/>
    <addaction name="separator"/>
    <addaction name="actionClose"/>
    <addaction name="actionQuit"/>
   </widget>
   <widget class="QMenu" name="menuEdit">
    <property name="title">
     <string>Edit</string>
    </property>
    <addaction name="actionCut"/>
    <addaction name="actionCopy"/>
    <addaction name="actionPaste"/>
   </widget>
   <widget class="QMenu" name="menuView">
    <property name="title">
     <string>View</string>
    </property>
    <addaction name="actionNormal"/>
    <addaction name="actionFullScreen"/>
   </widget>
   <addaction name="menuFile"/>
   <addaction name="menuEdit"/>
   <addaction name="menuView"/>
  </widget>
  <widget class="QStatusBar" name="statusbar"/>
  <action name="actionClose">
   <property name="text">
    <string>Close</string>
   </property>
  </action>
  <action name="actionFile">
   <property name="text">
    <string>File</string>
   </property>
  </action>
  <action name="actionUrl">
   <property name="text">
    <string>Url</string>
   </property>
  </action>
  <action name="actionQuit">
   <property name="text">
    <string>Quit</string>
   </property>
  </action>
  <action name="actionNew">
   <property name="text">
    <string>New</string>
   </property>
  </action>
  <action name="actionSave">
   <property name="text">
    <string>Save</string>
   </property>
  </action>
  <action name="actionSave_As">
   <property name="text">
    <string>Save As...</string>
   </property>
  </action>
  <action name="actionCut">
   <property name="text">
    <string>Cut</string>
   </property>
  </action>
  <action name="actionCopy">
   <property name="text">
    <string>Copy</string>
   </property>
  </action>
  <action name="actionPaste">
   <property name="text">
    <string>Paste</string>
   </property>
  </action>
  <action name="actionNormal">
   <property name="checkable">
    <bool>true</bool>
   </property>
   <property name="text">
    <string>Normal</string>
   </property>
  </action>
  <action name="actionFullScreen">
   <property name="checkable">
    <bool>true</bool>
   </property>
   <property name="text">
    <string>Full Screen</string>
   </property>
  </action>
 </widget>
 <resources/>
 <connections/>
</ui>
 

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

В вашем идёт чтение ui (вы рассчитываете, что все ui будут лежать в пределах досягаемости ручек пользователя?), дополнительный класс - менеджер (прекрасно (не ирония, я о таком подходе не подумал), см. PPS), двойной вызов сигналов ( не критично ), связывание в конструкторе, невнятные (от моего незнания) манипуляции в main.

Ваш пример можно доработать, ища не "все Qmenu", а используя только QMenuBar, как я уже писал, если верить ассистенту.

Ваш подход ммм... скажем так непонятен начинающему (думаю начинающий повесится :D ) и довольно громоздок к условностям. Минимум в 3 местах надо будет иметь обвязку.

Мой подход имеет же прост, основан на стандартном связывании и как раз, по моему мнению, подходит для разработки форм средней сложности средними программистами.

PS снимаю перед вами шляпу - с помощью QUiLoader можно запепенить нормальную утилитку. Незнал, незнал.

PPS ваш подход прекрасен для запутанных проектов. Думаю, чуть подправив, можно свести все Action'ы в этот класс менеджер. Вот только в большинстве случаев меню виджета должно выполнять с ним какие то действия. У вас же получается отвязка от самих виджетов и необходимость дополнительной обвязки в каждом из MainWindow и как следствие нарушение инкапсуляции.




 

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

Ну почему же - нормально. Но в любом случае :D Необходимо делать эти слоты вручную. А это как раз тупая моторика. Не требующий ума монотонный набор одинаковых функций и прочего :)

Можно еще один способ использовать:
1. Завести болванку под систему, которая реализует "общие" системные пункты, такие как обработка распространенного типа файлов - тесктовых, хтмл, или что там вашей софтине требуется, печать, вызов хелпа, управление окнами и т.д. и т.п.
2. Болванку под построение меняющихся интерфейсов. Т.е. туда, куда формы добавляются. Тут уже куча методов, от испоьзования уилоадеров до использования словаря метаданных.
Я именно так и сделал.

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

panAlexey, разъясните мне пожалуйста концепцию болванки, а то чего й то не понимаю.

Просто в случае с словарём и прочими методами связь "пункта" и слота неочевидна и требуется обвязка. Повторюсь - для средних проектов.

PS мне просто обвязки очень ненравятся. Ибо я то разберусь, а кому другому надо будет изменить/добавить, то ему придётся разбираться в обвязке и необходимом количестве условий для её выполнения.

Дело в том, что если завязываться на QMenuBar::triggered( QAction* action ), то нам никак не узнать в каком именно меню выбрали пункт :(

Почему?
Псевдокод
Если добавить рекурсию, возможно получить все Menu. Или я неправ и при добавлении подменю в меню, он не становится его родителем? Незнаю.

Неправ по всем параметрам.
Неужто ты думаешь, я не проверил все варианты перед тем как утверждать)

Да то же самое, что и наследование в ООП.
Есть класс который может многое и многое делает, ты берешь его за основу и добавляешь свои функции.

Не, болванки в этом случае не катят :) Слишком разный набор функций. Всё вместе собрать - получится крошево :D