Qt Project жив!

Какая связь между осиливанием и навороченностью?

Так предложи. Ради такого же qt-project и задумывался!

Не думаю, что они его не сделали, тк поленились, скорее были определенные причины его не делать (начнем с наличия 2х компиляторов под винду - mingw и mcvc - какой вариант включать в редистрибьютабл?)

почему-то сосредоточились на gui, обсуждая qt. формочки для программиста - это не главное. это чуть-чуть чаще всего. хотя и формочки - тоже важно. важно иметь возможность простыми и понятными средствами организовать масштабируемый (в плане геометрии) интерфейс. очень важно, чтобы морда была красивой и быстрой. ни qtk, ни fltk уже не сравнятся с qt в этом плане. удобство программирования на qt и на gtk - не стоит даже начинать спорить. на qt проще. естественно, если задача - не полный примитив типа одного диалога пользовательского ввода (там вообще зачем развитые тулкиты?). в основном же программирование - это работа с файлами, работа с сетью, работа с динамическими объектами в памяти (списки, деревья и проч.), работа с БД. qt это всё покрывает с огромным запасом. в отличие от gtk, fltk. вот загнётся или нет - вопрос. имхо, не стоит ждать. надо просто использовать его. тогда вопрос решится сам собой. лет 5 оно ещё протянет точно. вы рассчитываете, что ваша программа будет активно развиваться 5-10 лет? ну берите себе исходники qt и используйте её хоть 20 следующих лет. оно уже давно годно.

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

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

Но по удобству использования GLib и рядом не стоял с Qt.

Не вижу супер глобальной проблемы. В sdk то обе сборки присутствуют.

Да что за бред? Это ровно про то же, что и говорить, что _каждая_ программа, использующая .Net весит много вместе с .Net. Отключите статическую компиляцию и положите рядом один ДЛЛ.

Ога, только стандартные контейнеры (списки, деревья и проч.) на редкость тормозные в glib, а всё из-за специфики Си.

>почему-то сосредоточились на gui, обсуждая qt. формочки для программиста - это не главное

Потому, что обсуждаем _графический тулкит_. То есть инструмент для создания gui. Создания gui для пользователя. Которым _пользователю_ будет удобно пользоваться.

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

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

А можно пример, в каком приложении можно менять логику?

По идее, в любом web - приложении. Из чисто десктопных - в той же Mozilla с помощью расширений. Ну и разные приложения, настраивающихся с помощью скриптовых языков программирования.

> Покажите, как можно в этой модели изменять состав меню, например, в том числе добавлять те пункты, которые являются комбинацией вызовов существующих. К примеру, есть пункты A и B, нужно добавить C = A(B), то есть вызов A с параметром B. Можно на любой существующей программе.

Похоже вы действительно не знаете, что значит модель Model/View. То о чем вы спрашиваете, этой моделью не покрывается, она совсем для другого. Управление пунктами меню в Qt - ну совсем тривиальная задача, в отличии как раз от Model/View. Добавлять, удалять, изменять пункты меню - задача в Qt для программиста детская. Нужно только понять, насколько нужно такое изощренное управление. Вполне вероятно, что достаточно чего-либо вроде конфигов openbox в xml (которые на Qt очень просто реализовать тоже). Можно и на лету менять типа как в Гноме или КДЕ, но, ещё раз, это децкая задача, которая больше нужна как свистелка, чем как фича. А фичи, которые дает Qt, даже тупо перечислять долго. Не уверен, что когда-нибудь будет проект за исключением КДЕ (хотя и он не все юзает), когда они все одновременно понадобятся.

Ничего, что в системы нельзя поставить 2 одинаковые либы с одним именем? В sdk судийные либы лежат в папке с креатором и нужны только ему (читай они тянут либы вместе с прогой)

Печалька. Но можно же таки суффикс или префикс у разных сборок указывать.

Для этого придется перекомпилить все ранее написанные приложения, чтобы они искали -lMyKibSuffix а не -lMyLib

.Нет можно поставить в систему (тк длл одной версии не имеет разных вариантов сборок). А Qt нельзя. Другое дело, что в конкретном случае, юзерам приходится держать 2-3 версии дотнета (2, 3.5, 4) в системе.

> Ты так говоришь, как будто сейчас Qt - сырая недоподелка. Qt давным-давно готов к продакшену. Главное, чтобы фиксили баги и вносили изменения в соответствии с обновляемыми системными библиотеками, если те сменят API.

Вообще-то не готов, а давно там.

> еще бы отменили идиотский переход на JavaScript в Qt5 - было бы круто!

Забей ты на Qt5.

У нас бы Qt3 продолжали бы использовать, если бы он подо всеми системами был полностью открыт.

Тролл детектед.

Аргументы?

Судя по qt3support классам, тройка отличалась удолбищностью апи.

Хотя, если вам нравится все делать в дизайнере...

> Тролл детектед.

Здраствуй, троль!

Аргументы?

Какие аргументы? Для продакшена не нужна куча наворотов добавленная в Qt4. Были мелкие неудобства, но умея их обходить, проблем не возникало бы.

Судя по qt3support классам, тройка отличалась удолбищностью апи.

Походу, вы под Qt3 не работали. Потому и такое отношение.

Хотя, если вам нравится все делать в дизайнере...

Эту свистелку, как раз сильно развили в Qt4.

До этого она была не особо удобна.

не понял - какую свистелку? в 3ем дизайнере можно было писать код форм, в 4м нельзя - кто что раздул?

> не понял - какую свистелку? в 3ем дизайнере можно было писать код форм, в 4м нельзя - кто что раздул?

Раздули возможности по приданию виджетам разных видов и использование стилей.

А код в дизайнере - ну.... может любители и были...

Поддержка стилей и нативный вид - это одна из немногих причин, почему вообще стоит использовать c++/qt а не джаву - уж там-то поболее написано. Только с гуем траблы из-за ненативного лук энд фил.

Кроме того, стили зашити где-то внутрях рисования - не понимаю, что вас смущает, паблик АПИ они не меняют ну вообще никак.

да не. обсуждение не ограничено графикой. разговор о qt вообще. если же рассматривать только gui, то я не видел ничего проще wxWindow. просто, кроссплатформно, понятно, компактно. fltk тогда тоже очень неплох. но qt - это совсем другое. это - всеобъемлющее решение. при этом снабжённое развитым инструментарием разработчика. отличная документация - тоже огромный плюс. в таком разрезе конкурентов у qt очень мало, мягко говоря.

А еще wx тормозит везде кроме венды, что намекает.

> Кроме того, стили зашити где-то внутрях рисования - не понимаю, что вас смущает, паблик АПИ они не меняют ну вообще никак.

Меня ничего не смущает. Я говорю, что всего, что нужно - хватало и в Qt3.

Так что смысла ожидать Qt5 при наличии Qt4 не вижу.

Если только для программирования всяких видов телефонов.

> Ога, только стандартные контейнеры (списки, деревья и проч.) на редкость тормозные в glib, а всё из-за специфики Си.

4.2, вызванное банальным незнанием основ программирования.

Неуч, glib'овские контейнеры ничего не знают про типы и вызов функций там всегда происходит по указателю. Сравни для начала производительность sys/tree.h и glib'а, а потом неси тут эту ересь.

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

Резюмируем: Qt - очень удобный (для программистов) инструмент для создания неудобного (для пользователей) интерфейса.

Ещё раз: программисты (прикладных программ) в Linux не имеют ни малейшего понятия о создании нормальных интерфейсов. И не должны иметь - это не их компетенция. Это компетенция дизайнеров (не художников, клепающих темы и считающих их за интерфейс). А у дизайнеров нет инструментов для создания _нормального_ интерфейса. Qt designer для клепания формочек - не в счёт. И как результат - популярность Linux ниже плинтуса. Ибо формочки на очень удобном для их создания тулките - не есть нормальный интерфейс.

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

Я, конечно, рад, что вам удобен Qt. Но пользователям ваши программы неудобны. Хотя, если вы программы только для себя пишете, то всё это не имеет никакого значения.

А так меня забавляет ситуация, когда It-шники пишут GUI, но сами этим брезгуют пользоваться. Понимают же, что такой интерфейс - дерьмо. Но не понимают почему.

То есть работа с дисками, сетевыми интерфейсами не нужна? Очевидно, вы пишете очень маленькие программы:)

Вы предлагаете посадить дизайнеров писать уй на винапи?

Для того и придумали qml.

А что, в Windows интерфейс лучше? Там просто более-менее работающая в тривиальных случаях автоматика спасает.

Посмотрим, что их этого выйдет. Сдаётся мне, что новым инструментом будут решать задачи старыми способами.

Просто тот анонимус сказал, что Qt говно, тк на нем не могут писать дизайнеры под линукс, так как их там нет (какая длинная логическая цепочка) В винде дизайнеры есть. Предположим, что Qt говно, как говорит тот анонимус. Дизайнерам надо делать уй на винапи или MFC? Если не на винапи, то тогда Qt не говно? Если дизайнерам вообще не надо писать уй, то тот вброс не имеет смысла. Как-то так.

Тот анонимус - это я. И я не говорил, что Qt - говно. Я говорил, что Qt раздут, но с точки зрения GUI не предоставляет чего-то более удобного для пользователя, чем остальные тулкиты. Только эстетика.

Дизайнерам надо делать уй на винапи или MFC?

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

Qt - мощный инструмент, умеющий всё, но не имеющий оптимальной настройки для простого пользователя. Чтобы с помощью его делать хороший интерфейс, нужен дизайнер - профессионал. Которых, естественно, очень мало, и которые очень дорогие. Результат - большинство программ на Qt - формочки, и не более. Меньшинство - чуть больше, чем формочки. Ибо интерфейсы на Qt делают программисты или дизайнеры-непрофессионалы.

В винде дизайнеры есть.

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

Хороший интерфейс (относительно остальных) я видел только в нескольких жутко дорогих программах, и в некоторых обычных. WYSIWYG - классический графический интерфейс. Рабочая область графических редакторов и разных вещей по работе с графикой - тоже. Ну и, конечно, компьютерные игры. Вот где настоящий GUI, так это там. Там почти нет формочек - взаимодействие идёт с предметной областью, представленной в истинно графическом виде. Вот в этой области и живут настоящие дизайнеры интерфейсов. Жалко только, что от игр реальной пользы нет.

Я, конечно, рад, что вам удобен Qt. Но пользователям ваши программы неудобны. Хотя, если вы программы только для себя пишете, то всё это не имеет никакого значения.

При чём здесь qt? С помощью прекрасных инструментов (что бы это ни было) написано подавляющее большинство отвратительных программ и под windows, и под mac, и под linux. Правильно написанных программ становится исчезающе мало. Развитый инструмент разработки на фоне неумения проектировать - и результат налицо: рисуем форму, в ней же реализуем алгоритм, попутно кодируя на C++ свои клёвые классы-контейнеры (оптимальные по производительности! новое слово в науке! кто я? тварь дрожащая или право имею? даёшь вейланд! :)). Дело не в инструментах по большому счёту. Разруха не в клозетах. Это как кольт - великий уравнитель. Вы же тоже можете взять qt, и создать настоящий unix-way. Qt много удобнее в этом смысле, чем gtk например :)

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

Ну вот какими такими волшебными свойствами должен обладать интерфейс графического редактора или того же редактора реестра windows? предметная область и там и там вполне очевидна. инструменты - на кнопках, в контекстных меню. строка состояния, строка ввода команд. что ещё? в 3D показывать разные HKEY? зачем? лично мне кажется, что вполне достаточно для начала придерживаться единого гайдлайна. для винды, кстати, был очень неплохой гайдлайн по gui. просто более законченного не видел. по гному тоже есть, конечно. другое дело, что формочку можно нарисовать красиво и удобно, логично разбить на разделы, понятно разместить кнопочки, добавить удобств, автоматизации. но, к сожалению, бОльшая часть людей, делающих хоть что-то для других, просто не одарена художественными талантами. в случае free source можно взять и исправить.

> По идее, в любом web - приложении. Из чисто десктопных - в той же Mozilla с помощью расширений. Ну и разные приложения, настраивающихся с помощью скриптовых языков программирования.

Вы опять не поняли. Где можно менять _логику_ на уровне пользователя? С серьёзными вещами вроде плагинов и вообще платформы того же Eclipse даже продвинутому программеру не все так просто. Или вы таки считаете, что простой пользователь может что-то заскриптовать? С другой стороны, даже если и сможет, он все равно будет работать в рамках логики, заложенной в программу.

Можно все-таки пример, где можно настраивать любое web-приложение не на уровне меню/кнопочек/портлетов, а именно на уровне логики его работы пользователем, а не админом/программистом этого приложения?

> Нет можно поставить в систему (тк длл одной версии не имеет разных вариантов сборок). А Qt нельзя. Другое дело, что в конкретном случае, юзерам приходится держать 2-3 версии дотнета (2, 3.5, 4) в системе.

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

> Резюмируем: Qt - очень удобный (для программистов) инструмент для создания неудобного (для пользователей) интерфейса.

Ну вот, пришел крутой анОним и всех зарезюмировал. Как мы раньше не сами не смогли?

Я, конечно, рад, что вам удобен Qt. Но пользователям ваши программы неудобны. Хотя, если вы программы только для себя пишете, то всё это не имеет никакого значения.

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

А так меня забавляет ситуация, когда It-шники пишут GUI, но сами этим брезгуют пользоваться. Понимают же, что такой интерфейс - дерьмо. Но не понимают почему.

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

> А еще wx тормозит везде кроме венды, что намекает.

Ну да, под виндой он использует шустрый WinAPI, а под иными осями что-то более тормозное, типа gtk.

> Неуч, glib'овские контейнеры ничего не знают про типы и вызов функций там всегда происходит по указателю.

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

А что же он в сравнении с GTK лагает?

>Дело не в инструментах по большому счёту.

Это как это, не дело в инструментах?

>Ну вот какими такими волшебными свойствами должен обладать интерфейс графического редактора или того же редактора реестра windows? предметная область и там и там вполне очевидна. инструменты - на кнопках, в контекстных меню. строка состояния, строка ввода команд. что ещё?

По поводу граф. редактора - в том же GIMP не всё имеет препросмотр. Настройка инструментов - это просто задание чисел и флажков. И это при том, что GIMP профессионалы делают.

А в regedit слабая группировка компонентов и мало отображаемых между компонентами связей. И при этом - глубокая разбивка. Одна ветвь может содержать только один параметр. Найти что-то можно только если знаешь, что и где искать. Просто бегло изучить состав невозможно. Интуиция не работает полностью. Тестовой редактор проще был бы. Интерфейс из разряда необозримых. И если только нужно просто исправить значение ключа или добавить параметр - годится.

>Можно все-таки пример, где можно настраивать любое web-приложение не на уровне меню/кнопочек/портлетов, а именно на уровне логики его работы пользователем, а не админом/программистом этого приложения?

API web-приложений. Можно создавать любой интерфейс. по желанию. Те же webmoney. Или lj.

Или вы таки считаете, что простой пользователь может что-то заскриптовать?

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

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

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

+1! По полочкам всё! Доводы GTK-шников поднадоели уже слегка, внятных аргументов как не было так и нет.

> То есть работа с дисками, сетевыми интерфейсами не нужна? Очевидно, вы пишете очень маленькие программы:)

Анонимное чудо не знает, что все это в Qt3 было. И еще безумное множество библиотек, часть из них с открытым кодом.

>Нет, вы не убедили меня, что 16Мб на пустую форму это уже нормально.

А 1Гб линукса для пустой формы это нормально?