Russian Qt Forum

Что происходит в Nokia?
Обещали придерживаться квартального графика по выходу младших версий и годового по минорным, в итоге застряли после 4.6.3 с 4.7.0 и 4.7.1. Обещали QtCreator 2.1 выпустить вместе с 4.7.0 - прошло почти полгода, а мы до сих пор с 2.0.1. Даже записи в developer блоге не обновляются уже 11 дней. Все брошены на допиливание MeGo? Почти все последние обновления касаются исключительно QML (чтоб он сдох). Не пора ли нам искать новый фреймворк?

Ну толсто же )
Я QtCreator 2.0.94 пользую.

Баги фиксят. Ты посмотри на гиториусе - там постоянные коммиты. Особенно в креаторе.

Да, Nokia решила отказаться от Qt в пользу Dalvik. Ничего не поделаешь. Удаляйте Qt с диска скорее.

А-а-а, мы умрем. Куда же катится мир???  ;D

Подскажите, где достать. Неохота с исходников компилить. Мне для linux. Спасибо.

Updated: http://qt.nokia.com/developer/qt-qtcreator-prerelease#download

ftp://ftp.qt.nokia.com/qtcreator/snapshots/ (ftp://ftp.qt.nokia.com/qtcreator/snapshots/)

зря глумитесь...

Действительно зря, такой ажиотаж вокруг javascript и овебление могут привести к краху целого такого инструмента как Qt.
интересные размышления по теме рождения ошибок в приложениях http://landoflisp.com/
Если вдуматься Qt это всего лишь c++ с сигналами. Все остальное имеет бесплатные аналоги.

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

Кстати анимации, state machines, и прочие json QML штуки они видимо отсюда (http://www.clutter-project.org) стянули :)

>>Кстати анимации, state machines, и прочие json QML штуки они видимо отсюда стянули
там чистый "Цэ" без плюсов, так что врятли.

А давайте продолжим размышления:
http://love5an.livejournal.com/355385.html#cutid1 (http://love5an.livejournal.com/355385.html#cutid1)

К чему это я? Ах, да. Умрет c++, умрет Qt. Но вы скажете с++ не умрет. А почему бы пайтону не заменить c++? Кроссплатформа, stl, куча батареек - это все касается их обоих.

Чтобы сдох сипипи, нужно столько систем перевести на другой язык, а это невыгодно. Увы, но на мой взгляд, С++ не умрет до тех пор, пока программы не начнут писать программы :)

Это кстати одна из основных идей Лиспа (создать "код" и выполнить его). Работал 2 года на AutoLisp, Сначала конечно сынтаксыс бьет по ушам, но потом - нравится, начинаешь изобретать такие вещи о которых в ++ даже и не помышлял.

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

Qt уже долгое время является инструментов для создания широчайшего спектра приложений. Сколько еще кирпичиков надо? Софт - это не только фрейворки,в первую очередь это мозги и идеи. Нет идей и желания работать - никакие апгрейды не нужны. Поэтому я вообще не понимаю этой темы. Что, требуется чтобы в Qt был движок аля UE3 и чтобы все можно было в дизайнере сделать?



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

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

П.С.
ещё ни один программист не написал ни одной программы сходу.

А я думаю что понимаю. Вот к примеру было 4.5 а сейчас 4.7. Что я с этого имею? Понятно мое мнение субъективно - всем пользователям никогда не угодишь, та же самая фича "вышак" и "само то" для одних - и ничего не значит для других. Но складываясь вместе эти мнения формируют объективную картину. Автор топика может меня поправить, но я понял его так: если нет достаточного прогресса - неизбежно начинается регресс. "Чтобы оставаться на месте нужно бежать достаточно быстро" (неточная цитата).

Ответ есть в ++ библии - на то она и библия чтобы отвечать на любой вопрос. Там где объясняется почему люди обычно не любят программистов и есть множество попыток обойтись без них (ну примерно как Вы  хотите :))

очень-очень согласен :) Яву вспоминаю как страшный сон

А я смысла темы не понимаю. Что остановилось? Какой регресс? Да, сайчас больше уклон пошел в сторону мобильных платформ и это хорошо. А с другой стороны, чего не хватает на десктопе?

Эта тема - пустая болтовня. Взгляните на тотже GTK+, хотябы на последние релизы - 2.20 (1.04.2010), 2.22 (23.09.2010). Там больше прогресса? Или в каком нибудь другом тулките больше?

> Вот к примеру было 4.5 а сейчас 4.7. Что я с этого имею?

What's new in Qt 4.6 (http://doc.qt.nokia.com/4.6/qt4-6-intro.html)
What's new in Qt 4.7 (http://doc.qt.nokia.com/4.7-snapshot/qt4-7-intro.html)

это поверхностно

+ добавить чендж логи всех промежуточных версий.

Pastor, я никак не хотел задеть ни Qt (это реально классный фреймворк), ни Вас лично. Просто люди (из тех которые умеют думать) всегда будут спрашивать "а достаточно ли быстро Qt бежит?" - и это нормально и неизбежно. На то он и лидер чтобы бежать - и быть судимым  :)

Кому хорошо и почему? Мне как разработчику десктопных приложений и владельцу Android смартфона от этого ни холодно ни жарко.

Много чего мне не хватает. Нормального интерфейса к БД и нормальной же реализации MVC (которая, кстати, была в планах еще Troltech). Нормального варианта MDI с табами аля новые opera и firefox 4. Нормального QtCreatora с нормальным отладчиком и полноценной поддержкой CMake (тоже обещали). И так далее. Так вот после 4.6.3 я вижу существенное замедление темпов развития Qt в этом направлении и меня это беспокоит. А с учётом ахового положения Nokia на их родном мобильном рынке судьба Qt как моего основного framework беспокоит ещё больше.

Ну так мне глубоко всё равно что там происходит с GTK. Пусть хоть совсем не развиваются - я им не пользуюсь, а GUI программ, разработанных с его помощью, меня и вовсе в ступор вгоняют.

Всего лишь год назад Qt развивался существенно более динамично и ритмично. Теперь - нет. Об этом тема и была создана.

Ну другом конце ui-программистского городка говорят, что объединением окон должна заниматься операционная система, мол, незачем второй список окон делать.
А eclipse кстати умеет первое, причем во множественном числе, и второе, причем тремя способами, а в одном даже автодополнение с подсказкой аргументов для cmake файлов (сам пользуюсь).

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

Вот скажите пожалуйста, а winAPI развивается быстрее Qt? Есть другие кроссплатформенные либы, которые выполняют всецело функции Qt?

Разница 4.5 и 4.7 огромна, надо только софт чаще выпускать в разных сферах :) Особенно для мобильных устройств, т.к. winCE - это не только мобилки и WM, но еще и куча других девайсов, выполняющих часто очень важные функции в масштабах предприятий.

А "не хватает" - никто не мешает написать это самим. Никто не мешает доработать QtCreator, сделать и себе и другим.

>>а winAPI развивается быстрее Qt?
API ОСьки бессмысленно сравнивать с библиотекой "GUI и около". Сравнивай уж тогда .NET с Qt.


>>Разница 4.5 и 4.7 огромна
я кроме полу работающего QML ничего не вижу, да и затея говнецо если откровенно. Визуальные вещи надо делать визуально, а не очередной язык программирования придумывать. Да и креатор сильно кривой интерфейс имеет для визуального проектирования QML-ных штуковин.

как сказал xokc, давняя проблема - кривой QSql, троли ни на йоту не продвинулись в этом направлении.

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

.NET развивается наверное быстрее, но имеет такие косяки в некоторых областях, что мама не горюй :)


А между 4.5 и 4.7 очень сильная оптимизация рендеринга на моб. устройствах. Qt Mobility - тоже полезнейшая вещь для мобилок, развивающаяся. QML - тоже удобная штука. Пускай и для мобилок все это.

А с точки зрения десктопа - state machine, animation framework? Да, для БД ничего не добавилось, но кроме БД есть много других вещей. К примеру, я вообще с БД не работаю, но работаю с мультимедия и сетями. Так что тут наверное "кому что надо" вопрос?

xokc, нехочу вступать ни в какие холивары и прочее. Но, а что вы слалали для того чтобы модуль по работе с БД стал лучше: багрепорты, suggestions, патчи, etc? Гуевые фишки это вобще спорный момент, вам они нада, другим нет. Выход: отправить suggestion, грамотно обосновать свои мысли, написать накрайняк патч, ну или реализовать недостающий функционал "только для себя" и  использовать его в скоих проектах.

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


> Pastor, я никак не хотел задеть ни Qt (это реально классный фреймворк), ни Вас лично.

Я об этом даже не подумал, я просто попытался показать, что фрейворк не стоит на месте ))

К вашему сведению, .NET сейчас развивается во многом именно в этом направлении. Только у них это называется WPF и основывается не на java-синтаксисе, а на xml-синтаксисе. Кстати, последняя Visual Studio написана именно так.

нет) не выйдет)
питон как бэ питон,... хорош, но не надо видеть к нем замену C++)
ну и знаете ...
"только отмороженный мог придумать описывать синтаксические конструкции невидимыми символами".
и весь язык после этого... слегка отмороженный, с некоторой извращенной логикой))) упрощать можно, но надо вовремя остановиться. черезмерное упрощение в сложных системах порождает не слишком нужную неоднозначность поведения.

и это не говоря про плюсы-минусы "динамической типизации" против "статической", по "скриптовую/интерпретирую суть питона" и т.п. и т.д. )
скриптам - скриптовое, компилируемым языкам - компилируемое). не надо смешивать)

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

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

И здесь есть 2 подсмысла :)
1) Описать простым языком сложное, не погрешив против истины - невозможно.
2) простая вещь "понятна" многим, но часто это понимание "мнимое" - когда начинаешь выяснять что же именно каждый из "понимающих" понимает под тем что он "понимает" - выясняется что ожидания от этого - у всех разные.

Конечно, если ты знаешь весь язык и все его "сакральные знания" - то он тебе "понятен" и его поведение совпадает с те что ты ожижаешь. Но есть такая штука как "интуитивное понимание" что-ли... когда ты не знаешь что и как - а оно работает точно так как ты думал. А с питоном - совершенно иная история - т.е. ты вначале изучения инструкции ожидаешь от неё несколько иного поведения, чем оно тебе демонстрирует и этого не видно(!). Т.е. "язык не прощает незнания собственных спецификаций".  В Си ты сращу видишь, что инструкция "сакральная" - и ты начинаешь её понимать. А в питоне -  натыкаешься на то, что "тебе кажется" что инструкция понятна - но ведет она себя не совсем так, как ты от неё это ожидаешь. По крайней мере в начале)

Всякому инструменту - своё место. Имхо - место Питона (как однажды было сказано самими поклонниками) -  в замене Basic в учебном процессе.
И это действительно более приятный и мощный язык чем бейсик. Одно только то, что он ООП для учебного процесса очень важно.

Но замечу - историю с популяризацией Бейсика мы уже проходили. И толпы программ на "визуал-басике", и скриптование офисных программ, и даже АСП как оная реинкарнация.
Вы не находите параллелей с питоном? как его "суют куда ни попадя" - от настольных приложений до веба? жду аналогичного сценария развития событий. Где бейсик? вот там и питон будет. Он осядет в своих избранных нишах, предназначенных для простых, скриптовых языков.

Всякому инструменту - своё место. не надо натягивать инструменты на несвойственные им задачи и роли.
Не надо пытаться позиционировать питон как замену С++).  
Вот описывать бизнес логику на питоне в среде программы написанной на С++ - это дело. но никак не наоборот)))
(хотя и для этого по мне - так для скриптования С++ приложения лучше подходит ECMA262 (JavaScript/QtScript))

Ну что же... Для того чтобы знать два языка, надо знать два языка. И вы можете прекрасно прожить свою жизнь владея только русским. Он мощен и разнообразен.
Несомненно. Но ведь критические участки, допустим, декстоп-приложения это отрисовка большого количества данных. Обработку данных все чаще предоставляют sql серверам, причем на ада-подобных скриптовых языках. Это значит что в приложении остается отрисовка и логика взаимодействия с пользователем. Отрисовка на с/с++, и оставшееся на скриптовом языке. Причем не вижу особой разницы в чем храняться данные в QVariant или в PyObject. Единственное, что последний требует интерпретатора.
Теперь скажите как вы наследуете c++ классы в ecma262? А как вы там переопределяете операторы? А там у вас итераторы есть? А декораторы?
Простая вещь, если бы в какой-то момент духовному вдохновителю/менеджеру компании Qt не пришло в голову делать из Qt фреймворк для создания web броузера, я бы до сих пор наслаждался данным интрументом.

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

а вот это уже касается вопросов вкуса и "один скриптовый язык против другого", и в эти споры я влазить не намерен)
но думаю что по мнению "каждому инструменту - своё место" - мы сошлись? ))) вот и ладненько)

То да, но

Ой-ой, ну вот не надо льстить себе что, мол, "достигается (моим) пониманием", ну там "(моей) общей культурой" и все такое. Это та же самая "зубрежка" - просто Qt подала ее очень по-умному и (не без оснований) этим гордится. В 99% (если не больше) Assistant ясно и понятно отвечает на все вопросы - но все равно это остается "запоминанием" а не "работой мысли"  :) И это "опасно чревато" (мое мнение)

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

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

иначе говоря, я про "повторяемость" и аналогии внутри системы, соответствие своим-же ключевым принципам.


"зубрежка", о которой вы говорите -  отличается объемом.
вы ещё скажите что 1С в этом смысле ничем не отличается от Питона или Qt)

поясню:
1С - надо _весь_ _зубрить_. там практически нет единых на всю систему концепций - его нельзя понять, его можно только вызубрить (имхо). (хрестоматичный пример: задача скопировать объект. итог: в одном месте (таблица значений кажется) для копирования объекта мы берем метод источника и указываем на приемник, в другом (список значений) - мы берем метод приемника и указываем на источник) - и т.д. и т.п. на каждом шагу.)

с Питоном ситуация получше - есть области с едиными подходами и принципами, но пока вот (по прошествии пары месяцев знакомства) я не могу ещё "угадывать" поведение системы, без детального вчитывания в мануалы.
и это я считаю "нехорошимзнаком" - т.к. обычно я относительно легко осваиваюсь с новыми системами, особенно если в них есть "соблюдаемые концепции"... имхо - слишком многое в питоне "не так" )... по сравнению с другими системами,  ... в сравнении с объявляемыми принципами простоты и "логичности"... Соблюдения единых принципов и концепций я пока не шибко много видел, хотя местами вкусно...

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


т.е. QT чем (для меня) привлекателен: есть несколько ключевых концепций, идей и подходов. И они повторяются в подавляющем числе случаев - т.е. это "достаточно стройная система", "логически понятная" - которую практически не надо зубрить - пойми несколько ключевых принципов и "дух системы" - и она "сама начнет разворачиваться" в соответствии со своими ключевыми концепциями ... как фрактал что-ли... объем зубрежа - минимален.

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

а в 1С этой "стройностью" и "логичностью" даже не пахнет)

вот и все имхо)

А  если почитать внимательней про cluttermm ?

Одна из ключевых идей Qt: добавление некоторой инстроспекции в с++. И это в свою очередь позволяет сигнал/слоты.
Все остальное это: удобная нотация и стройная иерархия/архитектура классов.
Количество разработчиков Qt в разы меньше и это позволяет сделать более совершенный код.
Но возможностей доступа к закрытым интерфейсам нет (не считая reinterpret_cast). Мне не нужно эта хваленое разделение труда между программистами через private секции. Я хочу иметь полный доступ ко внутренностям Qt без перекомпиляции.

Ну, ИМХО, это палка с двумя концами:
- с одной стороны - да, это может помочь в решении некоторых проблем разработчика если он хочет расширить функционал Qt, используя её потроха ( в некоторых случаях без этого невозможно "красиво" реализовать ту или иную задумку)
- с другой стороны - для разработчика, который просто пользуется теми классами Qt (паблик) - это не нужно вообще.

Исходя из всего вышеперечисленного (всех постов), читая гугл и т.п., я тоже недоумеваю над приоритетами компании Nokia. Они добавляют всякие (иногда абсолютно ненужные) вещи/фичи/перделки, хотя в это же время имеется куча важных вещей которые они игнорируют.

Например, не совсем понимаю важность добавления классов типа QStateMachne (по крайней мере в таком его виде какой он есть в текущем виде).
Имхо, но довели бы они лучше до ума то что есть, теже сокеты, MVC, и т.п.

Это понятно, что QML и прочий гламур сейчас в моде, но всё-же ....   

Ну хз, сейчас возможно буду писать десктопный (!) проектик, без QML и скриптов там не обойтись

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

Не силен в QML - просто мысли в слух.

http://developer.qt.nokia.com/wiki/Dpointer

>>А  если почитать внимательней про cluttermm ?
Я так же знаю и про GTKmm, и юля толку. труповое это всё. Да и идеи не в GTK рождаются. Они их пытаются только реализовать, также как и все другие.

Ох до чего же я люблю категоричность на русских форумах...
А ну да, конечно...  ;D
Qt лучшее... А их программисты самые лучшие и умные в мире...

На этих С++ биндингах писать не намного сложнее чем на Qt.
Свои Widgets тоже делаются намного проще чем в голом Си (gtk+), почти как в Qt.

И прежде чем про трупы говорить, почитайте про sigc++ (http://libsigc.sourceforge.net/benchmark.shtml)(gtkmm) и как она использовалась в Qt когда-то, и чего может каждая.

+1
"улыбает всю дорогу..."