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

>Ну да, а такой простой вещи, как multicolumn list view сделать не в состоянии.

Это уже сто лет как задепрекейтили

Qt - хорошая вещь если используешь плюсы. Но мне больше нравится gtk, хотя бы из-за gtk#.

>qt таки так и не стал DE образующим тулкитом (кроме как KDE - а это как несчастный случай и как пример бестолкового управления работами и ресурсами)

По крайней мере, KDE 4 - это реальность, а не vaporware, как Gnome 3

>Но мне больше нравится gtk, хотя бы из-за gtk#

А Gtk# востребован где-нибудь в ынтерпрайзах?

Если про haskell... Есть конечно gtk2hs ... Но qt набирает обороты и даже есть qtHaskell, но я его боюсь. Для C++ лучше учить Qt мне кажется.

Пока не очень. Но это скорее из-за неприятия линукса как десктопной пплатформы.

Вообще я сейчас работаю в мелкой фирме, программистом на С#. И в общем-то мы пишем так, что наши приложения вполне можно перенести на моно, а интерфейс на gtk#. Основное делают библиотеки, а интерфейс можно отодрать. Т.е. на линуксы мы не ориентируемся, но в случае чего - готовы.

>возможность сборки без бинарной совместимости, но зато с убраным оверхедом на pimpl

Да сколько там того оверхеда? Ты бы еще преджложил писать без виртуальных методов)

> кроме как KDE - а это как несчастный случай и как пример бестолкового управления работами и ресурсами

толсто же

разработка на Qt идет быстрее, чем на Gtk, так что пример бестолкового управления ресурсами - это как раз Gnome

>Для C++ лучше учить Qt мне кажется.

наоборот

>Пока не очень. Но это скорее из-за неприятия линукса как десктопной пплатформы.

Мы на Qt для embedded разрабатываем

Ну молодцы, а у нас другая ниша - десктоп. А это пока винда, к сожалению или счастию, не знаю.

> но не понимаю почему объект умеющий сигналы и слоты уже нельзя копировать).

А если этот объект имеет соедиенные слоты/сигналы? Такое соединение тоже копировать?

> Ну да, а такой простой вещи, как multicolumn list view сделать не в состоянии.

Странно. У нас все работало еще год назад. Пока на TableView не перешли

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

Use krazy2, Luke

>Очень бесит беспричинное отсутствие нормальной модульности

поясни

А в чём собственно проблема копирования соединений?

Во-первых сборка Qt достаточно монолитна (нельзя просто взять и собрать скажем один только QtGui). Во-вторых расположение некоторых классов в том или ином модуле иногда несколько удивляет. Например что заставляет держать в QtGui QPoint(F) и QPolygon(F)? В-третьих, как я уже говорил, phonon.

Беглый поиск в гугле ничего ценного не дал. Что это?

>Беглый поиск в гугле ничего ценного не дал. Что это?

надо не в гугле искать, а в репах. статический анализ от КДЕ, туева хуча тестов по Qt + некоторые KDE-специфичные

Метаобъектный препроцессор как средство реализации сигналов/слотов (да и всего остального). Накладывает некоторые ограничения. Как там, уже можно сделать шаблонный класс с Q_OBJECT, м?

Виджеты в некоторых местах не особо продуманы (решения в gtk мне больше по душе).

С++, из-за которого хренъ-забиндишь.

Это из того, что сразу пришло на ум

на Ъ-плюсатую gtkmm посмотри, выбора у него нет, видите ли :)

> Это проблема Qt?

Да

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

ООП в манах? А что, было бы клёво, например, того же Буча или GoF в маны разорвать.

Как там, уже можно сделать шаблонный класс с Q_OBJECT, м?

Через Q_INTERFACES можно попробовать, но не гарантирую, что сработает.

Виджеты в некоторых местах не особо продуманы (решения в gtk мне больше по душе).

Виджеты в основном как раз нормальные, основные траблы во всяких view'ах. Сам трахаюсь с некоторыми косяками. Но над новым набором виджетов работа идется http://labs.qt.nokia.com/2009/04/07/item-views-next-gen/

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

Use krazy2, Luke

А подробнее?

> А в чём собственно проблема копирования соединений?

А вы уверены, что все ожидают такого поведения от всех объектов?

>К примеру, в разделе о ListView ни одна тварь не сознается, почему этот view молча игнорирует все столбцы, кроме первого. И только наследственный MFCшник знает, что multicolumn list view — это на самом деле TreeView.

во-первых, для слепых.

http://doc.qt.nokia.com/4.7/qlistview.html

This view does not display horizontal or vertical headers; to display a list of items with a horizontal header, use QTreeView instead.

Для зрячих, но еще не научившихся читать, там есть картинки.

Во-вторых, что за «мультиколоночный список»? Это ушибленные дотнетом так обзывают обыкновенную таблицу, чтобы умнее выглядеть?

>«Вещь в себе» — отсутствует интеграция с внешним миром и другими библиотеками

кто запретил использовать внешние библиотеки? И какая тебе нужна с ними интеграция?

>Qt монструозно.

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

> Накладывает некоторые ограничения.

Дает некоторые возможности

Как там, уже можно сделать шаблонный класс с Q_OBJECT, м?

Можно. Но это как ремонт двигателя через выхлопную трубу

> на Ъ-плюсатую gtkmm посмотри, выбора у него нет, видите ли :)

И под какие ОС он работает. И где он более или менее нативно выглядит, кроме linux'а?

> А что, было бы клёво, например, того же Буча или GoF в маны разорвать.

Ну примерно тоже самое. Ман пишется по маленькой функи. А тут пкуча всего написано. Хотя да, многое можно было бы еще написать.

> Через Q_INTERFACES можно попробовать, но не гарантирую, что сработает.

Это как раз не то, что хочется

> И под какие ОС он работает

Под мейнстримовыми работает

И где он более или менее нативно выглядит, кроме linux'а?

Заезжанный баян :)

> Во-вторых, что за «мультиколоночный список»? Это ушибленные дотнетом так обзывают обыкновенную таблицу, чтобы умнее выглядеть?

Ну если по честному, то table view иногда немного ущербен

И, да, куте выглядит не особо роднее.

> Под мейнстримовыми работает

Я этот gtk у себя с mac os видел. Она до сих пор через X там отрисовываеться. Qt уже давно с карбона на какао перебрались, а это еще из 80 не вылезло.

Ну блин напишите уже свой itemview с б&ш

Ну, порт gtk-1.2 на cocoa был уже и давно, а вот 2.0 нестабильное ещё :)

Ну это-то сомнительный аргумент. В C++ можно самому определить копирующий конструктор, причём при желании реализующий довольно нетривиальное поведение. Это же не повод не копировать объекты? Я серьёзно не вижу причин для того чтобы «я умею сигналослоты», «я умею Q_PROPERTY» и «меня и моих потомков нельзя копировать» не разнести в три макроса. Скорее всего они есть и носят чисто технический характер, но мне они не известны.

Вот это корм

В C++ можно самому определить копирующий конструктор, причём при желании реализующий довольно нетривиальное поведение.

Можно. Но при этом надо скопировать QObject. А вот как копировать его? Объект на низком уровне не должен думать о том, что хочет объект выше.

Это же не повод не копировать объекты?

Повод. Потому, что нельзя понять, какое поведение должно быть у QObject'а при копировании. (я говорю про сигналы/слоты)

Скорее всего они есть и носят чисто технический характер, но мне они не известны.

QMetaInfo

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

> Ну блин напишите уже свой itemview с б&ш

QTreeView меня всегда спасал

>Если про haskell... Есть конечно gtk2hs ... Но qt набирает обороты и даже есть qtHaskell, но я его боюсь. Для C++ лучше учить Qt мне кажется.

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

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

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

На винде GTK нормально выглядит только после танцев с бубном, на макоси - до Qt как до Луны пешком

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

а так же Perl, Lua, и еще много чего

>Во-вторых, что за «мультиколоночный список»?

Ууу, как все запущено. Ты первый раз за компьютер сел вчера? Multicolumn list view — это многоколоночный список. Таблица — это таблица. На пальцах для самых сообразительных: список состоит из последовательных «записей» (item), таблица же состоит из разреженных (опционально) ячеек данных (cell).

>С++, из-за которого хренъ-забиндишь.

Существоание SWIG ставит под сомнение этот тезис

>Multicolumn list view — это многоколоночный список. Таблица — это таблица. На пальцах для самых сообразительных: список состоит из последовательных «записей» (item), таблица же состоит из разреженных (опционально) ячеек данных (cell).

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

>Doxygen'овское говно — это бред сивой кобылы, а не документация

Если ты написал там бред, кто в этом виноват?

И так не один я считаю, кстати

Конечно, миллионы мух не могут ошибаться.

>SWIG

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

>В нормальных библиотеках. В boost, например.

Кто мешает использовать Qt и Boost вместе? можешь хоть буствоские сигнал и слоты использовать в Qt-шном коде, читай доки внимательнее