>Почитал... Мда... Человеку надо было использовать Borland C >Builder... ;-) Весь его рассказ о преимуществах qt - фактически >рекламма VCL... ;-)
>Только вот:
>connect( button, SIGNAL( clicked() ), SLOT( action() ) );
>И это ООП? 8-()
И это ООП!!! А не Delphi ;)
>button.OnClick:= !!! :-P
А QT Designer так может
>+ man Action...
>А вот этого я не понял:
>button = new QPushButton( "button text", MyParentWidget);
>А что, в qt есть ненажимаемые кнопки? 8-()
:)))
P.S. Как можно сравнивать QT и WindowsForms ? WindowsForms имеет
OpenGL, networking (server,client (TCP, UDP)), XML ...?
> Думать ты можешь все что угодно. Только взрослым солидным дядям
> твои думки абсолютно по барабану.
Дык взрослые солидные дяди воопще ложили и на МФЦ и на КуТэ, для них главное это скорость написания и стабильность работы программы...
> Да, когда аргументов по существу не хватает, то начинается совесный
> понос.
Хм... Ну вот про словесные поносы, я бы промолчал... Так как неИМХО а так сложилось, что Микрософт технологии покупает компаниями...
> Малыш, когда серьезный софт, который используют взрослые дяди будет
> переведен на VCL, тогда и поговорим. Я думаю завтра в четверг,
> после дождичка. А пока расти большой и свои гормональные комплексы
> не переноси на какую-то там MFC.
Вот именно "на какую-то там MFC"... Просто все дело в том, что МФЦ устарел. Нет он не такой уж и плохой, просто он устарел, и ему пора в гроб(о чем подумывают некрософтовцы). Будущее Некторотеха за .НЕТ. Хотя в этом аспекте я могу и ошибаться...
> что лучше всего использовать как GUI в связке c Perl'ом?
use Qt;
my $a = Qt::Application(\@ARGV);
my $hello = Qt::PushButton("Hello World!", undef);
$hello->resize(160, 25);
$a->setMainWidget($hello);
$hello->show;
exit $a->exec;
> что лучше всего использовать как GUI в связке c Perl'ом?
я 2 года писал на Perl/Tk для баз данных (программы без правки кода работают на win (ActivePerl) и на linux, но надо заранее подумать о кодировках), хорошо выглядит Perl/Gtk, Perl/Qt я не смотрел
Уважаемай анонимус, сначала предьявите созданное вами хоть что-нибудь, имеющее хотя бы близкое кол-во пользователей, а потом мы поговорим - что есть лол, ок?
P.S. По остальным пунктам, как я понимаю, возражений нет?
Незнаю, если бы ты сначала _прочитал_, а потом "комментил", то увидел бы, что я говорю про Borland Delphi/Builder VCL, в котором очень даже есть и "networking" и "XML". А для особых любителей - с боку прикручен "OpenGL".
>> Как можно сравнивать QT и WindowsForms ?
>Незнаю, если бы ты сначала _прочитал_, а потом "комментил", то увидел бы, что я говорю про Borland Delphi/Builder VCL, в котором очень даже есть и "networking" и "XML". А для особых любителей - с боку прикручен "OpenGL".
В те очень далекие годы, когда NT 4.0 считался верхом крутости и стабильности, помниться я эксперементировал с перерисовкой приложения.
Рисовал шестигранники, кокойто из виндовых функций, и вдруг NT упал и
откинул копыта - посинел весь бедненький. И так несколько раз, начал я
проверять код, и увидел, что я не инициализировал толщину линии карандаша(в одной из winapi функций), она принимала не вероятное значение, MFC не проверяя отдавал скармливал это винде, и у той случалось несварение желудка.
Сами делайте выводы, насколько MFC хорош или плох.
Знаете, а вот не исчерпал.
Так что... может конечно я вас оскорблю этой мыслью своей убогой, в клинч как говорится вгоню, но уж звеняйте.
При всей "убогости" MFC, и всей "обджектной крутости" Qt, есть один немаловажный фактор успеха - количество программ написаных с помощью этих библиотек.
Можно конечно копытом землю рыть,и доказывать как Qt делает MFC, как оно ващщщее все там круто на... но письку мерить все равно линейкой придется.
И кажется мне что при всех недостатках MFC делали ее именно так как устраивало на тот момент - не "парясь" о мегаобжектфичах.
> 3. Типа вывод (тавтологический). Любой кросплатформенный тулкит будет работать медленнее нативного. Кросплатформенность хороша для веб-интерфейса.
Я тут даже спорить не буду. Но дело всё, как мне кажется, в том, что сегодня скорость разработки программы часто оказывается важнее скорости работы программы. А уж про интерфейс -- он интерактивен по сути, и после некоторого порога человеку уже всё равно, отрисовался элемент за 1E-5 сек или за 1E-7 сек, для него это одинаково "мгновенно". И если тормоза Java я ещё могу наблюдать визуально, то тормоза KDE (3.4.1) уже нет. Я тут ещё долго обобщать могу :) Но всё-таки, конкретно про "событийный потоп" можно прояснить про что именно речь?
>Но всё-таки, конкретно про "событийный потоп" можно прояснить про что именно речь?
Наверное, имелось в виду, что события циклически вызывают друг друга, так что их количество увеличивается в геометрической прогрессии:) Хотя может быть, имелось в виду что-то совершенно иное.
Угу, оно и чувствуется... Чисто методов не хватило, потребовалось ещё и функцию вкорячивать...
> Это тоже ООП. Но кривое какое-то:)
Уровень оценен. С этим - к geek'у...
> Кроме QPushButton (обычная кнопка)
Спасибо за экскурс. Я спрашивал зачем было называть именно PushButton. Излишняя сущность неявно подоразумевает, что есть просто QButton... Вот вам и логика qt...
> Верно, qt - это не правильный тулкит, а самый правильный фрэймворк:)
Блин, этой статье уже несколько лет и здесь и на kde.ru она пробегала неоднократно. И если Вы все еще пишете на MFC, тогда... я Вам очень сочувствую. Я по счастью никогда не писал ;-)
Кто-нибудь из лоровцев знает такой GUI FrameWork или кому нравится toolkit, который был кросплатформенный на такие платформы Unix, Windows 98/NT/XP и самое важное на WINDOWS CE, Windows mobile в добавок. Или есть такой напильник, который может заставить Qt под CE, mobile работать?
Сейчас юзайем поделку, собственной разработки ( которую наваяли за три дня).
И ещё вопрос: если в qt нативная поддержка skinned примитивов?
> connect( , , ) --- это метод базового класса QObject.
Метод? Тогда его как-то странно вызвали... Или - чудеса препроцессора? ;-)
> Класс QButton наследуют QCheckBox, QPushButton, QRadioButton и QToolButton.
Понятно... Хотя для общего предка могли бы как раз понепрезентабелнее название задвинуть, бо его всё равно не создают впрямую... Хотя... Пусть называют как хотят, не мне пользовать...
> Но C++ - не хочу. Для работы - только C++. Для себя - не хочу.
Это правильно C++ - изврат над логикой. А время компилирования програм ого как долгое. Аизучение исходников - вообще занятие тоскливое. А шаблоны нужно включать как хедеры и компилить заново.
А если кому нравится классы, пожалуйста - берите далацте сишный файл (aka class). Это же элементарно просто. А с++ - ето изврат.