Разработчики из компании Nokia объявили (http://labs.qt.nokia.com/2012/04/03/qt-5-alpha/) о выпуске первой альфа-версии Qt 5 (http://qt-project.org/wiki/Qt-5-Alpha), первый значительный выпуск, развиваемый (http://www.opennet.me/opennews/art.shtml?num=32103) при непосредственном участии сообщества в рамках нового полностью открытого процесса разработки и управления проектом. Qt 5 позиционируется в качестве фундамента для реализации новых путей разработки приложений. При сохранении всех инструментов по созданию Qt-программ на языке C++, в Qt 5 акцент смещается в сторону использования C++ в основном для создания функциональности модульных бэкендов для Qt Quick, т.е. для реализации критичных ко времени выполнения или излишне сложных частей программы, в то время как простые Qt-приложения могут быть написаны полностью на JavaScript, без использования C++.
В ветке Qt 5.x отмечается (http://wiki.qt-project.org/Transition_from_Qt_4.x_to_Qt5) нарушения совместимости с Qt 4.x на бинарном уровне и частично на уровне исходных текстов. К моменту релиза планируется подготовить набор средств для упрощения адаптации кода существующих проектов для Qt 5.x. Тем не менее, нарушающие совместимость изменения в основном связаны с чисткой устаревших компонентов, поэтому адаптация современных проектов потребует минимальных изменений. Например, в текущем виде единая кодовая базе Qt Creator успешно собирается с использованием Qt 4.x и Qt 5.
Ключевые архитектурые изменения Qt 5:- Перевод всех портов на использование уровня абстракции Qt Platform Abstraction layer (QPA), основанного наработках проекта Lighthouse (http://labs.qt.nokia.com/category/labs/lighthouse/). QPA значительно упрощает перенос Qt на новые оконные системы и устройства, так как он изначально оперирует более абстрактными категориями, фундаментально отличаясь от ранее используемых средств интеграции с оконными системами. Например, уже написаны бэкенды для QNX, Android и iOS. В настоящее время реализация QPA уже входит в состав Qt 4.8, в касестве замены QWS/Qt Embedded, но в Qt 5 данная прослойка будет задействована для всех платформ, что потребовало существенно переработки огромной части кода, связанного с обеспечением поддержки различных платформ.
- Изменение архитектуры графического стека и увеличение производительности графических операций. В качестве центрального элемента новой архитектуры для Qt Quick выступает QML Scenegraph, работающий поверх OpenGL. Для работы Qt 5 система должна поддерживать как минимум OpenGL (ES) 2.0.Поддержка QPainter сохранена для выполнения расширенных функций, но ограничена возможностью использования бэкенда программной растеризации вывода (Raster), бэкенда OpenGL и бэкенда для вывода на печать и создания PDF. Поддержка привязанных к платформам бэкендов, таких как X11 и CoreGraphics, прекращена. QWidgets теперь отображается поверх графической сцены, а не наоборот, как реализовано в версии Qt 4, что позволило перейти в Qt 5 на принципиально новую графическую архитектуру, сохранив при этом совместимость с Qt 4.
В QtGui добавлен набор классов QOpenGL*, заменивших собой устаревшие классы QGL*, которые пока оставлены для обеспечения совместимости. Также представлен класс QGuiApplication, которые заметно легче классов QApplication и QWindow при выполнении задач обработки корневого окна на экране.
- Модульная структура (http://www.opennet.me/opennews/art.shtml?num=28425) репозитория. Многие из подсистем Qt разрабатываются разными группами разработчиков, развиваются с повышенной интенсивностью или плотно зависят от сторонних проектов. При грамотном разбиении фреймворка на модули, подобные подпроекты смогут обновляться и поставляться независимо от других частей Qt. Модульная организация репозитория позволит обеспечить сборку отдельных библиотек без загрузки и пересборки всех зависимостей, а также независимое использование каждой библиотеки. Разработчики интенсивно развивающихся подсистем QtWebKit и QtDeclarative получат возможность не ждать когда подтянется другой код и выпускать релизы значительно чаще. Кроме того, модульная структура существенно упростит приём в состав Qt модулей, созданных сторонними проектами, например, проект KDE намерен добиваться интеграции в Qt некоторых своих библиотек общего назначения. Ожидается, что разбиение на модули будет длительным и постепенным процессом, который будет продолжен и после выхода релиза 5.0.- Выделение всех связанных с QWidget возможностей в отдельную библиотеку. Несмотря на то, что основанные на QWidget классы чрезвычайно важны для существующих приложений, общая тенденция ведёт к тому, что все пользовательские интерфейсы должны быть реализованы на QML и Qt Quick. Отделение связанных с QWidget функций в отдельную библиотеку позволит в долгосрочной перспективе сохранить чистоту архитектуры Qt 5.
Новые возможности:
- Qt Core:- Класс QStandardPaths для определения стандартного местоположения на текущей платформе таких данных, как мультимедиа файлы и документы;- В состав включен парсер формата JSON и оптимизированное для более высокой скорости обработки бинарное представление для данных JSON;- Поддержка определения meme-типа как по расширению, так и по содержимому;- Включение в состав движка для обработки регулярных выражений, полностью совместимых с Perl;- Переписаны и оптимизированы для увеличения производительности многие структуры данных;- Добавлена поддержка стандарта C++11, но сохранена возможность сборки и при помощи компиляторов, совместимых с C++98.
- Qt Gui: Как было отмечено выше, классы QWidget вынесены в отдельную библиотеку QtWidgets. В QtGui добавлена поддержка OpenGL и возможность работы через класс QWindow с поверхностями корневого экрана;
- Qt Network: Добавлена поддержка выполнения DNS-запросов. Удалены классы QHttp и QFtp, которые вынесены в отдельные модули;- Qt Widgets: Осуществлено портирование на новую архитектуру QPA с сохранением полной совместимости с Qt 4.x;
- Qt Quick: Полностью совместимая с Qt 4.x реализация Qt Quick оформлена в виде модуля Qt Quick 1, который подготовлен только для обеспечения обратной совместимости и не будет развиваться в будущем. Реализация Qt Quick для Qt 5 разделена на отдельные модули, с графической частью и с компонентами поддержки языков QML и JavaScript. Связанные с выполнением JavaScript классы (QJSEngine и QJSValue) теперь базируются на движке V8, позволившем достигнуть более высоких результатов производительности. В движок QML также внесены значительные оптимизации производительности и связанные с языком улучшения, при сохранении базовой совместимости. Модуль Qt Quick включает в себя реализацию Scenegraph на базе OpenGL и все ранее поддерживаемые в Qt 4.x базовые возможности. Дополнительно добавлена поддержка графических эффектов, создаваемых при помощи шейдеров OpenGL.- Добавлены модули Qt 3D и Qt Location для интегарции 3D-контента с Qt и для взаимодействия с GPS и другими сервисами определения местоположения;- C++ API Qt WebKit не изменился по сравнению с Qt 4.x, но осуществлён переход на более новую версию движка WebKit, что привело к улучшению поддержки технологий HTML 5.
URL: http://blog.qt.nokia.com/2012/04/03/qt-5-alpha-is-here-provi.../
Новость: http://www.opennet.me/opennews/art.shtml?num=33527
>Для работы Qt 5 система должна поддерживать как минимум OpenGL (ES) 2.0.Привет llvm-pipe?
Он работает на уровне старого софтварного растера, какие вообще проблемы?
Т.е. без 3D-ускорителя кеды теперь работать не смогут вообще?Ну, то есть, понятно, что проблема не в железке - 3D нынче не умеет ускорять только ленивый, но вот драйверы, драйверы.. Последнее поколение видях от ATI и NVidia по-моему еще не поддерживают ускорение в открытых дровах, несмотря на то, что прошло несколько месяцев с момента выхода 7xxx серии...
http://wiki.x.org/wiki/RadeonFeature
Ок, с ATI значит совсем плохо, для S.Islands все 3D-фичи либо WIP, либо TODO - т.е. неизвестно, когда появятся.А с Nvidia последними что?
Да ладно КЕДы, даже простенькие фигульки :)
поддерживают
Что-то катится некогда замечательный фреймверк в какую-то степь.
>>При сохранении всех инструментов по созданию Qt-программ на языке C++, в Qt 5 акцент смещается в сторону использования C++ в основном для создания функциональности модульных бэкендов для Qt Quick, т.е. для реализации критичных ко времени выполнения или излишне сложных частей программы, в то время как простые Qt-приложения могут быть написаны полностью на JavaScript, без использования C++.Странное мышление... В чем выгода? Как минимум теперь надо будет 2 языка знать чтобы полноценно использовать. Запутали все очень....
Из шикарного фреймверка для окошек и кросплатформенного программирования сделали монстра похлеще WEB...Нокия облажалась теперь и с Qt. Очень жаль.
Хуже, что теперь проекты на QWidgets придётся насильно в гроб загонять.
Ретрограды детектед. Я вот рад, что наконец-то в Линуксе порядок начали наводить и выпиливать всякий deprecated хлам.
Про deprecated. QHttp - с каких времен обещались выпилить в угоду QNetworkManager-у?
Про QWidgets. Ткните носом в рабочую альтернативу. Именно виджетов, а не "слепи себе сам из QML". Чтоб готовые гриды, чекбоксы, комбобоксы...
http://qt.gitorious.org/qt-components/desktop Пользуйтесь на здоровье.
Вигода в том, что при разработке софтины можно сначала быстро накидать код на JS, а потом уоптимизироваться по самое немогу переписывая узкие места на плюсах. Но только там и тогда, когда это действительно надо. Причём заметь, сказано что простые Qt-приложения _могут быть написаны_ на JS. Не хочешь — лабай всё на плюсах и не парься на счёт JS.
Да и что плохого в знании двух ЯП? Лично я считаю, что знать меньше двух ЯП — позор для программиста.
>Да и что плохого в знании двух ЯПГолова, говорят, взорвется.
http://www.meddaily.ru/article/21Feb2011/izu4inostr_yazТак-то.
Надо знать 2 языка: C и C++ :) Ну ладно, еще Bash не повредит ;)
> Да и что плохого в знании двух ЯП? Лично я считаю, что
> знать меньше двух ЯП — позор для программиста.Ничего плохого нет, но нафига нужно обучаться именно JS в добавок к С++? Значительно лучше выучить Prolog и Haskell. Но время-то тоже не резиновое.
> Нокия облажалась теперь и с Qt. Очень жаль.во-первых, уже не нокия.
во-вторых, кто сказал, что возможность писать на c++, как раньше писали, выпилят?
в-третьих: прямо в новости о выходе говорится, что всё бросать и бежать, намылив органы, переделывать софт под Qt 5 не надо: Qt 4 ещё вполне живой, никто его не объявлял устаревшим.
но мы ж тут оригиналы не читай @ каменты оставляй, да.
ура! Qt живее всех живых и развивается бешеными темпами! весь свой софт пишу последнее время исключительно на Qt... правда на Qt 4.8.x пока еще
> ура! Qt живее всех живых и развивается бешеными темпами! весь свой софт
> пишу последнее время исключительно на Qt... правда на Qt 4.8.x пока
> ещеЧему радуетесь-то? Очередному bloatware?
Предложите лучшую реальную альтернативу.Уверен, что многие программисты, которым нужно решать реальные задачи, а не разводить споры на форумах моментально "прозреют" и начнут использование этой чудо-технологии.
Задаю условия:
1. кроссплатформенность (Qt, в том числе 5-й версии портирован даже на Haiku),
2. поддержка сети, графики, SQL, т.е. сравнимый по возможностям с Qt,
3. подходит для широкого круга приложений (т.е. не узкоспециализированная),
4. подходит для решения реальных задач (т.е. проверено по надежности, удобству и скорости разработки, имеет достаточную документацию и поддержку).Набор библиотек, также хорошо согласованных между собой тоже подходит. Вариант "Qt - отстой, но нет ничего лучше," - не катит, реальные задачи нужно решать здесь и сейчас, а не когда произойдет чудо (иначе нишу на ранке займет конкурент с еще худшей технологией).
P.S. Qt обычно используют как разделяемые библиотеки, которые используют половина программ в системе, поэтому набор программ, каждая со своим мегаоптимизированным набором библиотек пролетает как по месту на диске и в оперативке, так и по суммарным затратам на разработку.
P.P.S. Идеалисты, которые любят кричать: "Технология XXX - полный отстой", когда дело доходит до реализации реального проекта, либо осознают, что порют чушь, либо предлагают решение по стоимости реализации сравнимое с пилотируемым полетом на Марс.
P.P.P.S. Когда заявляешь: "Технология xxx - отстой", полезно уметь различать - "отстой, потому что мне больше нравится другая технология" и "отстой, потому что не подходит для решения конкретной реальной задачи в условия реальных ограничений на решение этой задачи". Т.е. если нужно кроссплатформенное решение, то .NET в пролете, сколько бы он тебе не нравился.Ну и напоследок: - не нравится - проходите мимо. Молча.
>1. кроссплатформенность (Qt, в том числе 5-й версии портирован даже на Haiku),Я скажу круче, они собираются выкинуть весь слой совместимости с beos в отдельную либу и переписать весь гуй на Qt.
>>1. кроссплатформенность (Qt, в том числе 5-й версии портирован даже на Haiku),
> Я скажу круче, они собираются выкинуть весь слой совместимости с beos в
> отдельную либу и переписать весь гуй на Qt.Кто нибудь вообще пользуется хайку? И для каких целей?
>>>1. кроссплатформенность (Qt, в том числе 5-й версии портирован даже на Haiku),
>> Я скажу круче, они собираются выкинуть весь слой совместимости с beos в
>> отдельную либу и переписать весь гуй на Qt.
> Кто нибудь вообще пользуется хайку? И для каких целей?Это секрет. Никто не скажет, но заминусуют.
> Кто нибудь вообще пользуется хайку? И для каких целей?Гоняю на P4 (Dell Opteron 260) в качестве просмотрщика сети. Браузер WebPositive+Djvu+PDF. Ну и пишмашинка теоретически. Самое смешное, что на этом железячном говне всё, включая браузер, работает крайне быстро.
Не дай бог, впилят QT.
> Гоняю на P4 (Dell Opteron 260)Дьявол, ошибся вечером - Dell Optiplex GX260. Гайка работает значительно быстрее родных для этой машины WinXP.
Можно посмотреть в сторону Java, там все это есть.
>Предложите лучшую реальную альтернативу.Java
>Уверен, что многие программисты, которым нужно решать реальные задачи, а не разводить споры на форумах моментально "прозреют" и начнут использование этой чудо-технологии.
Довольно часто случается что Qt не покрывает реальные задачи.
Простой пример необходимо взять данные из таблицы и сохранить в эксель-файл, и всё нет никакой кроссплатформенности и необходимо изобретать велосипеды.
Чуть более редкий протокол чем http и ftp и опять велосипеды в пути. Ну и так далее. Правда если рассматривать разные биндинги, особенно pyqt/pyside все становиться более-менее радужно.
А что такое "эксель-файл"? Это не та ли закрытая проприетарщина, формат которой не известен даже самой Мелкософт? ;) Ну так купи у Мелкософта права на этот формат, выложи патч для Qt, сообщество тебе спасибо скажет :)
> А что такое "эксель-файл"? Это не та ли закрытая проприетарщина, формат которой
> не известен даже самой Мелкософт? ;) Ну так купи у Мелкософта
> права на этот формат, выложи патч для Qt, сообщество тебе спасибо
> скажет :)Что такое "эксель-файл" и еще много странных для себя слов вы узнаете от реального заказчика. Который платит реальные деньги и хочет реальную программу работающую с теми технологиями которые выберет заказчик.
Реальные пацаны выбирают "эксель-файлы"
> Что такое «эксель-файл» и еще много странных для себя слов вы узнаете
> от реального заказчика. Который платит реальные деньги и хочет реальную программу
> работающую с теми технологиями которые выберет заказчик.есть ещё вариант: «ищи себе другой ансамбль, дядя!» но, конечно, code monkeys никто не спрашивает, они про такой вариант только мечтать могут.
> Который платит реальные деньги и хочет реальную программу
> работающую с теми технологиями которые выберет заказчик.Никак реальная сессия скоро...
> А что такое "эксель-файл"? Это не та ли закрытая проприетарщина, формат которой не известен даже самой Мелкософт? ;) Ну так купи у Мелкософта права на этот формат, выложи патч для Qt, сообщество тебе спасибо скажет :)Замени эту "гадкую проприетарщину" эксель на "кошерно-православный" ODF , разницы для Qt не будет, не поддерживает и всё тут.
> Ну так купи у Мелкософта
> права на этот формат, выложи патч для Qt, сообщество тебе спасибо
> скажет :)Сообщество Qt может взять открытые исходники у "клятых и тормозных java и python", на которых сохранение данных в excel не просто, а очень просто. А если очень постарается то зайдет на сайт микрософт.ком и скачает пэдэфку с даташитом этих форматов.
> и скачает пэдэфку с даташитом этих форматовСуществование этих даташитов отнюдь не означает, что микрософт им следует
>Существование этих даташитов отнюдь не означает, что микрософт им следуетКак тебе это помешает сохранить в файл данные? Почему для других платформ это не проблема.
Просто интересно, сколько времени уйдёт у вас на чтение более 6 тыщщ страниц доков...
Я уж не говорю об осмысливании и следовании ЭТОМУ...
> Просто интересно, сколько времени уйдёт у вас на чтение более 6 тыщщ
> страниц доков...
> Я уж не говорю об осмысливании и следовании ЭТОМУ...Вот просто странно, что тут люди 100 килобайт работающего кода уложились, правда?
http://pypi.python.org/pypi/xlwt
> Простой пример необходимо взять данные из таблицы и сохранить в эксель-файл, и
> всё нет никакой кроссплатформенности и необходимо изобретать велосипеды.Ваш эксель-файл не кросс-платформенен. Конечно, я не буду задавать вопросы, типа "а на хуа он на Linux'е", но имейте всё-таки совесть. :-)
>> Простой пример необходимо взять данные из таблицы и сохранить в эксель-файл, и
>> всё нет никакой кроссплатформенности и необходимо изобретать велосипеды.
> Ваш эксель-файл не кросс-платформенен. Конечно, я не буду задавать вопросы, типа "а
> на хуа он на Linux'е", но имейте всё-таки совесть. :-)С какого это он кроссплатформенен? Есть доказательства?
> С какого это он кроссплатформенен? Есть доказательства?Чукча - писатель. :-) :-) :-)
Из того, что заказчику нужен эксель-файл (хоть убейся головой об стену - нужен), автоматически выплывает следствие "на хуа" линукс?К счастью, проблема не в линуксе, а лишь в отдельных "кроссплатформенных" средствах разработки ))
> К счастью, проблема не в линуксе, а лишь в отдельных "кроссплатформенных" средствах
> разработки ))Есть такая дрянь, да. Это ещё хрен знает когда по-поводу QT же отмечал такой В. Вагнер. Что эта библиотека всё делает не очень - под Win выглядит не родным образом, под X Window хранит настройки не там, где нужно, гоняет битмапы.
В общем, да, утка - она всё делает хреново. Ну и подход - сделаем свою однозадачную ОС на базе Win32/NT и X/GNU/Linux - это порочный подход. :-(
> Поддержка привязанных к платформам бэкендов, таких как X11 и CoreGraphics, прекращена.Пока, нормальная сетевая прозрачность. Мы будем тебя вспоминать!
> нормальная сетевая прозрачность:-D лет тридцать назад была нормальная, сейчас - динозавр
> :-D лет тридцать назад была нормальная, сейчас - динозаврЗнаете, самый простой способ запустить Mathematica не на своей машине - это через ssh, пользуясь этой самой "динозаврической" сетевой прозрачностью.
>> нормальная сетевая прозрачность
> :-D лет тридцать назад была нормальная, сейчас - динозаврПозвольте поинтересоваться, на скольких хостах Вам доводится работать и по какой географии?
Мои раскиданы на более чем тыщу километров, минимум на три (порой -- больше) регулярно шарюсь ssh -Y или по NX, вплоть до ежедневно.
меня одного напрягают эти Qml-ы и жабоскрипты?
Чем плох интерфейс, написанный на скриптовом языке, который обращается к ядру приложения, написанному на плюсах? Blender так сделан (Python интерфейс и C++ ядро). Единственная неприятность, которую я заметил - в таких приложениях обычно отсутствует внешний вид схожий с системной темой оформления (у них обычно своя тема, написанная на том самом QML). Но, наверняка автору приложения нужно очень постараться, чтобы нельзя было вернуть системную тему оформления простой заменой CSS (или что там используется).
> Чем плох интерфейс, написанный на скриптовом языке, который обращается к ядру приложения,
> написанному на плюсах? Blender так сделан (Python интерфейс и C++ ядро).
> Единственная неприятность, которую я заметил - в таких приложениях обычно отсутствует
> внешний вид схожий с системной темой оформления (у них обычно своя
> тема, написанная на том самом QML). Но, наверняка автору приложения нужно
> очень постараться, чтобы нельзя было вернуть системную тему оформления простой заменой
> CSS (или что там используется).Qt Components умеют QStyle дергать, а с ним можно абсолютно нативный вид сделать как и было в QtWidgets'ах. Да и можно же оборачивать просто нативные виджеты в QmlItem'ы и вообще не парится. На маке так точно этот финт ушами прокатывает.
Предлагаете заниматься велосипедописанием? Надеюсь интерфейс как раз таки наоборот по-умолчанию будет нативным, а дальше - делай что хочешь!
Учись искать информацию самостоятельно
http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/
> Учись искать информацию самостоятельно
> http://labs.qt.nokia.com/2011/03/10/qml-components-for-desktop/Я не говорил что этого нету (а статью эту я ещё в первый день прочитал), а я про то, что если вдруг они решать сделать единый интерфейс, то с чего вдруг это если это противоречит всей истории Qt?
ну с qml я ещё могу как нит сдружится, если я правильно понял, то это язык __описания__ гуйни. Но вот зачем остальные скриптовые языки приплетать для чистого программирования? Что только люди не придумаю, лижбы память не освобождать...
>Blender так сделан (Python интерфейс и C++ ядро)Неправда. На Python там опциональные расширения, работать он и без python может.
Нет, не только вас. У людей какое-то ЖС-помешательство: то виртуальные машины пишут, то сервера приложений в вебе (НодЖС). Вобщем, суют его куда непопадя без разбору, а потом плачут: ошибки, утечки, медленно работает... Такими темпами через 10 лет не будет программистов, которые могут в Си, одни ЖС быдло-кодеры остануться.
чистой воды правда. Но пичально...
> Нет, не только вас. У людей какое-то ЖС-помешательство: то виртуальные машины пишут,
> то сервера приложений в вебе (НодЖС). Вобщем, суют его куда непопадя
> без разбору, а потом плачут: ошибки, утечки, медленно работает... Такими темпами
> через 10 лет не будет программистов, которые могут в Си, одни
> ЖС быдло-кодеры остануться.Си на сегодняшний момент, один из самый простых языков, тем более академически преподаваемых, правда чтобы написать что-то значительное, требуется много времени и много сторонних компетенций, так что вы не бойтесь за быдло-кодеров, на Си их будет всегда больше чем где-то ещё исключая PHP.
Ядро языка, да простое (проще чем та же ява), а вот дальше всё не так тривиально,и чтобы написать что-то сложнее сортировки массива, требуются довольно-таки широкие знания мат. части.
> Ядро языка, да простое (проще чем та же ява), а вот дальше
> всё не так тривиально,и чтобы написать что-то сложнее сортировки массива, требуются
> довольно-таки широкие знания мат. части.Так я про то и написал. Только думаю что всякая гопота кричащая что "имя_языка" не нужно/тормоз и т.п., если и знает Си то на этом самом тривиальном уровне.
>Такими темпами через 10 лет не будет программистов, которые могут в СиНе нужно нас хоронить.
А ведь кеды только-только допилили :(
Я к тому что Арон Сейго говорил, что работы по переводу на Qt5 начнутся как только так сразу.
ну выкинут весь софт, которому нужен Qt3Support и пофиксят хедеры, делов то.
где они его допили отрисовка как тормозила так и тормозит.
man Qt Render Engine. Тормозят иксы, а не кеды. Когда уже это люди поймут...
> man Qt Render Engine. Тормозят иксы, а не кеды. Когда уже это
> люди поймут...Плохому танцору...
... кеды мешают? :)
Есть ли у пятых кед шанс выйти одновременно с Qt5? Может они полегче-побыстрее будут.
>Есть ли у пятых кед шанс выйти одновременно с Qt5? Может они полегче-побыстрее будут.Легче не будут точно. Надеюсь, что хоть без регрессий.
Они портировали v8 на ту кучу архитектур, работал раньше Qt? Или из список теперь заметно похудел?
> Они портировали v8 на ту кучу архитектур, работал раньше Qt? Или
> из список теперь заметно похудел?http://ru.wikipedia.org/wiki/V8_(%D0%B4%D0�...)
Операционная система
Microsoft Windows, Mac OS X, FreeBSD, HP webOS и LinuxАппаратная платформа
x86, ARM
> Перевод всех портов на использование уровня абстракции Qt Platform Abstraction layer (QPA), основанного на наработках проекта Lighthouse. QPA значительно упрощает перенос Qt на новые оконные системы и устройства, так как он изначально оперирует более абстрактными категориями, фундаментально отличаясь от ранее используемых средств интеграции с оконными системами. Например, уже написаны бэкенды для QNX, Android и iOS. В настоящее время реализация QPA уже входит в состав Qt 4.8, в качестве замены QWS/Qt Embedded, но в Qt 5 данная прослойка будет задействована для всех платформ, что потребовало существенно переработки огромной части кода, связанного с обеспечением поддержки различных платформ.Правильно ли понимаю что теперь Android будет поддердиваться официально, т.е. теперь, для написания прог для Android можно обойтись без necessitas?
> Правильно ли понимаю что теперь Android будет поддердиваться официально, т.е. теперь, для
> написания прог для Android можно обойтись без necessitas?В будущем прост оветки слияют и всё думаю.
KDE 5.0 != KDE 5
Поддержка Json - это конечно очень хорошо. Но зачем его пихать QtCore?
Почему нет и куда его пихнуть?
В Network не катит, т.к. вполне может пригодиться и для файлов без юзания сети.
> Поддержка Json - это конечно очень хорошо. Но зачем его пихать QtCore?А куда еще сериализацию пихать как не в ядро.
Вероятно, раз многое там можно сделать на яваскрипте (даже целиком программу), то очень удобно и яваскриптовые объекты в "родном" яваскриптовом формате гонять - сериализовывать/десериализовывать для сохранения объектов на диск или передаче по сети. Наверное можно много причудливых и полезных решений придумать.
Никогда не понимал, в чем Qt лучше скажем FLTK. Все дополнительные фичи в Qt означают только лишнюю головную боль.
> Никогда не понимал, в чем Qt лучше скажем FLTK. Все дополнительные фичи
> в Qt означают только лишнюю головную боль.это потому что вы считаете Qt графической библиотекой, а это нечто пытающейся быть платформой и во многом это у кьюта получается, sql,вектор,3d,сеть.
>> Никогда не понимал, в чем Qt лучше скажем FLTK. Все дополнительные фичи
>> в Qt означают только лишнюю головную боль.
> это потому что вы считаете Qt графической библиотекой, а это нечто
> пытающейся быть платформой и во многом это у кьюта получается, sql,вектор,3d,сеть.Да... SQL есть. Но сравнивать с платформами .net или java еще очень рано. Из коллекции можно вытянуть несуществующий элемент и это действительно будет объект созданный с пустым конструктором... Сеть тоже весьма причудлива(10-20 последовательных запросов при помощи QNetworkManager-а сделают ваш код очень очевидным). Так что пытаются - да, другой вопрос на сколько это у них получается.
> Да... SQL есть. Но сравнивать с платформами .net или java еще очень
> рано. Из коллекции можно вытянуть несуществующий элемент и это действительно будет
> объект созданный с пустым конструктором... Сеть тоже весьма причудлива(10-20 последовательных
> запросов при помощи QNetworkManager-а сделают ваш код очень очевидным). Так что
> пытаются - да, другой вопрос на сколько это у них получается.Согласен. Поэтому я и написал "пытающиеся быть платформой".
С другой стороны есть PySide, который тоже Qt, но в котором этих проблем нет ибо python.
Очередной неосилятор из пещеры с дизель генератором и радиоприемником?
Что такое неосилятор я не знаю, но простые решения сложных проблем уважаю.
> Никогда не понимал, в чем Qt лучше скажем FLTK.Чисто как тулкит -- гораздо более качественной поддержкой i18n/l10n; IIRC с переводами, размещением виджетов и текстов в фултике всегда были изрядные проблемы.
Ну вот. Опять КДЕ сломают.
Наоборот.
Нечётные версии КДЕ стабильнее.
;)
И никто не обратил внимание, что там теперь для работы OpenGL нужен, т.е. если у вас нет или не работают дрова для видеокарты, то вы в пролете. Вот это будет фурор! А ведь даже блоб нвидии не очень хорошо работает с новыми картами(2х летней давности), про нуво вообще молчу, от них вообще глупо ждать что-то рабочее. Так что выходит, что для линукса все программы на Qt5 будут выкинуты в виду неработоспособности(хотя КДЕ4 и так уже признали нерабочим трупом).
На все остальное можно было закрыть глаза, даже на всякие там джабаскрипты (надеюсь его можно будет выпилить), но вот OpenGL это перебор. Я даже не упоминаю про встраиваемые системы, в которых часто нельзя задействовать DSP, потому как разработчики делают блобы только для определенных систем и всяким энтузиастам работа с OpenGL может только сниться.
Надеюсь форкнут Qt4, он действительно оправдал надежды и много всего в нем было сделано правильно, но с Qt5 разработчиков понесло.Да даже представим, что у нас в системе работает 3Д ускорение (ну может у нас венда), так чтобы отобразить Hello World нужно будет разогревать видеокарту, на которой может быть охлаждение куда мощнее(и громче), чем на центральном процессоре, а уж про энергопотребление и речи нет - видеокарта всегда потребляет больше. Т.е. все эти заигрывания с новомодными технологиями выходят боком для пользователей в итоге.
Ну и про JS - представим себе приложение, которое должно работать 24x7, если в нем будет хоть немного кода на JS то в итоге это приложение(а вернее встроенный в нее интерпретатор) съест всю память(или большую её часть), и чем это чудо будет от Java тогда отличаться? Выйдет тоже самое, вид сбоку. Те же утечки и тормоза.
Может разработку Qt5 спонсировал Майкрософт?
Подумайте, почему MS Office не пишут на JS(и не встраивают его туда), может потому, что от этого приложения требуется отзывчивость и работа подолгу? А не как сейчас в браузерах - один раз сайт отобразил, выполнил пару инструкций(со страшными тормозами) и сайт закрыл.
Ну ты выдал. Пьян? Такой бредятины я еще не читал.
> Ну ты выдал. Пьян? Такой бредятины я еще не читал.С чего это пьян? Бредятина в голове у разработчиков, которые хотят из десктопного тулкита сделать какой-то веб на коленке с JS и CSS.
Сейчас Qt является единственным более менее доделанным мультплатформенным тулкитом с нативной отрисовкой виджетов на каждой из платформ (ну или почти нативной). Ничего такого среди других тулкитов даже близко нет, да к тому же Qt еще и фреймворк(а не просто набор кнопочек и контролов). Все его части очень тесно друг с другом интегрированы, что позволяет делать более качественный код(не нужно искать ошибки в api разношерстных библиотек).
Нет, ну может вам удобнее на .Net писать и вы считаете Mono отличным выходом. А может вам нравится GTK+, ведь для него так удобно в макоси запускать иксы, лишь бы только отобразить hell world. А может быть скажите, что самое то это FLTK без поддержки юникода?
Реальной альтернативы нет.
>> Ну ты выдал. Пьян? Такой бредятины я еще не читал.
> С чего это пьян?Можно например сходить сюда http://ru.wikipedia.org/wiki/OpenGL
> Сейчас Qt является единственным более менее доделанным мультплатформенным тулкитом с нативной
> отрисовкой виджетов на каждой из платформ (ну или почти нативной)Смелое такое замечание, мало коррелирующее с действительностью.
>Надеюсь форкнут Qt4, он действительно оправдал надежды и много всего в нем было сделано правильно, но с Qt5 разработчиков понесло.Пока желающего форкнуть этого монстра на горизонте не видно. А 5-ка это другой продукт, практически. Лучше бы его переименовали, чтобы не вводить в заблуждение. А вот ещё интересные планы http://lists.qt-project.org/pipermail/development/2012-April...
По ссылке шутка скорее всего.Я думаю что Qt4 еще долго просуществует и в основных дистрибутивы его будут собирать, а дальше видно будет.
>По ссылке шутка скорее всего.Шутка, шуткой, но по сути кое-что является правдой. Тот же JS в ущерб C++.
>Я думаю что Qt4 еще долго просуществует и в основных дистрибутивы его будут собирать, а дальше видно будет.Скорее всего загонят всех на Qt5. QtWidgets присутствуют и их можно использовать. Единственное, развития в этом направлении уже не будет.
> Шутка, шуткой, но по сути кое-что является правдой. Тот же JS в ущерб C++.Если уж быть совсем честным - то там необязательно все на JS писать, но именно такой путь написание, по мнению разработчиков, является истинно верным, вот это и огорчает.
> Скорее всего загонят всех на Qt5. QtWidgets присутствуют и их можно использовать. Единственное, развития в этом направлении уже не будет.
Можно посмотреть что произошло с выходом KDE4 - народ просто ушел с KDE, потому что понимает, что этим пользоваться нельзя. Тут я думаю будет тоже самое - некоторые пересилили себя, поломали несколько стереотипов, докупили железо в 3 раза мощнее и они смогли как-то использовать KDE4(с падениями и глюками), но таких не большинство.
Если при переходе с Qt3 на Qt4 был слой совместимости и можно было с минимальными затратами портировать своё приложение на новую версию фреймворка, то при переходе на Qt5 предлагают переписать приложения кардинально или использовать какие-то костыли, но переписывать придется в любом случае. Не думаю что многие на это пойдут. Да, они оставили QtWidgets, но если оно не будет развиваться, то кому такое надо?
И еще тут подкрадывается другая сторона - Qt на мобильных платформах. Хоть народ и орет, что ничего нет, а Nokia N9 продолжает продаваться и приложения потихоньку делают. Конечно не миллионами, но все-же движение есть. Вот что будет с ними? Всех заставят переписывать приложения для нового фреймворка? Что-то сомневаюсь. Думаю там и будет продолжать жить Qt4 или даже благодаря им.
> Если при переходе с Qt3 на Qt4 был слой совместимости и можно
> было с минимальными затратами портировать своё приложение на новую версию фреймворка,
> то при переходе на Qt5 предлагают переписать приложения кардинально или использовать
> какие-то костыли, но переписывать придется в любом случае.круто. люблю оналитегов, которые читать ничего по теме не прочитали, зато какие Глобальные Выводы делают! так держать, может, со временем тебя примут в журналисты: они тоже феерически безграмотны, зато мастерски описывают, как всем будет плохо.
> круто. люблю оналитегов, которые читать ничего по теме не прочитали, зато какие Глобальные Выводы делают!Рады стараться. Чего там читать? Ежу понятно, что если раньше сцену можно было на OpenGL встроить в QtWidget, то теперь QtWiget будет поверх сцены, которая всегда будет OpenGL и это отнюдь не в пользу системам, у которых OpenGL до сих пор нормально не поддерживается, даже при наличие железа(потому что дров нет полноценных, линукс в их числе).
> так держать, может, со временем тебя примут в журналисты: они тоже феерически безграмотны, зато мастерски описывают, как всем будет плохо.
Поздно уже предостерегать.
мне потом отсыпешь. Если бы ты внимательней читал, то Raster Engine, никто, никуда не выкинул.
> Надеюсь форкнут Qt4, он действительно оправдал надежды и много всего в нем
> было сделано правильно, но с Qt5 разработчиков понесло.тыц разработчики кутэ теперь такиеже анонимусы как ты. и там подумали не то что дважды а у всех заинтерисованных была возможность высказаться и обсудить. насчёт яваскрипта уже работает 24/7 и память там не съедается потомучто обрабатывает нужные события(и в целом является замечательной заменой питоноскриптам). яваскрипт это не ява.
Большинство вообще считает, что венда это верх совершенства, так что какой смысл у них спрашивать?
Какой смысл высказываться, если они сделают в итоге так, как захотят.По поводу скриптинга - уже давно существует QtScript, который почти никто не использует и это было хорошо. А теперь всех будет загонять в это скриптовое счастье.
Я, в принципе, не против скриптинга, но для этого есть Lua, ничего более не нужно, не нужны там никакие пистоны с джаваскриптами.
К слову сказать, я понимаю разницу между JS и Java, а еще лучше я понимаю, что на Java можеть быть написан качественный код, который не будет жрать память дуром и который даже, возможно, будет по скорости всего в 2 раза медленнее С++. Но когда толпы быдлокодеров ринутся из веба в Qt, вот тогда и будут выходит быдлоподелки тысячами.
Я думаю - сделали бы скриптинг на Lua, раз уж так зачесалось, зачем приплетать сюда этот ужасный JS.
Честно признаюсь, я не тестировал производительность V8, когда они официально выпустят - можно будет посмотреть, но когда вспоминаю, как текла память с CSS, то могу себе представить что это будет.
кто в лес, кто по дрова…кстати: не покажешь ли Lua-биндинги для Qt такого же уровня, как у QtScript? видишь ли, js знают достаточно много людей, в том числе связаных и с созданием интерфейсов.
а ещё я хочу узнать, что такого «ужасного» в js (кроме того, похоже, что ты его не знаешь)?
Lua-биндинг? Зачем? Есть С++. Все эти биндинги для тех, кто ничего не понимает и понимать не хочет, но хочет что-то сделать. Если хочешь писать на Qt - учи С++ или пиши на чем-нибудь другом.
Можно встроить Lua для скриптования в приложение, у него очень компактный рантайм и код достаточно простой. QtScript был для того же.JS просто очередной скриптовый язык, вопрос именно в рантайме, в том, что для его выполнения, зачастую тратится очень много ресурсов. Я не буду вдаваться в подробности, про отсутствие наследования и другие мелкие недочеты, это скорее все вкусовщина.
Я имел в виду другое - представим, что у вас есть приложение, которое работает 24*7 и оно по коллбеку выводит какие-то данные, допустим, для этого надо создавать новый объект. Если бы это был код на С++, то контроль создания и времени жизни объекта можно четко проконтролировать. Если же подобный код на JS, то у нас есть только надежда на то, что сборщик мусора правильно удалит старые объекты через какой-то промежуток времени. А если у нас создание объектов происходит с наносекундными интервалами, когда сборщик мусора это все уберет? Вот представим, что у нас такое больше приложение, которое постоянно выводит кучу постоянно меняющейся информации(типа систем контроля доступа на больших предприятиях или систем по контролю за производством), сколько тогда памяти будет утекать и какой её объем будет нужен?
Если это простое приложение(блокнот какой-нибудь), которое вы каждый день отключаете и включаете, то его можно и на пистоне написать, все равно его каждый день перезагружаете. А вот для серьезных задач такое не пойдет.
> Lua-биндинг? Зачем?затем, что там выше были слова по поводу «если уж скриптинг — давайте Lua». ну вот я и предлагаю показать, как её давать.
> Есть С++. Все эти биндинги для тех, кто ничего не
> понимает и понимать не хочет, но хочет что-то сделать. Если хочешь
> писать на Qt — учи С++ или пиши на чем-нибудь другом.точно? и иначе никак? какая досада. придётся теперь забрать у клиентов весь софт, а то там у меня морда на вебките вообще сделана.
> про отсутствие наследованиявот дальше про JS с тобой вообще можно не говорить, твои знания в нём на уровне «а в китайском какие-то закорючки непонятные!»
> А если у нас создание объектов происходит с наносекундными интервалами
то в консерватории всё неверно. буквально: всё. и язык тут никак не поможет, ошибка в DNA.
> сколько тогда памяти будет утекать и какой её объем будет нужен?
судя по твоему описанию — вся и ещё чуть-чуть, пофигу, будет там JS, C++, C, assembler или вообще сразу хексдампами.
> А вот для серьезных задач такое не пойдет.
конечно, там мозг нужен. человеческий. который сначала всё правильно спроектирует.
> затем, что там выше были слова по поводу «если уж скриптинг — давайте Lua». ну вот я и предлагаю показать, как её давать.Все так, скриптинг на уровне автоматизации рутинных задач, а вот биндинг это уже создание программ на скриптовом языке с использованием библиотек другого языка.
Если брать конкретные примеры
PyQt - биндинг Qt для Python
libqtlua - встраиваемый в программу интерпретатор(вирт. машина)
Задачи у них различаются. А теперь нам говорят, что надо будет использовать, по сути, биндинг JS к Qt. Вот тут уже и появятся все эти тормоза и пожранная память.> вот дальше про JS с тобой вообще можно не говорить, твои знания в нём на уровне «а в китайском какие-то закорючки непонятные!»
В рамках общего обучения проходил да потом еще несколько сертификатов получил, это было 4 года назад, ничем примечательным этот язык не запомнился и в дебри не вдавался. На практике не применял его, не было повода.
> точно? и иначе никак? какая досада. придётся теперь забрать у клиентов весь софт, а то там у меня морда на вебките вообще сделана.
Почему сразу такой экстремизм, зачем переписывать то, что уже работает?
Если программа нужна для коротковременного отображения информации, то можно на чем угодно её написать. Я же писал про софт, который работает 24/7, у которого контроль потребляемых ресурсов куда выше.> судя по твоему описанию — вся и ещё чуть-чуть, пофигу, будет там JS, C++, C, assembler или вообще сразу хексдампами.
Сборщики мусора для сбора и сделаны, а при чем тут хексдампы и что вы под этим подразумеваете?
Всякий бред и переходы на личности опустил.
> Все так, скриптинг на уровне автоматизации рутинных задач, а вот биндинг это
> уже создание программ на скриптовом языке с использованием библиотек другого языка.можно чёткую границу?
> по сути, биндинг JS к Qt. Вот тут уже и появятся
> все эти тормоза и пожранная память.а почему у меня не появляется? O_O
> В рамках общего обучения проходил
причём мимо. я вот, например, хаскеля не знаю: так я о нём и молчу. такой вот намёк.
> Если программа нужна для коротковременного отображения информации, то можно на чем угодно
> её написать. Я же писал про софт, который работает 24/7, у
> которого контроль потребляемых ресурсов куда выше.у меня софтина с мордой на вебките (и частью логики на js) работает как раз месяцами. не падает. память не выжирает. я опять в ней что-то неправильно написал, видимо.
> Сборщики мусора для сбора и сделаны, а при чем тут хексдампы и
> что вы под этим подразумеваете?а при том, что проблема в описываемом тобой раскладе вовсе не в JS, а в прокладке, которая между креслом и клавой.
> Я думаю - сделали бы скриптинг на Lua, раз уж так зачесалось, зачем приплетать сюда этот ужасный JS.http://www.nongnu.org/libqtlua/
http://savannah.nongnu.org/projects/libqtlua/
не Lua -> Qt, а Qt -> Lua
Что нужно этому OpenGL?
Теперь придется к каждому бухгалтерсому компу видуху докупать для юзания Qt-софта?
Нет, просто вылезти из криокамеры.
>> Нет, просто вылезти из криокамеры.люди привекли чужими бабками сорить и думают - нормально.
а на самом деле это сродно воровству.
В обычных офисных компах встроенное видео - стандарт.
Не понимаю, зачем отдельная видеокарта для обычного бухгаллтерского, менеджерского или секретарского компа.
То есть это или интел, или амд...опенгл будет там искаропки.
С разморозкой!
>> Не понимаю, зачем отдельная видеокарта для обычного бухгаллтерского, менеджерского или секретарского компа.
>> То есть это или интел, или амд...опенгл будет там искаропки.
>> С разморозкой!Спасиб.
Не спец по железу вот и спросил.
поясните, я этот QML и просто QPainter без OpenGL юзать cмогу в 5-й версии Qt?
я так понимаю что все спорные неуниверсальные улучшения должны быть опциональныс другой стороны, стоит помнить что некросовтовский wpf работает на видухах с дырехттридэ - вот так...
> поясните, я этот QML и просто QPainter без OpenGL юзать cмогу в
> 5-й версии Qt?
> я так понимаю что все спорные неуниверсальные улучшения должны быть опциональны
> с другой стороны, стоит помнить что некросовтовский wpf работает на видухах с
> дырехттридэ - вот так...Программную эмуляцию ни кто не отменял. Тормозить, правда, будет. А виджеты будут работать как и раньше.
> Программную эмуляцию ни кто не отменял. Тормозить, правда, будет. А виджеты будут
> работать как и раньше.А с чего оно будет тормозить-то? Как-то раньше на всяком старье не тормозило, показывая диалоги, так а сейчас-то с чего должно?
>> Программную эмуляцию ни кто не отменял. Тормозить, правда, будет. А виджеты будут
>> работать как и раньше.
> А с чего оно будет тормозить-то? Как-то раньше на всяком старье не
> тормозило, показывая диалоги, так а сейчас-то с чего должно?Очевидно, из-за эмуляции OpenGl.
что вы понимаете под словом "эмуляция"? Софтварный рендер для диалогов покажет результаты не хуже Raster Engine и уж получше X11 рендера.
>что вы понимаете под словом "эмуляция"? Софтварный рендер для диалогов покажет результаты не хуже Raster Engine и уж получше X11 рендера.А что, для перевода OpenGl вызовов в растр процессор уже не нужен? И, кстати, вижу что товарищ не в курсе, что такое QML.
>>что вы понимаете под словом "эмуляция"? Софтварный рендер для диалогов покажет результаты не хуже Raster Engine и уж получше X11 рендера.
> А что, для перевода OpenGl вызовов в растр процессор уже не нужен?
> И, кстати, вижу что товарищ не в курсе, что такое QML.О_о и чтож такое QML по анонимусу?
Лучший Qt, это Enlightenment, точнее efl.
тыц ефл уже тоже фрэймфорк?
Включение в состав движка для обработки регулярных выражений, полностью совместимых с Perl; ура самые удобные регулярные выражения без перла! крутокрутокруто.