Qt доступна теперь и под LGPL

Все говнокодеры пишут на C# и расхваливают его на каждом шагу, а нормальные пацаны курят C++ потихоньку, знают его плюсы и минусы, таки да, прогресса это не добавляет потому что ЧСВ зол. Ты вот например трындишь тут - а даже простейшим проектом не займешься, нашел бы чёнить полезное для себя и для людей да поисправлял бы багов.

>ублюдочный синтаксис

И чего там ублюдочного, если принимать во внимание то, что Лисп - функциональный язык? Писать императивно - да, неприятно.

> И чего там ублюдочного

То, что нет его. Еще лично мне не нравится то, что пришлось изобретать специальные формы.

> Лисп - функциональный язык

Ну, я оставлю твою тушку на растерзание фанбоям Лиспа, ежели таковые появятся здесь :)

А ссылки на функциональную природу не катят - у *ML и Haskell синтаксис есть.

>Но компилятора из тех лет под рукой нет.

аналогично. так что замяли.

точнее, что-то древнее у меня есть, но оно не собирается. а читать я это не буду, это ж не манга.

>А с Лиспом всего 2 проблемы - ублюдочный синтаксис и отмороженные на всю голову фанбои ;)

одна. только вторая. первая иллюзорна и без труда решается. %-)

говно, слейся назад в унитаз. твоя телепатия работает херово.

А тем временем...
"Проект Ubuntu Mobile рассматривает возможность перехода на Qt/KDE"
http://www.opennet.ru/opennews/art.shtml?num=19863
"Разработчики Ubuntu Mobile заинтересованы в интеграции более совершенной, чем Hilton, системы экранного ввода. В настоящее время компании Nokia и Intel уже интенсивно работают в плане замены Hildon, выбор Ubuntu скорее всего будет зависеть от того, как в дальнейшем будет развиваться ситуация. Кроме системы ввода, отмечается, что приложения KDE лучше адаптируются для низких экранных разрешений, по сравнению с GNOME."
--
гтк/гномокапец уже на горизонте!

>на него балкон упал — глядишь, сейчас писали бы на ObjC.

почему не пишите ?
ObjC доступен. уже ооочень давно
пишите, Ёмое, или плохому танцору ... мешают ??
пишите шура, пишите

лолшто?)

дебил, иди к боженьке. если твои дерьмоподелки можно напилить в одиночку со всеми бибилотеками — это не значит, что остальные тоже занимаются «чистилками реестров» и калькуляторами со скинами.

протелепать, мразота. ты же считаешь, что у тебя это офигенно получается.

>Но потом Си и Си++ пошли разными путями, что прискорбно. Shit happens.

Нет, ну а как они могли пойти одним путем? И что это за путь такой?

>> Но потом Си и Си++ пошли разными путями, что прискорбно. Shit happens.

> Нет, ну а как они могли пойти одним путем?

Как раньше ходили.

> И что это за путь такой?

Сохранение Си99 как подмножества. Или хотя бы адаптация популярных фишек Си99.

Упс. Пошёл гуглить.

Вопрос встречный - какую из популярных фишек си99 пожно назвать наиболее, на твой взгляд, удачной?

> какую из популярных фишек си99 пожно назвать наиболее, на твой взгляд, удачной?

Именованные инициализаторы.

Ну, неэффективный возврат объекта класса это известный косяк C++... Однако костыли придумали.

А вообще ты прав. Кстати, причина непринятия расширения языка для поддержки данной фичи так и не понятна мне.

Насчёт операций выделения подстроки и т.п.: Что-то я не вижу упоминаний что сейчас фактически ASCII строк нету - де-факто стандарт сейчас UTF8, а это кодировка с переменным числом байт на символ. И поэтому знание длины строки (в байтах и символах) и знание конца строки (указатель на конец массива как в D) не помогут найти вам найти m-ый символ в n-ой строке без сканирования m или n-m символов.

только очень больные люди хранят строки, с которыми активно работают, в utf. все нормальные преобразовывают в ucs и дальше работают с ucs.

>и именно тут сигналослоты через moc не при чём, а при чём то, откуда в moc первая буква. это уж не говоря о том, что «динамическая загрузка форм» не нужна чуть менее, чем полностью

за всех не говорим, ага?

>потому что не type safe. однако кто мешает расширить libsigc++ для рантаймового привинчивания обработчиков (костылище!)?

маководам про это расскажи, поржут :) У них большинство "по соглашению" вызывается

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

то есть, рисование форм и логики к ним на QtScript'е не делал никогда? И какая разница, за врапперы ты будешь дёргать из ecmascript или за Qt слоты? В ecmascript статической типизации — того, нету :)

Вот что бы жизнь не испортило — так это тулза типа lint, которая проверяла бы статические connect'ы на валидность, чтобы их в рантайме не ловить. А от гибкости отказываются только му^W недалёкие )

>за всех не говорим, ага?

а зачем оно надо?

>маководам про это расскажи, поржут

я как-то фигово понял: мы тут о Qt и C++, или нет?

>то есть, рисование форм и логики к ним на QtScript'е не делал никогда?

формы на js — идиотская идея изначально. коли уж понадобилось — врапперы для нужных виджетов и универсальный callback-диспетчер.

>Вот что бы жизнь не испортило — так это тулза типа lint, которая проверяла бы статические connect'ы на валидность

а меня вот задолбало каждый раз перечислять руками типы параметров в connect. я не понимаю, почему за меня это не может сделать moc. пусть сам разбиравется. ублюдочная реализация, ублюдочная — я должен делать за машину то, что она может и сама. слава робатам, смерть чилавекам, чилавек должен служить машине.

> В ecmascript статической типизации — того, нету :)

Того, есть. Опциональная и только в новом стандарте, но есть. Видать, не всех устраивает "по соглашению". Или за маководов думает Жопс?

> Опциональная и только в новом стандарте, но есть

в Qt-то нет :D

> Видать, не всех устраивает "по соглашению". Или за маководов думает Жопс?

оно не для всего подходит. Но для гуя — песня. Качество мак-софта какбэ подтверждает :)

>а зачем оно надо?

чтобы не пересобирать продукт, когда у заказчика левая пятка зачесалась. Вообще, скриптовая бизнес логика и богатая платформа — это Ъ.

>я как-то фигово понял: мы тут о Qt и C++, или нет?

про программирование «по соглашению», как сделаны сигналы и слоты Qt. И, _внезапно_, не только они )

>формы на js — идиотская идея изначально. коли уж понадобилось — врапперы для нужных виджетов и универсальный callback-диспетчер

Формы нормальные люди рисуют :) А уж с платформой это увязывается через js

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

потому что есть перегрузка сигналов и слотов. Выкини emacs, и пользуйся QtCreator. Он сам всё подставляет :)

> ублюдочная реализация, ублюдочная — я должен делать за машину то, что она может и сама

не может. Типы параметров входят в прототип функции. Имена сигналов и слотов за тебя додумывать не надо, нет?

>чтобы не пересобирать продукт, когда у заказчика левая пятка зачесалась.

для этого придумали dll/so.

>про программирование «по соглашению»

да? это когда ж про это начали?

>А уж с платформой это увязывается через js

и Objective C. а не удолбище C++.

>потому что есть перегрузка сигналов и слотов.

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

>Выкини emacs, и пользуйся QtCreator.

оно неюзабельно и дичайше тормозит даже на моём core 2 duo с четырмя гигами RAM.

>не может. Типы параметров входят в прототип функции.

а. то есть, прототип узнать никак нельзя? о, ужас… как только пишут компиляторы в таких условиях…

>Выкини emacs, и пользуйся QtCreator.

>оно неюзабельно и дичайше тормозит даже на моём core 2 duo с четырмя >гигами RAM.

QtCreator отличная, весьма удобная IDE для Qt к тому же не тормозит в отличае от других

Причем компьютер у меня весьма старенький по сегодняшним меркам :

Celeron 1200 Mz , ОЗУ 256 Mb QtCreator работает весьма быстро, например автодополнение кода срабатывает мгновенно в отличае от NetBeans или Eclips с интергаторам, где оно срабатывает через несколько секунд.

да плевать мне на автодополнение, если основной инструмент — редактор — обладает дичайшим latency. настолько дичайшим, что я такого больше нигде и не видел.

>да плевать мне на автодополнение, если основной инструмент — редактор — обладает дичайшим latency. настолько дичайшим, что я такого больше нигде и не видел.

4.2

я рад, что ты лучше меня знаешь, как оно работает. я так думаю, моего core 2 duo 3GHz и 4GB RAM маловато, видимо, чтобы этот мегаинструмент не тормозил.

Моих 2.66 ghz и 1 гб DDR-300 хватает с избытком. ЧЯДНТ?

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

>видимо, ты никогда не работал с редактором, который отзывается сразу, а не думает о чём-то. FTE, например. после FTE задержки очень раздражают.

Да, по сравнению с ним медленнее, когда где-то на стыке элементов языка находишься. Но "дичайшими" бы я эти задержки не назвал, по сравнению с эклипсом вообще мелочи.

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

Относительно холивара. Могу предупредить что я гномер. Использую из-за субъективного вкуса. Просто полностью кастомизированный Гном для меня красивее и удобнее полностью кастомизированого КДЕ 4. При этом не отрицаю что оба DE являются прекрасно сбалансированными. Объясню почему начинаю не с тулкита, а именно с DE. Дело в том что несмотря на разные способы наложения тем GTK приложение ass ugly в КДЕ, а Qt - ass ugly в GNOME. Человек выбирает один десктоп и соотв-но тулкит, настраивает его, а движок тем другого тулкита отаются забытыми. Вот и частный случай из за которого в 95% случаев пользователь говорит "Кopete - говно, Pidgin - лапочка" или наоборот. Сюда идут парами за ручку Nautilus-Konqueror/Dolphin, Firefox-Opera, Brasero-K3b, Abiword-KOffice, Gnome Terminal-Konsole. Второе: загрузка. Часто GTK приложение юзает GNOME по полной программе, и так же Qt app использует KDE. Мы получаем лишние 10 сек загрузки, от которых наш родной рядовой пользователь делает выбор.

Поэтому считаю отделять обсуждение тулкита от DE умесным только на не Unix платформах. Я имею опыт разработки в обоих тулкитах и с радостью предпочел бы любой из них вместо WinAPI, MFC и wxWidgets. Вот мой ИМХО, кроме всех известных мнений которые вы можете по 100 раз прочитать в Инете.

Qt:

+ Интегрированность всех компонентнов в малом количестве либ. Очень удобно при сборке тулкита на не Unix. Тем более таскать целую иерархию каталогов для одной несчастной демки считаю накладным. Конечно на Unix что Gtk, что Qt - просто пакет который легко ставится любым способом.

+ Более мощная часть отрисовки ГУИ. Приятно что native код шагнул так далеко в современный GUI и Qt может так же красиво рисовать как WPF под .NET, Swing и JavaFX под Java Runtime, а также Flash. До этого прекрасная анимация была прерогативой только вышеперечисленных библиотек, а в native-code приходилось использовать "серые" библиотеки или писать с нуля на DX/OpenGL.

+ qmake. Удобная система управления проэктом.

+ Остальной инструментарий в виде дизайнеров и IDE. Все от одной компании и прекрасно интегрированно.

+ Платформа, а не ГУИ тулкит. Я на мог поверить что Gtk и GLib и вообще во всем наборе нет инет сокетов и нужно использоать непереносимые на 100% (многого захотел) Berkeley Sockets для работы с сетью

+ Qt может стать лидирующей платформой портативных телефонов и смартфонов, позволив писать приложения так же легко и надежно как на Java, но не под управлением виртуальной машины.

- Зависимость от препроцессора. С++ был создан частично для того что бы избавить С от экстенсивного использования препроцессора. Одно дело препроцессор компилятора, но внешний препроцессор - это слишком. Учить еще его особенности поведения и отходить от стандартов языка - камень преткновения к портабельности программ на экзотические машины и компиляторы.

- Отсутсвие любви со стороны монстров индустрии таких как Red Hat, Sun, Intel, Motorola и т.д. Поскольку их мощности превышают Nokia с головой, то смерть Qt - очень маловероятна, но GTK - невозможна. просто компании не любят зависеть от собственности одной какой то компании. Сразу вспоминается как компании типо IBM и Intel коммитами лихо поддержали Linux вместо Солярис и Виндовс. Как только GTK станет отставать от Qt в большинстве возможностей реально, а не с личной точки зрения школьников Новой Гвинеи, будет сильнейшая волна commit'ов и конференций со стороны вышеперечисленных компаний. И сейчас вырисовывается такое отставание. Можно ждать GTK 3 с более сильным резонансом и скачком, чем после появления Qt4. Увы при у кого больше денег, тот заказывает музыку и Nokia чуть-чуть победнее почти всей IT индустрии.

- Концепция OOP-only. Навязывать что-то не явлется правильным шагом и может служить проблемой для некоторых приложений, для которых лучше всего подходит С или другой не ОО язык.

GTK: + Суперпортативность. Тулкит портирован на самое большое количество платформ и имеет самый большой список binding'ов.

+ Простой функциональный интерфейс позволил тулкиту быть легко переносимым и привязываемым

+ Изначальная нацеленность на удобство пользователя и простоту интерфейса (философия GNOME, потом HIG) позволяет дизайнеру больше уделять внимание сути окна, а разрешить менеджеру разложить окна учитывая особенность монитора, платформы. Аналогия с Latex, когда человек пишет содержание книги, более полагаясь на менеджер по Layout для корректного и качественного отображения. Конечно и Qt сейчас обладает теми же возможностями, но GTK/GNOME имеет к этому же и философию легкого и удобного интерфейса.

+ Концентрация на содержании больше чем над отображением, позволила появиться таким проэктам как Cursed GTK, позволяющем без особых усилий переносить GUI приложения на консоль. http://whatsup.org.il/dittigas/Dittigas_GTKCursed_demo_rozdily.png

+ Будучи детищем GNU имеет прекрасную интеграцию с GNU ПО (pkg-config, autotools, GNOME, gcc, gobject, glib) которое является де факто стандартом Unix систем.

+ Тогда когда Qt предлагает клас (что было плюсом в предыдущем пункте) для решения проблемы, gtk не изобретает велосипед и отправляет разработчика использовать отдельную lib* (libpng, libxml2), обладающую более серьезными возможностями, что часто сподвигает разработчика на более продвинутые функции приложение.

- Пока что в возможностях анимации остается желать лучшего. Когда уже много лет люди используют самые серьезные 3D эффекты на своих десктопах и даже Windows не выглядит так серо, то движок тем GTK остался в 20 веке.

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

- Иерархия библиотек из которой состоит GTK сильно отпугивает разработчиков маленьких программ для не Unix систем.

- Технология сборки мусора системы glib, которой подвержены обьекты glib, является феноменом ставящей в один ряд ANSI C с мощными платформами как .NET и Java. Но к несчастью такие обьекты трактуются как потеряная память популярными отлаживающими программами. Пример, valgrind. После работы Gtk по мнению отладчика память замусорена так, что удивительно как работает еще машина. Конечно на сайте GNOME обьясняется, что за "мусором" надежно следит glib и боятся нечего, но как же узнать о настоящем мусоре? Существуют методы решения проблемы сильно замедляющие отладку.

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

vertexua

>>Тулкит портирован на самое большое количество платформ

Список в студию. Если считать платформу как
== дистрибутив+компилятор, то Qt портирован на

aix-g++        hurd-g++       macx-xcode      win32-msvc.net
aix-g++-64     irix-cc        macx-xlc        wince50standard-armv4i-msvc2005
aix-xlc        irix-cc-64     netbsd-g++      wince50standard-armv4i-msvc2008
aix-xlc-64     irix-g++       openbsd-g++     wince50standard-mipsii-msvc2005
               irix-g++-64                    wince50standard-mipsii-msvc2008
cygwin-g++     linux-cxx      qws             wince50standard-mipsiv-msvc2005
darwin-g++     linux-ecc-64   sco-cc          wince50standard-mipsiv-msvc2008
               linux-g++      sco-g++         wince50standard-sh4-msvc2005
               linux-g++-32   solaris-cc      wince50standard-sh4-msvc2008
freebsd-g++    linux-g++-64   solaris-cc-64   wince50standard-x86-msvc2005
freebsd-g++34  linux-icc      solaris-g++     wince50standard-x86-msvc2008
freebsd-g++40  linux-icc-32   solaris-g++-64  wince60standard-armv4i-msvc2005
freebsd-icc    linux-icc-64   tru64-cxx       wincewm50pocket-msvc2005
glibc-g++      linux-kcc      tru64-g++       wincewm50pocket-msvc2008
hpux-acc       linux-llvm     unixware-cc     wincewm50smart-msvc2005
hpux-acc-64    linux-lsb-g++  unixware-g++    wincewm50smart-msvc2008
hpux-acc-o64   linux-pgcc     win32-g++       wincewm60professional-msvc2005
hpux-g++       lynxos-g++     win32-msvc      wincewm60professional-msvc2008
hpux-g++-64    macx-g++       win32-msvc2002  wincewm60standard-msvc2005
hpuxi-acc-32   macx-icc       win32-msvc2003  wincewm60standard-msvc2008
hpuxi-acc-64   macx-llvm      win32-msvc2005
hpuxi-g++-64   macx-pbuilder  win32-msvc2008

>>и имеет самый большой список binding'ов

из которых используется только PyGTK?

>>+ Тогда когда Qt предлагает клас (что было плюсом в предыдущем
пункте) для решения проблемы, gtk не изобретает велосипед и
отправляет разработчика использовать отдельную lib* (libpng,
libxml2), обладающую более серьезными возможностями, что часто
сподвигает разработчика на более продвинутые функции приложение.

Qt предлагает класс, когда не нужна детальная работа с сущность. Если
нужно просто загрузить изображение - есть QImage. Если нужно
загрузить не просто, тебя никто не ограничивает использовать libpng.
QtXML это вообще галимый expat, только на C++.

Gtk работает везде где есть XServer, ну еще плюс Windows и MacOSX (сдесь не знаю через Х или нативно). Жаль списка компиляторов не могу предоставить. Не думаю что его кто-то составлял )

> из которых используется только PyGTK?

Источник настолько точной информации в студию ))))))

gtk-qt-style не? никак? я как-то давно уже не разбираюсь, на чём там что напилено — выглядят-то практически одинаково.

>MacOSX (сдесь не знаю через Х или нативно).

У сожалению, через X. Поэтому гимпом пользоваться неприятно. Qt — нативно. В 4.5 — вообще, совместно с Cocoa