Qt vs VCL

[spectre71]

QIcon - контейнер. и пусть фантазёры не придают ему некие чудесные свойства. если имеются сомнения, копайте сорцы.

Какие чудесные свойства, вообще о чем речь?
Да контернер для QPixmap.
Я приводил его в пример, поскольку может иметь визуальное представление(как-то опосредованно визуализироваться).

Работал и в делфи и билдере. Не вижу приципиальной(идиологической) разницы между "DFM" и "UI".

а DFM можно подгрузить рантайм?

Нет, нельзя. Никто и не говорил что нет различий, речь шла про визуальное программирование.

и еще слоты поумолчанию

это что-то новенькое...

Може называется подругому, не знаю.
Например:
Есть QAction MyAction;
Ecть слот: on_MyAction_triggered;

Нет необходимости делать connect.
  connect(this, SIGNAL(triggered (bool)), this, SLOT(on_MyAction_triggered()));
будут связаны автоматически;

Все что не наследовано от QWidget - не является визуальным компонентом!!!

QLayout не наследуется от QWidget, но является визуальной компонентой.
QPixmap - его нельзя положить на форму, но даже он является визуальной компонентой.

А я вот не считаю QLayout  визуальной компонентой, где написано что это не так.
Опять же сравнивали дизайнер и делфи, в делфи есть понятие визуальные/невизуальные компоненты. Если переносить это на  QT, то визуальные - наследники QWidget, остальные - нет.

[ритт]

Работал и в делфи и билдере. Не вижу приципиальной(идиологической) разницы между "DFM" и "UI".

а DFM можно подгрузить рантайм?

Нет, нельзя. Никто и не говорил что нет различий, речь шла про визуальное программирование.
[/quote]
а разве это не принципиальное различие? может быть можно написать компоненту, загружающую DFM рантайм? нет.
а то, что редакторы в некоторой степени похожи - это ещё ни о чём не говорит.

Да контернер для QPixmap.
Я приводил его в пример, поскольку может иметь визуальное представление(как-то опосредованно визуализироваться)

нет, не может. контейнер в принципе не может иметь визуального представления.
не станешь же ты утверждать, что QList<QPixmap> может иметь визуальное представление - это было бы глупо...
контейнер визуальных компонентов ещё не становится визуальной компонентой, т.к. не имеет возможности отрисоваться.

в делфи есть понятие визуальные/невизуальные компоненты. Если переносить это на  QT, то визуальные - наследники QWidget, остальные - нет.

довольно узкий взгляд.
в дизайнере Qt всё, что можно перетащить на форму - визуальные компоненты. в то же время свойства объектов по обыкновению не являются визуальными компонентами (кроме parentWidget, которое всего лишь враппер над parent).

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

[pastor]

....просто дизайнер еще достаточно молод.

Какими мерками меряем?

[BigZ]

....просто дизайнер еще достаточно молод.

Какими мерками меряем?

Думаю по колличеству фич, Delphi, VisualStudio .NET.

[spirit]

м... тогда нужно Qt Creator сравнивать, а не "голый" дизайнер.

[кып]

а DFM можно подгрузить рантайм?

Нет, нельзя. Никто и не говорил что нет различий, речь шла про визуальное программирование.

Странно, а что тогда народ из БД подгружает?

Можно. Достаточно просто. Многие так делают.

[pastor]

Думаю по колличеству фич, Delphi, VisualStudio .NET.

А причем тут VisualStudio .NET. к Qt Designer? Извольте объяснить

[SABROG]

Не знаю говорил ли кто-нибудь здесь, что Qt отличается от дельфи еще и тем, что может собираться и работать на нескольких популярных компиляторах, а не только bcc? Я не говорю о кроссплатформенности, а именно о компиляторах gcc, msvc, bcc, icc. Большинство хороших бесплатных библиотек пишется на Си/Си++, а не Паскале. И только один компилятор может увязать все эти библиотеки на почти любой ОС - gcc.

[BigZ]

Думаю по колличеству фич, Delphi, VisualStudio .NET.

А причем тут VisualStudio .NET. к Qt Designer? Извольте объяснить

Имелись в виду дизайнер Delphi, дизайнер WinForms VisualStudio.NET и Qt дизайнер.

[spectre71]

Нет, нельзя. Никто и не говорил что нет различий, речь шла про визуальное программирование.

а разве это не принципиальное различие? может быть можно написать компоненту, загружающую DFM рантайм? нет.
а то, что редакторы в некоторой степени похожи - это ещё ни о чём не говорит.

Да контернер для QPixmap.
Я приводил его в пример, поскольку может иметь визуальное представление(как-то опосредованно визуализироваться)

нет, не может. контейнер в принципе не может иметь визуального представления.
не станешь же ты утверждать, что QList<QPixmap> может иметь визуальное представление - это было бы глупо...
контейнер визуальных компонентов ещё не становится визуальной компонентой, т.к. не имеет возможности отрисоваться.

в делфи есть понятие визуальные/невизуальные компоненты. Если переносить это на  QT, то визуальные - наследники QWidget, остальные - нет.

довольно узкий взгляд.
в дизайнере Qt всё, что можно перетащить на форму - визуальные компоненты. в то же время свойства объектов по обыкновению не являются визуальными компонентами (кроме parentWidget, которое всего лишь враппер над parent).

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

По поводу QIcon - скажу что ты рассматривал в одном контексте, я в другом(я писал опосредованно, даже специально выделил). Про QPixmap тоже можно сказать что это массив пикселей (точек).
По поводу всего остального мы оба правы, все зависит от с какой стороны рассматривать. Я пытался просто провести аналогию между типами компонент QT дизайнера и Delphi/Builder, естественно что однозначно это сделать нельзя, можно интерпретировать и так и так.

[ритт]

> QPixmap тоже можно сказать что это массив пикселей (точек).
нельзя. под иксами QPixmap - это враппер над X Pixmap, который фактически используется для визуализации этих самых пикселей (рисуя на X Pixmap, мы рисуем "на экране").

хорошо. если рассматривать со стороны делфи, ты прав. поздравляю

[Tonal]

О, пошли б./м. конкретные вопросы. Будем "конкретно" разбирать.

1. Про невизуальные компоненты.
Они хороши для быстрого прототипирования. Когда нужно за час/день нарисовать рыбу интерфейса, которую можно показать заказчику и потом выбросить.
Для нормальной разработки они плохи потому, что при их использовании логика приложения размазывается между текстом на языке и визуальном представлением формы/фрейма/датамодуля. Что существенно затрудняет понимание/рефакторинг/слияние кода. Т.е. поддержку и развитие.

Qt-ёвый дизайнер отвечает только за визуальное представление. Он позволяет редактировать и смотреть. QAction тоже относится именно к визуальному представлению.
Что позволяет чётко разделить дизайн графического представления и логику.

В DeBilder-е тоже можно разграничить, но т. к. среда не предоставляет чётких средств для этого они (представление и логика) часто смешиваются и получается неподдерживаемая каша.

Кроме того, для Qt существует множество биндингов для разных языков. Python, Perl, ADA, Haskell... и все они используют один дизайнер и один формат UI-шек. Это огромный плюс, но тоже накладывает свои ограничения.
Например UI-шке не получится сохранить какой-то код или ссылку на код (как для событий Delphi) т. к. не ясно с каким языком это будет использоваться и есть ли в нём нужные для разрешения этих ссылок механизмы.

Кстати, быстрого прототипирования можно добиться на Qt просто используя тот же Python - скорость разработки на нём почти на порядок выше чем на С++ или Delphi.

И да, DFM можно грузить в рантайме. Так что тут с UI только форматы разные.
Хотя так никто почти не делает - очень уж это заморочно и замысловато.

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

3. Про размеры.
Есть такая проблема. Статически собранная минимальная программа на Delphi с одной пустой формочкой 700-800 кб.
Для аналогичной проги на Qt как минимум в 2-3 раза больше.
Линекр Delphi таки сильно лучше линкера С++. Правда у него и работа попроще.

4. Про сигнал/слоты.
Вызов события в Delphi - это просто косвенный вызов. По сути тот же вызов виртуальной функции.
В С++ честных аналогов такого механизма нет, хотя многие распространённые компиляторы, такие как bcc, msvc, gcc имеют соответствующие расширения С++.
С другой стороны механизм сигнал/слот в Qt это гораздо больше чем события Delphi. Он позволяет привязывать несколько слотов к одному сигналу, делать синхронные и асинхронные вызовы, обрабатывать сигнал в разных потоках.
Понятно, что он при этом несколько медленнее чем косвенный вызов события Delphi.
С другой стороны, все эти механизмы - это всё же в основном отработка взаимодействия с пользователем. Для критических к скорости мест их использовать не следует. Т. е. время отработки самого вызова не критично.

[BigZ]

О, пошли б./м. конкретные вопросы. Будем "конкретно" разбирать.

Тезис про невизуальные компонены был в том, что этого нет в Qt. Спорить хорошо это или плохо я не хочу. Если это нужно для создания прототипа, то с Qt это не  возможно. А это минус.
Таже самая картина про исключения. Тезис был, что нет поддержки. Почему этого нет, то это другая история, которой наверняка есть обоснование. Но их нет, а это минус.

>>Кроме того, для Qt существует множество биндингов для разных >>языков. Python, Perl, ADA, Haskell...

Я убеждён, что в один момент времени человек разрабатывает код для одного языка. Иметь ui.xml, который будет подгружаться к разным языкам не представляется промышленным подходом к программированию. Это первое. Второе. Код обработчика не предлагается сохранять в ui.xml. Я имел ввиду вот какую возможность:
- Создать проект ui формы в Qt дизайнере.
- Связать этот проект с *.h, *.cpp файлами (для Perl с *.pl и т.д.) в которых будет реализация.
- Добавить форме пользовательский слот.
- Перейти в файл *.cpp и в нём уже будет сгенерирована функция слота, в которой я могу написать код.

[ритт]

Я имел ввиду вот какую возможность:
- Создать проект ui формы в Qt дизайнере.
- Связать этот проект с *.h, *.cpp файлами (для Perl с *.pl и т.д.) в которых будет реализация.
- Добавить форме пользовательский слот.
- Перейти в файл *.cpp и в нём уже будет сгенерирована функция слота, в которой я могу написать код.

так уже было и от этого дешёвого трюка уже отказались...

Таже самая картина про исключения. Тезис был, что нет поддержки.

поддержка есть. опциональная. и это хорошо.

[denka]

>> Таже самая картина про исключения. Тезис был, что нет поддержки. Почему этого нет, то это другая история, которой >> наверняка есть обоснование. Но их нет, а это минус.

Обоснуй конкретно в чем минус того что в библиотеке нет исключений.  Кстате в самой либе исключения используются(пройдись поиском) хотя их раз два и обсчелся. Лично я считаю что отствие в библиотеки исключений явный +. Даже если не учитывать возможные проблемы в прошлом с исключениями для других компиляторов надо помнить что Qt используется для разных платформ(как по архитектуре так и по мощности). А вы до сих пор смотрите на Qt как пользователь и разработчик под Windows. Так вот у вас десктоп ПК скажем с несколькими гигагерцами и гигами оперативки и вызвать/обработать исключение для вас ничего не стоит. А как на счет встраиваемых ситсем где каждый мегагерц и каждый метр памяти на счету? Обработка исключения не такая уж и дешевая операция.

>>Я убеждён, что в один момент времени человек разрабатывает код для одного языка. Иметь ui.xml, который будет >>подгружаться к разным языкам не представляется промышленным подходом к программированию. Это первое.

Хочу тебя заверить что в крупном промышленном проэкте может участвовать несколько языков


>>Второе. Код обработчика не предлагается сохранять в ui.xml. Я имел ввиду вот какую возможность:
>>- Создать проект ui формы в Qt дизайнере.
>>- Связать этот проект с *.h, *.cpp файлами (для Perl с *.pl и т.д.) в которых будет реализация.
>>- Добавить форме пользовательский слот.
>>- Перейти в файл *.cpp и в нём уже будет сгенерирована функция слота, в которой я могу написать код.

Ты удивишся если глянеш на дизайнер для 3 QT. Правда слот там добавлялся в *.h