QT Designer

[hasherfrog]

Данный топик создан в помощь всех, кто работает с Qt и пользуется Qt Desiger при создании приложений. У меня накоплен большой опыт работы с Qt под Linux.  Но некоторые вещи ставят в тупик. Если у кого-то будут вопросы, задавайте их здесь.
Внимание! Данная тема предназначена для обсуждения вопросов, связанных не с работой Qt вообще, только дизайнера!

Мой вопрос: Qt designer внезапно стал некорректно работать. При редактировании свойств виджетов, при редактировании имени кнокпа Del на нумпаде стала удалять не букву в имени, а сам виджет. При этом "отдельный" Del (в ряду из 6 кнопочек) работает нормально. Можно, конечно, пользоватьтся  им, или BackSpace'ом, но я всю жизнь работал на нумпаде. Стрелочки на нумпаде работают как обычно. WTF? Бесит страшно...

[Dimon]

hasherfrog
Мой вопрос относится и к дизайнеру и к KDevelop'у, поэтому задам его здесь. ;)
Значит так, разрабатываю в КДевелопе с помощью дизайнера проект. Называется SigCreate. Создал проект, вызываю дизайнер, создаю в нем форму, сохраняю с именем sigcreatedlg.ui. Потом из этого .ui файла создаю файлы sigcreatedlg.h и sigcreatedlg.cpp посредством uic (т.к. КДевелоп почему-то сам это не делает). Подключаю их к проекту и наследую созданный KDevelop'ом класс SigCreate из класса диалога, созданного в Qt Designer'e. После компилю, а мне - куча ошибок типа:

sigcreate.h:35: parse error before `{' token
sigcreate.h:36: virtual outside class declaration
...
sigcreate.h:36: warning: `QString trUtf8(const char*, const char*)' declared

Я так понимаю, что создав в дизайнере форму SigCreateDlg для передачи ее в КДевелоп я должен унаследовать основной его класс SigCreate от класса SigCreateDlg.  Если да, тогда в чем может быть ошибка, если нет - тогда как работает механизм передачи информации от разработанной формы в КДевелоп?  
Файлы все прописаны и подключены. КДевелоп вроде не глючит: пробовал на 2.1.5 и на 3.0. Qt -3.1.2, Slackware-9.0, 2.4.22

[hasherfrog]

Dimon
Я прошу прощения, но с KDevelop я "завязал". Почти сразу. Более глючного ПО я даже на Линуксе не видел. Несмотря на все его плюсы и навороченность.
Что касается вопроса, меня смущает "создаю файлы ... посредством uic". Если пользоваться qmake'ом, проблем нет. Если же вручную вызывать uic и moc, надо хорошо представлять себе их "принцип действия" (могу только отослать к руководству qt).

[Dimon]

hasherfrog
"создаю файлы ... посредством uic". Если пользоваться qmake'ом, проблем нет. Если же вручную вызывать uic и moc, надо хорошо представлять себе их "принцип действия" (могу только отослать к руководству qt).

Дык а что там сложного? Из .ui файла двумя командами получаю хэдеры и исходник. А делаю сам потому, что КДевелоп сам это не делает.
По-поводу обмена информацией между формой, созданной в Дизайнере и КДевелопом я верно мыслю?

[hasherfrog]

moc. Где moc? Если форма, то скорее всего - QOBJECT. Следовательно, и moc.

[Dimon]

hasherfrog
А можно краткий экскурс сделать, так сказать? Что за moc? Проведи небольшой ликбез, если можно. :)

Добавлено:

И что посоветуешь использовать вместо KDevelop'a? Чтобы была интеграция с Qt Designer'ом? Anjuta - она вроде для GTK? C-Forge - с ним я так и не разобрался?
VIM/Emacs + autotools + gmake не предлагать. :)

[hasherfrog]

Очень кратко по поводу moc и uic.
uic превращает xml-содержимое файла описания формы .ui в .h и .cpp файлы. А moc создаёт из любого файла (чаще всего из .h) с директивой QOBJECT файл moc_xxxx.cpp, в котором будет имплементэйшн собственно QObject. Вот Вы готорите, этот мой класс будет КуОбъект. А где все методы, определяемые требованиями класса QObject? Например, property(), classname() и т.д.? Чтобы Вам их не писать руками, они создаются автоматом - именно moc'ом. Раньше был глюк, кстати - два QOBJECT на один .h давали сбои при компиляции. Сейчас вроде нет.

Это всё очень примитивно описано, почитайте всё же доки qt, там найдёте много интересного.

По поводу среды программирования: я использую KDE-> xterm[[bash]]-> designer& -> mc->qmake->make. Остальное только по мере надобности. Хватает с головой. KDeveloper пытался использовать только когда хотел поизучать  KDE. Но глюки... В последний раз, после Вашего вопроса, попытался запустить - завис где-то после 2-й минуты. Наверное, у меня руки не оттуда растут.

[Dimon]

hasherfrog
Прежде всего, если ты не против - давай на "Ты" :)
Очень кратко по поводу moc и uic.
Ага, понял, спасибо. Мне сама суть нужна, а там - разберусь...
Это всё очень примитивно описано, почитайте всё же доки qt, там найдёте много интересного.
Да я ищу, только что-то пока не нашел ничего... Док-то много... И интересного тоже много... :)
В КДевелоп-доках нашел, для чего .ui - файл используется, я это и так знал, но механизм обмена данными и как "брюки превращаются..." не описан: сказано "Вам не надо беспокоится - за вас это сделает КДевелоп". :)
Просто я не пойму: или я где-то в чем-то ошибся, при создании приложения, или КДевелоп глючит - бывало и такое...

Спасибо за помощь!  :)

[Dimon]

Такой вот еще вопрос: нужно в приложении организовать полноценную командную строку. Для этого нужно разбивать исходную строку на подстроки, выделять параметры, конвейеры, перенаправления ввода-вывода и т.д Например: ls -ls /home/dim|grep myfile*|sort>myfiles. Вручную все это разбивать и проверять непросто...
Вопрос: есть ли соответствующие объекты, которые могут разбирать командную строку (command line parsing) или вообще, ее, эту строку, организовывать?  

[ivank]

Dimon
При чём тут QT Designer?
Не проще ли передавать всё это сразу башу? Или надо просто разобрать? Тогда поможет yacc, я где-то видел грамматику bash скриптов. Очень может быть, что даже в исходниках самого баша :) В любом случае, поможет гугл.

[Dimon]

ivank
При чём тут QT Designer?
Не проще ли передавать всё это сразу башу
Пардон, а как я это все сразу передам?
Есть QProcess, у него есть метод addArgument. если я просто загоняю в него всю строку и посылаю на запуск - не работает, если же разбиваю на аргументы - работает. Как дальше быть?
А дизайнер тут при том, что может быть есть такой виджет, который уже реализует командную строку.

Не смейтесь сильно, если вопросы сильно ламеризмом попахивают - это моя первая прога под Qt. Делайте скидку...

[ivank]

Суть в том, что QT тут в общем н присём. можно просто выполнить /bin/sh с единственным параметром - то, что ввели в коммандной строке. Потом считать. Смотреть в сторону popen(), если не ошибаюсб.

А лучше не каждый раз порождать /bin/sh для выполнения одной строчки. А родить раз, а затем просто строчку ему скармливать и брать её результат. Честно говоря, не уверен как это проще сделать. Наверно, всё же придётся создавать трубу (pipe). Вообще говоря, юниксовый программер из меня тот ещё, поэтому это наверняка не лучшее решение.

И до кучи: если хочется самому парсить строчку: http://www.google.ru/search?hl=ru&q=C%2B%2B+shell-like+command+line+parsing&lr=

Добавлено:

н присём = не причём

[Dimon]

Мда, прогнал я вчера конкретно. :( Сегодня вроде разобрался...

В общем, организовал командную строку пока так:

connect ( cmd_line, SIGNAL(readyReadStdout()), this, SLOT(slotReadFromStdout()) );
...
cmd_line->setArguments("/bin/bash");
cmd_line->addArgument("-c");
cmd_line->addArgument(arg); // Entered command.
exit_status=cmd_line->start(0);
...
void lab1::slotReadFromStdout()
{
consoleTextEdit->append( cmd_line->readStdout()  );
}


Такие вот выражения, типа ls /home/dim>1|sort && cat 1 вроде работают.

[hasherfrog]

Dimon
Только маленький совет: протестируйте как следует потом своё приложение. Особенно обратите внимание на "затопление" выходной/выходной трубы :) При большом количестве строк, передаваемых туда и извлекаемых оттуда, идут глюки. Кррр, долго объяснять, если столкнётесь вдруг, я расскажу...

[Dimon]

hasherfrog
Ммм, немного не понял.
Я вызваю приложение по start(), оно отработало и я завершаю его по closeStdin(), tryTerminate() или вообще по kill(). И что,  глюки могут быть во время работы приложения, когда я буду посылать строки, с помощью например writeToStdin() или забирать строки по readStdout() ? И какие именно глюки, чтобы я смог их распознать и ликвидировать. Или обозвать фичей приожения. :)

[hasherfrog]

Визуально это будет выглядеть так:
1. Вы посылаете башу 5 команд(строк).
2. баш получает 1 строку, обрабатывает, возвращает результат.
3. Вы ждёте ответа на ещё четыре команды - до пенсии.
Как вариант, Вы устаёте ждать и...
3а. Вы посылаете ещё одну команду.
4а. Баш возвращает ответ на ранее посланные 4 + ответ последнюю.

[Dimon]

Такой еще вопрос: внятно объясните пожалуйста, как пользваться Spacer'ами? Каков механизм их работы? Какие есть общие рекомендации при их использовании? А то нигде ничего по существу не написано, или написано, что, мол, выравниванием можно овладеть только методом проб и ошибок. А этот самый метод пока не дает результатов...

[hasherfrog]

выравниванием можно овладеть только методом проб и ошибок.
:lol: Не знаю, где Вы это прочитали, но это удивительно точное описание. В процессе создания формы приходится поизгалятся, чтобы она под разными wm выглядела прилично.
Как научится пользоватся (и принцип действия) - это сразу становится понятным, когда Вы начинаете ресайзить форму (диалог). Если контролсы ведут себя "неприлично", нужно спейсеров добавить. Только не увлекайтесь. Как правило 2-х хватает за глаза.
И маленький совет: поменьше объединяйте контролсы в группы.

[Dimon]

hasherfrog
Не знаю, где Вы это прочитали, но это удивительно точное описание.
Да нашел одну статью на kde.org - вот там такое и написано. Очень информативно и крайне познавательно...
Для чего нужны спэйсеры я понимаю. Но вот принцип их работы - все никак не раскушу. Ну хоть в двух словах основные положения, так сказать, можно узнать?

[hasherfrog]

Dimon
Не совсем понял вопрос. Принцип работы стоит посмотреть в исходниках QT, наверное?..