Qt Project жив!

Кстати да: сборка Отладка-Сборка на Си может занять много больше времени из-за перекомпиляции больших объёмов кода. С С++ и ООП всё много проще, всё перекомпилировать не нужно.

> ИМХО, годный вид - это либка и интерфейсы на скриптовом языке.

Да по сути - то же самое. За исключением того универсальность интерфейса (библиотеки) несколько ниже универсальности текстового интерфейса.

Например tar, будь он реализован в виде либы, не смог бы обзавестись ГУЯми на винде (не знаю есть ли, но должен быть и макоси). Потому что библиотека линукса на винде и макоси уже не может выполнять своих функций, а вот бинарик с текстовым интерфейсом - может.

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

Комбинировать пункт меню с результатом выполнения другого пункта меню.

> Найдите коды возврата в интерфейсах в современных программах.

Да я и не говорю что все так идеально легко. Я говорил уже что нужно писать программы так, чтобы к ним удобно было делать отдельный ГУЙ. Если в современных программах поголовно этого нет - это плохо, позабыли для чего все затевалось. Есть еще довод в пользу текстовых интерфейсов. В отсутствии графического окружения, использовать wget или тот же tar легко и просто, чего нельзя было бы сказать, будь они реализованы в виде библиотек.

Если я правильно понимаю идею библиотек вообще, они нужны для предоставления функционала прикладным программам, а не для того чтобы содержать в себе код прикладной программы. Тот же wget скорее всего не сам качает, а пользуется функциями какой-нибудь системной библиотеки, а сам, по сути, является удобным текстовым интерфейсом для этой библиотеки (библиотек). Потому, наверное, и графических надстроек на него нет, что писать интерфейс к интерфейсу - ну, сами понимаете. Это я все не подсмотрел и не знаю, это я все сам придумал, потому как мне кажется должно быть. Так что если ошибаюсь - больно камнями не кидать. )

> Комбинировать пункт меню с результатом выполнения другого пункта меню.
Пока что на ум приходит нечто вроде векторного редактора, где над одним объектом совершается рад последовательных действий, например «залить объект A зеленым цветом» -> «произвести пересечение результата предыдущей операции с объектом B» -> и т.п. В любом случае не вижу особой проблемы для реализации подобного с помощью Qt.

>За исключением того универсальность интерфейса (библиотеки) несколько ниже универсальности текстового интерфейса.

Только его парсить надо.

вот. А ты ниасилил, тукан.

>Я говорил уже что нужно писать программы так, чтобы к ним удобно было делать отдельный ГУЙ.

Спасибо, кэп!

В отсутствии графического окружения, использовать wget или тот же tar легко и просто, чего нельзя было бы сказать, будь они реализованы в виде библиотек.

Библиотек к скриптовым языкам! Просто либки не помогут, конечно.

Тот же wget скорее всего не сам качает, а пользуется функциями какой-нибудь системной библиотеки

Какие могут быть библиотеки для http-клиента в системе? Это прикладная задача.

> Только его парсить надо.

Надо. Но, во-первых, это не так и сложно, при условии что разработчик позаботился и можно было бы написать единожды парсящий код, да и не париться больше об этом (это не из реальной жизни, но, в принципе, если бы все делали стандартный интерфейс, можно было бы стандартно парсить, дело-то, сама идея не виновата, что IRL все не так), а во-вторых, тут уж нужно решить что важнее, легкость разработки (тогда незачем парсить, можно использовать либу) или годность конечного продукта (хоть небольшое прибавление к универсальности, но все же прибавление)

>В любом случае не вижу особой проблемы для реализации подобного с помощью Qt.

В небинарной части? Ткните в доку, плиз, или в пример, как сделать последовательный вызов пунктов меню.

> В небинарной части? Ткните в доку, плиз, или в пример, как сделать последовательный вызов пунктов меню.

Через последовательный вызов нужных QAction::trigger() естественно, а как именно - зависит от архитектуры программы.

>это не из реальной жизни, но, в принципе, если бы все делали стандартный интерфейс, можно было бы стандартно парсить, дело-то, сама идея не виновата, что IRL все не так

Вот поэтому в IRL приходится делать по-другому, чтобы хотя как-то работать с подобием Unix-way.

> Библиотек к скриптовым языкам

Ох, щас блесну невежеством. Ну что делать, будем искоренять оное. )

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

If'ы, case'ы - это всё тоже работает?

> чтобы хотя как-то работать с подобием Unix-way.

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

Как-то бредово ) не, я Вас, конечно понимаю, доводы разумны, практика тоже подтверждает, работает. Но мечтать о светлом будущем, в котором все Unix-way ведь можно и нужно? :) И стремиться, разумеется.

Если нет ffi, то невозможностью использования обычной. Если есть, то причёсанностью.

>А давайте все разом будем забивать на идею

Так все УЖЕ забили на идею. Неужели незаметно?

>Qt давным-давно готов к продакшену.

s/готов к продакшену/в продакшене/g

> If'ы, case'ы - это всё тоже работает?
Возможно реализовать даже такую гибкость, хотя конечно свой код писать придется, чистыми библиотечными средствами Qt такое не предусматривается. Правда что-то я не видел, чтобы где-то использовалось такая параметризация GUI, пример-то не высосан из пальца случаем? Пользователь уже не просто пользователь, раз ему требуется фактически программировать поведение GUI. Как это сочетается с

Пользователи при использовании _рабочего инструмента_ плевать хотели на внешний вид и общую концепцию. Хороший интерфейс - это тысячи мелочей. И их программист не продумает. Ибо не компетентен в предметной области.

?

> Так все УЖЕ забили на идею.

Большинство - возможно. Я ж еще не зебил ) но, да, это в какой-то степени оправдывает отречение от идеи, мол, все уже забили, какой теперь понт верить в идею. Мое мнение, по-настоящему полезным для общего дела становится именно то, чьи разработчики не забыли чего ради все начиналось. TeX, например, двадцать лет уже не меняется, даже не разрабатывается, потому что готов, потому что стал маленьким кирпичиков в деле будущего рассово-верного компьютерного мира. Где академическая модель разработки программ, где все свободно. Где программа пишется хорошо и на века, для того чтобы годно выполнять свое дело, а не быстро-криво для того чтобы содрать с народа копеечку и чтоб народ мучался потом.

Вобщем, даешь светлое будущее рабочим и крестьянам IT! Нет буржуям-эксплуататорам, жирным боссам и корпорациям (которые зла) :)

Короче, я молодой, горячий, еще не видел жизни, не рушьте мою мечту в светлое завтра )

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

>Большинство - возможно.

Из прикладных программистов, видимо, все.

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

TeX и не используется напрямую. А уж тем более, не используется широко, в эпоху word processors.

потому что стал маленьким кирпичиков в деле будущего рассово-верного компьютерного мира

Что-то не верится, в эпоху-то электронных документов и падения спроса на печатную продукцию. А с электронной документацией у TeX как раз-таки плохо.

>Это который Джонни? :)

Он самый. A white knight upon a fiery steed.

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

не совсем так. в ntoskrnl.exe - да, плюсов не было. но в множестве системных либ - полно.

:)

Использовал quassel для винды когда-то. Весил 12мб, включая оформление.

>> Qt тормоз и на приплюснутых, это первая причина отказа от него, вторая - уродлив. А то что автор понаписал - вода и отсебятина

о великий ононизмус, тормоз не Qt и не C++ а школоло которое на нем пишет. в том числе тормоза которые похоронили практически кеды.

>а школоло которое на нем пишет

Так других же нет (c)

>Использовал quassel для винды когда-то. Весил 12мб, включая оформление.

Qt мне нравится, хорошая штука, НО..... 12 мб для IRC-клиента это очень много.... например MIRC весит чуть больше 1,5 мегов, а функционал наверное будет поболя, чем у quassel .... другие IRC-клиенты так же весят немного.....

Ладно, пусть будет не IRC-пакет, а что-то ещё, размер либ останется тем же. 10 мегов не перерастут в 120, если пакет будет побольше. (И да, это статическое линкование, без него он весит сильно меньше)

Ура! Очень боялся что смерть Nokia убьёт Qt.

А используя только Qt возможно написать программу для работы с USB устройством? Я так понимаю Qt вполне может взять на себя обработку пакетов с устройства?

Интересно, товарищи, которые выкрикивают про кончину Qt, серьезно не вылазят из своего гтк-мирка или они просто воображают что троллят?

Adium на Маке весит 72,3 метра и тащит вместе с собой AdiumLibpurple.framework (9.2 метра), libpurple.framework (15.3 метра), libglib и иже с ним более чем на 3 метра. 12мб для irc клиента много?) Нет, понятно что там не только irc, но и всевозможные протоколы, только кто сказал, что IM клиент - вещь легковесная? Вот я смотрю на этого 70метрового монстра и мне совершенно не жалко 30 метров кьютовских библиотек положить.

Далее, в сравнении размера гномовского мусора, поставляемого с Адиумом (5 либ) и QtCore - 3мб против 6. Да, весит меньше, но что-то мне подсказывает, что в QtCore функционала приблизительно в те же 2 раза больше - та же QAbstractItemModel ведь в коре живет.

Правда сравнение не совсем корректное, тк Qt и либы адиума являются universal binary, собранные под разные архитектуры (Adium - ppc+i386, Qt - i386+x86_64), но не вижу особых причин, почему вес бинарного кода для ppc должен разительно отличаться от x86_64

>Adium на Маке весит 72,3 метра и тащит вместе с собой AdiumLibpurple.framework (9.2 метра), libpurple.framework (15.3 метра), libglib и иже с ним более чем на 3 метра. 12мб для irc клиента много?) Нет, понятно что там не только irc, но и всевозможные протоколы, только кто сказал, что IM клиент - вещь легковесная? Вот я смотрю на этого 70метрового монстра и мне совершенно не жалко 30 метров кьютовских библиотек положить.

Далее, в сравнении размера гномовского мусора, поставляемого с Адиумом (5 либ) и QtCore - 3мб против 6. Да, весит меньше, но что-то мне подсказывает, что в QtCore функционала приблизительно в те же 2 раза больше - та же QAbstractItemModel ведь в коре живет.

Правда сравнение не совсем корректное, тк Qt и либы адиума являются universal binary, собранные под разные архитектуры (Adium - ppc+i386, Qt - i386+x86_64), но не вижу особых причин, почему вес бинарного кода для ppc должен разительно отличаться от x86_64

Мне трудно судить о Маке, ни разу не пользовался сим зверем.... НО для IM-клиента 72 мега это просто безумие.... например миранда весит всего 3 мега и функционал думаю не меньше чем в Adium.... если для мака 72 мега IM-клиент это нормально, то я рад, что не юзал Мак.... Вообще мне не понятно зачем вообще нужен Мак? Если винда самая популярная, линукс бесплатен, то Мак и не самый популярный и не бесплатный.... и какой смысл юзать этот плод маркетинга не понятно.....

72 метра, тк сборка под 2 архитектуры - делите реальный размер пополам (на винде-то одна архитектура)

Сборка миранды, к-й я пользовался, держала всего 2 протокола (icq и jabber) и не позволяла коннектится дважды с одного протокола, в отличие от адиума (30 протоколов) - у меня одновременно запущены 2 аськи и жаббер, иногда irc пользую

И как я уже сказал, основной вес - это тот же линуксовый libpurple (привет, пиджин!) да гномолибы. Остатки - это рандомные либы по 100кб

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

>Сборка миранды, к-й я пользовался, держала всего 2 протокола (icq и jabber) и не позволяла коннектится дважды с одного протокола, в отличие от адиума (30 протоколов) - у меня одновременно запущены 2 аськи и жаббер, иногда irc пользую

Скорее всего это была старая сборка..... потом как сейчас в комплекте с мирандой при весе 3 мега идут куча протоколов..... остальная часть протоколов идет в виде плагинов, весом около 100 килов каждый, по любому на 30 мегов не наберется.....

А если серьезно, удобнее чем винда и не надо трахаться, как с линуксом.

С любой виндой недавно вышедшей тоже первое время приходилось трахаться, пока дрова новые не выйдут.... с линуксом не с каждым приходится трахаться.... я пробовал федору с Xfce пришлось потрахаться а вот убунту с xfce сразу без проблем начал работать..... в тоже время с виндой вистой и 7-кой проблем постоянно много, то одна программа не пашет, то другая, то дрова не идут... то еще черте-что.......

> Qt Project жив!

Nobody cares.

> и какой смысл юзать этот плод маркетинга не понятно.....

Think different. Проще говоря, чтобы быть не таким, как все.

>Скорее всего это была старая сборка

Ну очень старая скорее.

>С С++ и ООП всё много проще, всё перекомпилировать не нужно.

Смотря как написан код :(

>если для мака 72 мега IM-клиент это нормально, то я рад, что не юзал Мак....

искоробки есть iChat без всяких гномозависимостей

>Nobody cares.

Говорите за себя

>Qt мне нравится, хорошая штука, НО..... 12 мб для IRC-клиента это очень много.... например MIRC весит чуть больше 1,5 мегов, а функционал наверное будет поболя, чем у quassel .... другие IRC-клиенты так же весят немного.....

Все зависит от 1)типа линковки - в Qt очень много функциональности, не требующейся IRC-клиенту 2)использования платформенно-специфичных компонентов (характерно для windows-only софтин, которые за счет этого имеют довольно небольшой размер)

>И лишняя навороченность Qt становится становится видна невооружённым взглядом.

Так и запишем: неосилятор

Неосилятор чего?

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

Злостное, шокирующее, мозговыносящее, эталонное 4.2.

ls -lh /usr/lib/qt4/ | grep -v «\->» | grep 4.7.2

ldd <путь к бинарнику>

Также смотришь размеры бинарника и _принадлежащих_исключительно_этому_проекту_ .so-шек. Для правдоподобных результатов делаешь выборку из нескольких проектов.

Берешь калькулятор, считаешь. Думаешь.

Вендопроблемы. Недоось не научилась содержать динамические библиотеки глобально.

Это скорее косяк Троллей, что они до сих пор не сделали redistributable package с кутей.

>Неосилятор чего?

Qt, конечно