Тем кто не любит Qt.

>Костыль и лишний слой

/me затрудняется ответить, в чем может быть проблема с кодогенерацией, которую раз настроил и забыл

http://www.linux.org.ru/jump-message.jsp?msgid=5539478&cid=5544017

Ну вот лазаю по svn'у KDE и не нахожу.

не задавался вопросом, где находится его svn или чего они там используют

> Используй krazy2, namezys

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

> Я не понял, тебе трудно настроить в таблице поведение выделения?

А таблице нельзя настроить поведение выделение current item'а

посмотрел в мане, вот:

http://websvn.kde.org/trunk/playground/base/kdetestscripts/

> Кто мешает использовать Qt и Boost вместе?

Кстати, они у меня нормально живут. И сигналы/слоты из boost'а тоже

http://doc.qt.nokia.com/4.6/qabstractitemview.html#setSelectionModel

Надо не selection, а current. А вот current может быть только один

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

толстый он. И с каждой версией всё толще. Те же fltk, fox toolkit, Ultimate++, wxWidgets поскромнее будут. Или вообще какой-нибудь минималистичный GUI тулкит.

Хотя, с современными винчестерами это non-issue. У Qt отличная документация, и в целом довольно неплохо отлажен. Плюс, это не только GUI тулкит, а ещё много всего (это же минус, если это «много всего» в приложении не нужно, но плюс, что не надо изобретать велосипед).

но сейчас практически все пишу на С++ с использованием Qt (если требуется и оправдано, конечно). Возможно, я упустил из виду другие интересные и удобные средства разработки.

все их освоить всё равно нужно много времени. Если время девать особо некуда, попробуй написать свою задачу сначала на Qt, потом на каком-то другом тулките Ultimate++/wxWidgets/fltk, и сравни ощущения.

Нука, покажи мне по ООП документацию такую

Мне документация по bada очень нравится например

> Мне документация по bada очень нравится например

Она написана в стиле ман? или в обычно для ООП стиле (описание, общие замечания, потом перечисления методов)

http://dpimg.ospos.net/contents/docs/resources_1.1.0/com.osp.apireference.hel...

Хз, как по другому еще ООП описать.

>Кстати, они у меня нормально живут. И сигналы/слоты из boost'а тоже

Эт получается ты можешь прицепить кутешный слот на бустовский сигнал? :)

Этож банальный Doxygen со свистоперделками.

Это банально понятная документация.

Не, я согласен что документация хороша.

>список состоит из последовательных «записей» (item), таблица же состоит из разреженных (опционально) ячеек данных (cell).

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

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

>Плюс, это не только GUI тулкит

это совсем не гуй-тулкит ;)

Я так вижу ты бывший делфифаг.

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

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

Невозможностью выбора отдельной колонки. Hint: в таблице курсор всегда прыгает по ячейкам, подсвечивая активную. Хотя конечно же можно перегрузить какой-нибудь обработчик событий и не реагировать в нем на стрелки влево-вправо, но нахрена мне такой костыль, когда в gtk все работает искаропки и с нормальной документацией в отличии от доксигеновского кутешного полубреда?

>Если я правильно понимаю, вменяемые биндинги Qt есть только под питон. Так вот... qtHaskell страшнее даже невменяемых биндингов

Да вот да ... я потому и говорю о gtk2hs )

>когда в gtk все работает искаропки и с нормальной документацией в отличии от доксигеновского кутешного полубреда?

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

Как минимум предупреждать о несоответствии сигнатуры сигнала слоту и как максимум сообщать о соответствии сигнала/слота отправителю/получателю. Но вообще сигнатура сигнала/слота на момент компиляции может быть просто не известна. Я не помню, если в connect'е опустить слова SIGNAL/SLOT, будет ошибка компиляции или нет?

QPoint - QtCore.

>>готовое приложение со всеми либами - 13 метров (гуй, сеть, xml и еще по мелочи). Пиши еще.

хотя если вспомнить нямку в виде MASM32, где оконное приложение занимало 5 Kb... :)

Но вообще сигнатура сигнала/слота на момент компиляции может быть просто не известна. Я не помню, если в connect'е опустить слова SIGNAL/SLOT, будет ошибка компиляции или нет?

Прочти сначала как работает connect, какие параметры принимает.

> хотя если вспомнить нямку в виде MASM32, где оконное приложение занимало 5 Kb... :)

а почему именно MASM32, а не С + WinAPI - ассемблер типа круче? люди даже на дельфи умещались в несколько Кб при прямом пользовании WinAPI

Потому что такие дебилы, не умеющие пользоваться objdump и не представляющие себе устройство PE файла, попадаются только разве что среди осэмблерщиков и вот, да, дельфистов.

Qt - говно.
Причины тут уже назвали:

1) C++
2) C++
3) Убогая объектная модель и куча костылей, но это по причине 1 и 2.

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

Какие существуют нормальные языки, кроме Святого Лиспа?
//Кроме плюсов вполне сносно могу писать на чистом С.

Сначала выучи CL, потом сам поймешь. И не надо как малолетний долбоеб кидаться фразочками с lurkmore.ru

Впрочем, кривые и кастрированные подобия CL, вроде Ruby, Python, или даже C# и Java - тоже всяко на порядок лучше, чем C++

На Си же вообще писать не надо, если пишется не ядро ОС или драйвер к нему.

ТЫ просто настолько туп, что плюсы для тебя только мечта!

TreeView полностью удовлетворяет твоим запросам.

Тролли уже не те пошли, эх.

QPoint - QtCore.

А QAbstractProxyModel, QSortFilterProxyModel, ещё ряд моделей - в QtGui. Вопрос: НАФИГА?

> GTK делали выходцы из мира ассемблера и С. Так чтоб выбора нет

Это очень плохо? Каждый, кто разбирается в ассемблере и в Си (а разбираться там особо не в чем), сможет без проблем разобраться в GTK+.

Скажу проще, GTK+ и компания - это подход KISS, Qt - это мощный, но также необоснованно сложный вариант.

И да, для кросс-платформенного софта (если реально требуется кросс-платформенность) лучше использовать Qt, для Linux-only лучше использовать GTK+. Вот вам и выбор.

компилятор С/C++ может добавлять свой код в программы, на masm32 кода получалось меньше всего.

>А QAbstractProxyModel, QSortFilterProxyModel, ещё ряд моделей - в QtGui. Вопрос: НАФИГА?

Запусти Qt Assistant и просветись на тему MVC. Или List/Table/Tree views по-твоему в QtGui быть не должно?

> А также man'ы из 2-го и 7-го разделов.

Что не так с man 3?..

Уже пришел со школы?

это же не view, а модели, они не привязаны к GUI. QAbstractProxyModel действительно находится в QtGui, надо у них спросить почему.

>хотя если вспомнить нямку в виде MASM32, где оконное приложение занимало 5 Kb... :)

да да, и графическая ОСь на дискете. Это все круто, но только в качестве красноглазия на досуге.
А говорить о жироности Qt, при этом сравнивая его со всякими жабами-дотнетами, это даже не троллинг, это какой-то детский лепет.

это же не view, а модели, они не привязаны к GUI. QAbstractProxyModel действительно находится в QtGui, надо у них спросить почему.

Модели существуют для отображения их в view. Поэтому без самого view необходимость в модели отпадает. Вот.

>>Модели существуют для отображения их в view

Модели существуют для хранения данных. Логично поместить их все в QtCore.

> говорить о жироности Qt, при этом сравнивая его со всякими жабами-дотнетами,

кстати, сколько весят исходники OpenJDK в куче? исходники Mono имхо покомпактнее будут

> компилятор С/C++ может добавлять свой код в программы, на masm32 кода получалось меньше всего.

а ты скажи ему -nostdlib -nostartfiles -nodefaultlibs, и не будет добавлять. Или, С runtime library (частично libc, частично Libgcc) похакай.

на masm32 кода получалось меньше всего.

real teensy elf executables ещё меньше, за счёт того что заголовок с кодом перекрывается. Ну и?

Модели это части паттерна MVC, который Model-View-Controller.

В этом паттерне одно без другого смысла не имеет - паттерн направлен на разделение логики и интерфейса(и в частности, гуя) - и если например интерфейса нет, нахрена что-то разделять то, и плодить всякие там модели? Поэтому вполне логично, что и Model, и View хранятся в гуевой подсистеме Qt.