Проект Lighthouse перестал быть экспериментальным и теперь является частью библиотеки. Напомню, что Project Lighthouse служит цели упрощения портирования Qt на другие платформы и является заменой для Qt for Embedded Linux.

Довольно интересно. Примеры Embedded-устройств с ним есть?

Ох, да неужели?!

Наконец-то! ВУУУУХХХУУУУУ!!!

Аж не вериться! Теперь появилась поддержка некоторых ну очень вкусных фич C++11, и, помимо всего, можно будет нормально делать списки инициализации!

И наконец-то можно будет получить возвращаемое значение слота из другого треда без использования передаваемых указателей!

Я джва год^W полгода ждал этот релиз!

Кеды 4.8 будут на этой версии, интересно?

почти весь лайтхаус пока используется для этого, а на Qt-Embedded кто-то делал интернет киоски и т.п. http://code.google.com/p/android-lighthouse/

Кеды 4.8 будут на этой версии, интересно?

А с чего бы им не использовать свежую версию? Разработчики гарантируют бинарную совместимость в пределах одной minor версии, так же они стремяться ее не ломать в пределах major версии. Поэтому в некоторых случаях можно обойтись даже без пересборки Qt. Для KDE необходима некая минимальная версия, а все что выше, должно работать. Если разработчики дистрибутива включат Qt 4.8 в дистрибутив и соберут KDE с этой версией, значит будет использоваться версия 4.8.

И наконец-то можно будет получить возвращаемое значение слота из другого треда без использования передаваемых указателей!

Ничего не понял. Можешь по-подробнее обрисовать проблему?

Ждём разлома сборки коряво написанных приложений :)

https://bugreports.qt.nokia.com/browse/QTBUG-17359

https://bugreports.qt.nokia.com/browse/QTBUG-10440

превосходно

Добавлена возможность одновременного доступа из нескольких потоков к OpenGL

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

вкупе с оптимизацией kde 4.8 - звучит сладкой музыкой

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

Аж не вериться! Теперь появилась поддержка некоторых ну очень вкусных фич C++11, и, помимо всего, можно будет нормально делать списки инициализации!

Пруф? Новые слоты, как я понимаю, не попали?

http://labs.qt.nokia.com/2011/05/26/cpp0x-in-qt/

http://developer.qt.nokia.com/doc/qt-4.8/qt4-8-intro.html

C++11 support: Qt supports some of the features of the C++11 standard. QList, QVector and QStringList can be initialized with initializer lists. Most of the tool classes have a move operator. It is possible to use lambda functions in some of the QtConcurrent functions.

Новые слоты планируют в Qt5

Добавлена возможность одновременного доступа из нескольких потоков к OpenGL.

как?

Добавлена возможность одновременного доступа из нескольких потоков к OpenGL.

Отлично!

К сожалению, следующим будет Qt 5.0, в котором поломают весь API и начнут задвигать C++ в дальний угол :(

http://labs.qt.nokia.com/2011/06/03/threaded-opengl-in-4-8/

поломают весь API и начнут задвигать C++ в дальний угол :(

А что будет вместо плюсов? Какой-нибудь Пхитон? Или собственная разработка?

Добавлена возможность одновременного доступа из нескольких потоков к OpenGL.

Вот это довольно полезно, да.

JavaScript

Long live Qt!!!

Long live KDE!

А что будет вместо плюсов? Какой-нибудь Пхитон? Или собственная разработка?

Для ГУИ - QML + JavaScript. В остальном останется С++.

А что будет вместо плюсов? Какой-нибудь Пхитон?

Пихтон тогда уж. Анаграммировать так анаграммировать :)

К сожалению:

Следует ожидать, что с течением времени все интерфейсы будут написаны на QML. JavaScript основным в сообществе Qt, и мы должны ожидать, что большая часть логики приложений и даже целые приложения будут написаны на JavaScript, а не C++. Ожидается, что многие разработчики приложений на уже сейчас начнут с QML и JavaScript, и будут реализовывать функции на C++ лишь тогда, когда это требуется. В некоторых случаях, вся мощь C++ API, предлагаемая Qt, может быть использована для реализации критичных по времени и сложных по функциональности приложений.

Нездоровая тенденция.

nice.
Но из всего этого для меня важней OpenGL, и C++0x.чую будет срач, видел тред на одной странице.

qt

Связь с OpenGL еще понятна, но зачем с http, webkit? Мне казалось что qt - это графический тулкит, а тут прям целый emacs

global lock ?

＞Мне казалось

Тебе показалось.

Просто вспомнил недавно висевшее в моём вузе объявление:

Требуются программисты на Django + Phyton

Ну и вдогонку:

Separate all QWidget related functionality into its own library While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term.

Когда они окончательно выпилят QWidget, будем ждать форка :)

Нокла - вселенское зло.

Отличная новость, ждём qt5, 2012 и модульности

Связь с OpenGL еще понятна, но зачем с http, webkit?

Очень удобно писать кроссплатформенные вещи. На всех поддерживаемых платформах всегда с собой куча батареек.

Когда они окончательно выпилят QWidget, будем ждать форка :)

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

Поддерживаю начинание. Действительно, как правило, совсем небольшая часть интерфейса требует нативного кода. Меньше нативного кода — выше переносимость. Я когда-то давно мечтал чтобы вместо свинга в жаве были биндинги к куте. Проект существовал, но мёртвенький.

Их ОП не ясно, какая же версия Qt 4.8 вышла. По-русски будет так: «Вышла новая версия Qt: 4.8»

Для ГУИ - QML + JavaScript. В остальном останется С++.

Не только для гуи, но и для всего остального. c++ останется только для написания расширений как это сделано, например, в XUL. Да и вообще, вызов QML из c++ очень кривой. Использование findChild и setProperty с названиями функций и объектов в виде строк наплодит ещё большее число ошибок, которые не выявить на этапе компиляции. Собственно, сами кутешники рекомендуют свести взаимодействие между QML и С++ к минимуму. Иными словами, на JS придётся писать не только гуй, но и логику.

Наконец то появилась пассивная динамическая тесселяция классов. Мы так этого ждали.

Поддерживаю начинание. Действительно, как правило, совсем небольшая часть интерфейса требует нативного кода. Меньше нативного кода — выше переносимость. Я когда-то давно мечтал чтобы вместо свинга в жаве были биндинги к куте. Проект существовал, но мёртвенький.

Код с использованием Qt вполне себе переносимый. Не вижу смысла превращать каждое приложение в браузер. Пусть и с JSON-разметкой.

Qt не GTK, это фреймворк, а не тулкит.

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

Какая радостная новость.

давно пора

Добавлена возможность одновременного доступа из нескольких потоков к OpenGL.

Вот это правильно, это хорошо, теперь тормозящий гуй не будет виден в системном мониторе, просто видуха закипит и отрубится, только и всего. Лепота!

Когда они окончательно выпилят QWidget, будем ждать форка :)

Форкать надо уже сейчас. В 5-й ветке уже слишком много изменений, нацеленных именно на QML. Например, зависимость от OpenGL в QtGui. По этой причине софт на базе QWidgets будет грузить с собой пачки либ OpenGL и никак их не использовать. Впрочем, поддерживать QWidgets в рамках 5-го Qt нокия тоже не собирается и энтузиастов, желающих бесплатно работать в этом направлении на горизонте пока тоже не видно.

Yeah

Ненене, теперь без видяхи Qt будет тормозит в 2^N раз лучше, как Gnome3 поначалу

Использование сторонних библиотек в проектах на куте сопряжено с гемороем вот и лепят все вподряд.

К сожалению, следующим будет Qt 5.0, в котором поломают весь API и начнут задвигать C++ в дальний угол :(

Некто Aaron Seigo, говоря о перспективах KDE 5 и о том, что это будет эволюционный релиз, направленный на стабилизацию, упоминал, что больших изменений в Qt 5 также не ожидается. Поэтому не понятно откуда вообще инфа.

Читал стандарт, но никаких QList и QVector там не упоминается? Нахрена вообще было писать этот кривоватый аналог STL.

Напомню, что Project Lighthouse служит цели упрощения портирования Qt на другие платформы и является заменой для Qt for Embedded Linux.

Если сравнить http://developer.qt.nokia.com/doc/qt-4.8/supported-platforms.html и http://developer.qt.nokia.com/doc/qt-4.7/supported-platforms.html, то получается что будет работать на 3-х ОС только

Ты не понял о каких тормозах речь. Время от времени на некоторых каталогах вкладка konqueror начинает моргать и выжирать всё ядро процессора. Моргает она до тех пор пока не перейдёшь в другой каталог. Внешне это не всегда заметно а в системном мониторе хорошо видно: загрузка конгуерором ядра на 100% - ищи глючную вкладку. Если несколько таких глючных приложений дорвутся до ресурсов видухи, это будет абзац, перезапускай иксы если успеешь.

konqueror не юзаю, но файрфокс тоже так подлит, правда видно, что флеш жрёт всё
думаю умные люди сделают системный монитор для видяхи.