Компания Digia объявила (http://blog.qt.digia.com/blog/2013/05/14/qt-5-1-beta-released/) о начале тестирования бета-выпуска Qt 5.1. Релиз Qt 5.1.0 планируется выпустить до начала лета. Для упрощения установки тестовой версии, кроме исходных текстов, предоставлен бинарный пакет с инсталлятором.
При подготовке ветки Qt 5.1 основные усилия были направлены на оптимизацию производительности и улучшение работы возможностей, изначально представленных в Qt 5.0. Новые ключевые возможности Qt 5.1 Beta:
- Модуль Qt Quick Controls с набором готовых компонентов для построения интерфейса пользователя, ориентированных на десктоп-приложения, создаваемые с Qt Quick;
- Модуль Qt Quick Layouts представляющий легкий и более интуитивно понятный способ управления масштабированием пользовательских интерфейсов, гарантирующий неизменное расположение элементов на экранах с разным разрешением;- Модуль Qt Serial Port с реализацией кросс-платформенного интерфейса для обращения к аппаратным и виртуальным последовательным портам;
- Поддержка совместного использования Qt Quick и классических виджетов в одном окне приложения;
- Поставка нового выпуска Qt Creator 2.7.1 (http://blog.qt.digia.com/blog/2013/05/14/qt-creator-2-7-1-re...), предоставляющего такие новшества, как улучшенная поддержка C++11 и Qt Quick Designer для быстрого создания прототипов интерфейса;
- Поддержка статических сборок Qt, позволяющая обойти ситуации, когда нет возможности использовать динамическое связывание;
- Модуль Qt Sensors переведён в категорию официально поддерживаемых модулей;
- Возвращена поддержка платформы Windows Embedded Compact 7;
- Экспериментальная поддержка платформ Android и iOS:
- Для платформы Android доступны такие возможности, как виджеты (widgets), Graphics View, приложения с Qt Quick 1, Qt Quick 2, OpenGL, сетевые функци, отдельные элементы Qt Multimedia (QML media player), поддержка датчиков (сенсоров) в Qt Sensors. Отладка и установка приложения может осуществляться непосредственно из Qt Creator;
- Для платформы iOS использование Qt Quick 2 невозможно из-за необходимости создания нового движка QML. Из поддерживаемых функции отмечены: виджеты (widgets), Graphics View, приложения с Qt Quick 1,
OpenGL, работа с сетью, Qt Sensors, возможность установки приложения на устройство из XCode/iTunes.
Одновременно можно отметить (https://plus.google.com/u/0/102024182244414154266/posts) развиваемый независимым сообществом проект (http://qt-project.org/wiki/tizen) по создания порта Qt 5 для мобильной платформы Tizen. Целью проекта является обеспечение возможности разработки мобильных приложений для платформы Tizen с использованием Qt Quick 2 и обеспечение средств для их бесшовной разработки в Qt Creator.
<center><iframe width="640" height="360" src="http://www.youtube.com/embed/GSzLDkNLkeE?rel=0" frameborder="0" allowfullscreen></iframe></center>URL: http://www.digia.com/ru/Digia/1/News/qt-5-1-beta-released/
Новость: http://www.opennet.me/opennews/art.shtml?num=36939
Qt Creator->мулти-селект фаилов когда добавят?
хочется одним взмахом все стереть. :)
так мультиселект - свойства QFileDialog, или QTreeView/QListView и пр. так что и исходники в руки ;)
Большая проблема QML - трудность обмена данными с С++. Получается весьма громоздго, со всеми этими дефайнами/гетерами/сетерами. Но самое страшное - это передача коллекций обьектов... Вроде, говорят пишите логику на плюсах, а интерфейсы на QML, но на деле получается дофига костылей.
Так же в стандартных компонентах куча всяких мелких недороботок, с документацией проблемы, а они занимаются портированием на разные платформы.
Qt уже не торт.
Нормальные люди юзают С и гтк
Эти Ваши "нормальные" люди - ненормальные извращенцы.
> Нормальные люди юзают С и гткПисать интерфейсы на портабельном ассемблере в 2013-м году! Поручик, вы такой затейник!
Видимо мы с вами в меньшинстве.
Никаких трудностей не испытываю, не забывай что есть несколько способов достучаться из Qml`я в плюсовый код.
Писать геттеры/сеттеры/сигналы не затрудняет. С коллекциями объектов всё тоже очень хорошо, смотря что нужно, можно использовать QList<..>(чаще всего использую QVariantList, внутри какие-нибудь QVariantMap), QAbstractItemModel based классы, в крайнем случае еще есть чисто qml`ные вещи, вроде DeclarativeModel. Не знаю где здесь нужны костыли.В контролах если есть недоработки, всегда для вас открыт багтрекер, имхо дженс ошибки очень оперативно исправляет. С документацией если проблемы - смотри примеры и код. Работа на разных платформах как бы ключевая вещь в Qt`е. Старайтесь реже говорить людям, что им делать, а то как-то некрасиво получается.
>достучаться из Qml`я в плюсовый код.Ты исходное сообщение читал вообще? Там про обратную задачу, если что.
гм, извиняюсь
>Большая проблема QML - трудность обмена данными с С++.Она на это и не рассчитана. C++ только для написания расширений, которые на жобаскриптах не написать, или они будут тормозить. Впрочем, если уж тащить с собой жабоскрипты, то смысла в использовании плюсов и нет совсем. Только если компонент какой написать.
Qml это не javascript, если что. Из qml`а вызывается js движок, по мере надобности.
Например, как вы реализуете работу с файловой системой из Qml`а?
>Qml это не javascript, если что. Из qml'а вызывается js движок, по мере надобности.Например, как вы реализуете работу с файловой системой из Qml'а?
Спасибо, КЭП. Но движок жабоскрипта там прибит гвоздями. Он используется для пересчёта координат, например. Заменить его на питон или другое по вкусу не представляется возможным. В общем кури исходники и доки.
Да, гвоздями, но js движок загружается только когда нужен. Код открыт, заменяй, но я бы не советовал. Спасибо за совет.
А вы не пользуйтесь C++. QT - это среда для разработки приложений на JavaScript. C++ там спрятан под капот.
Да ну?Это только для QML частично верно. И то QML + JavaScript там в основном для описания поведения интерфейса (один из вариантов, так как QWidget и прозводные никто не прячет).
Основа - все равно C++.
C++ forever, QML must died.
Лол. Поясню немного, а то что-то школьники-студенты, которые не писали на этом самом QML ничего сложнее калькулятора или примеров с шариками минусуют.По поводу гетеров/сетеров - да, один/два не так сложно, но есть такая штука как ОРМ, которая работает со структурами, в которых бывает по 10-15 полей. В С++ коде просто заполняем поля, скармливаем ОРМу и впуть. Чтоб выдать это в QML мне надо описать эти самые 10-15 гетеров/сетеров. Весело, неправда ли? Конечно, можно описывать не для всех полей, а только тех что надо и получать обьекты-огрызки.
Когда нада передать в QML список обьектов, как я говорил, все еще хуже. Можно отдать QList, но ТОЛЬКО стандартных для QML типов. Свои типы, вроде как рекомендовали оборачивать в Variant(добавля ОЧЕРЕДНУЮ метадату к обьектно), но не тут то было, ведь есть вот это: https://bugreports.qt-project.org/browse/QTBUG-25194 Багу год, между прочим. Но выход есть, а именно другой костыль - QDeclarativeListProperty. Почему костыль? Да потому что взять, наприме один обьект, в QML из этой коллекции низзя. Нельзя сделать ее ReadOnly, а ведь во многих случаях добавления элементов туда вообще не имеет смысла. Да достаточно взглянуть на то, как оно реализуется в C++ со всякими там статическими методами... Так же мне нравится, что там есть конструктор из QList, который вызывает утечки памяти, что сказано прям в документации. НО это еще не все: в QML есть различные View для представления обьектов, но данная коллекция не может быть использована как model, к этим самым View.
Для View нам рекомендуют использовать в качестве моделей из C++ либо спиоск строк(кому оно вообще надо?), либо лист указателей на QObject в для которых задекларированы property(!!!). К слову, к элментам моделей просто так из QML обращаться нельзя, т.е. проблему выше это не решает(хотя есть еще костыли, как делать это через прокси View, но...). Казалось бы - вот оно решение, НО View не реагирует на изменения в модели. ЛОЛ. Т.е. при изменеии данных, пользователь этого не увидит(ну если не перестроить View заного). Для решения этой проблемы нужно создавать наследника QAbstractItemModel в котором специально для QML сделали костыль из RoleNames(привет Си!). Теперь доступ к данным происходит на основании сравнения значения енума, ведь типизация не нужна, да. Думаете это решение всех бед?! Ну конечно нет, если коллекция не плоская, и какой то ее эллимент - это коллекция, то доступа к ней у вас не будет. QTBUG-25194. И вот тогда приходится добавлять в модель еще QDeclarativeListProperty, которая по индексу вернет коллекцию.
В результате биндинги из C++ в QML могут иметь больше файлов и кода, чем сам код C++. Офигеть.
По поводу документации: вопервых для многих новых QML обьектов ее просто нет(ну или не было еще пару месяцев назад, ща не проверял). Во вторых они с чего то взяли и сменили структуру сайте, и теперь многие ссылки в инете(в том числе и на багтрекер) ведут в никуда, просто редирект на главный сайте.
Ну и баги в компонентах: везде! Скролл из кода того же ListView до какого элемента происходит без анимации. Решение - костыль в виде самостоятельной анимации и использовании свойств, которые документация использовать не рекомендует. Передача сообщение от той же мыши для вложенных MouseArea невозможно(покрайней мере в 4.8, в 5ке, вроде, были какие то подвижки). WebView - вообще один сплошной баг. От невозможности использования anchor scroll на страничке и до проблем с ресайзом https://bugs.webkit.org/show_bug.cgi?id=90421. Стоит ли говорить, что взаимодействие с JavaScript внутри WebView происходит через строки? В 5ке webview переписали, но всеравно есть проблемы, народ на форумах жалуется, что оно течет. Недокументированный Experemental api - это вообще пушка.
Короче проблем когда сталкиваешься много. Некторые можно поправить, некоторые, как говориться, broken by design. Но чего я не понимаю, это то чем занимаются троли. Портируют на разные платформы, добавляют модули и тд. Да кому оно вообще нужно такое вот? Тот же JavaScript с современным количеством ГУИ фреймворков намного чище и проще.
>[оверквотинг удален]
> на страничке и до проблем с ресайзом https://bugs.webkit.org/show_bug.cgi?id=90421.
> Стоит ли говорить, что взаимодействие с JavaScript внутри WebView происходит через
> строки? В 5ке webview переписали, но всеравно есть проблемы, народ на
> форумах жалуется, что оно течет. Недокументированный Experemental api - это вообще
> пушка.
> Короче проблем когда сталкиваешься много. Некторые можно поправить, некоторые, как говориться,
> broken by design. Но чего я не понимаю, это то чем
> занимаются троли. Портируют на разные платформы, добавляют модули и тд. Да
> кому оно вообще нужно такое вот? Тот же JavaScript с современным
> количеством ГУИ фреймворков намного чище и проще.QML сам по себе не так уж плох. Эдакий аналог HTML5, но с разметкой JSON. Минус в том, что HTML5 как-никак стандартизирован, в отличие от этого QML. Кроме того, я не вижу смысла таскать JS-движок для приложений уровня плеера. Минус также ещё в том, что тролли забили на всё остальное, в частности, на "устаревшие виджеты". Это я к тому, что портировать приложение с Qt4 на Qt5 смысла практически нет. Нет там ничего такого особенного, кроме увеличенного потребления памяти и новых глюков.
>QML сам по себе не так уж плох.Я согласен, но некоторые проблемы тянутся с релиза.
> Я согласен, но некоторые проблемы тянутся с релиза.Недописал. Ощущение такое, что посоны пытаются укусить больше, чем могут сьесть в конкретный момент. А пока будут жевать, жаваскрипт займет таки мобильники, за которые они так бьются. Да и на десктопе уже можно кое-чего делать.
Смотри в 5.1 MEMBER у Q_PROPERTY - можно больше не прописывать геттеры@сеттерыQList - не умеет оповещать о изменениях коллекций, да проблема, приходится вешать сигнал
С другой стороны в QList(QVariantList) довольно удобно засовывать вообще кучу всего, потом содержимое прекрасно отображается через вьюхи(у нас работают только с ListView, TableView и Repeater`ами, на счет остальных не в курсе).QAbstractItemModel - да слишком накрученная и переусложнённая вещь, но используем, удобно
Посмотри ещё модели в приватных классах qml`ных, вроде их можно использовать и они простые. Посмотри модели из Cascades.
QDeclarativeListProperty - да, когда первый раз увидел этот класс, не очень был готов к такому.
QTBUG-25194 - написано же, что пофикшенно в Qt5.
С QWindow баг вроде должны пофиксить.
С анимацией скролов фейл, но и понятно - виджеты.
С MouseArea - бесит.
View реагирует на изменения в модельках - отдельно тестил.
>Смотри в 5.1 MEMBER у Q_PROPERTY - можно больше не прописывать геттеры@сеттерыОтлично!
>QList - не умеет оповещать о изменениях коллекций, да проблема, приходится вешать сигнал
А кто реагирует на этот сигнал? Как обновляется View? Инкрементально?
>С другой стороны в QList(QVariantList) довольно удобно засовывать вообще кучу всего, потом содержимое прекрасно отображается через вьюхи(у нас работают только с ListView, TableView и Repeater`ами, на счет остальных не в курсе).
Видимо, это уже в 5ке.
>QAbstractItemModel - да слишком накрученная и переусложнённая вещь, но используем, удобно
Не переусложнённая, а костыль. Енумы для определения типов, это конечно что-то...
>Посмотри ещё модели в приватных классах qml`ных, вроде их можно использовать и они простые. Посмотри модели из Cascades.
Ok, спасибо.
>QDeclarativeListProperty - да, когда первый раз увидел этот класс, не очень был готов к такому.
Еще один костыль.
>QTBUG-25194 - написано же, что пофикшенно в Qt5.
А что, куте4 уже не поддерживается? Во всех дистрах, вроде, еще 4ка.
>View реагирует на изменения в модельках - отдельно тестил.
Да, на QAbstractItemModel точно.
Но это только то что вспонил, что-то помелочи регулярно всплыает. В виджетах такого не было, все было, как говорится, solid.
>> А кто реагирует на этот сигнал? Как обновляется View? Инкрементально?Передаешь сигнал, на него реагирует, работает так же как все динамические биндинги
Как-то решили сидеть на Qt5, поэтому последнее время с Qt4 не сталкиваюсь, а то что кеды и Qt софт на 4ке сидят, это дело времени, кидал ссылку здесь уже виден прогресс по портированию кед.
>Как-то решили сидеть на Qt5, поэтому последнее время с Qt4 не сталкиваюсь, а то что кеды и Qt софт на 4ке сидят, это дело времени, кидал ссылку здесь уже виден прогресс по портированию кед.Реалии таковы что есть парк машин, на которых ОС с куте 4 в репах. Да и в проэкте используется WebKit, который в 5.0(где я последний раз тестировал) показал себя не с лучшей стороны касательно ресурсов.
Ну если бы сильно нужно было, всегда можно придумать репу с Qt5 и подключить её.(Хотя работает - не трогай).
На счет вебкита - меня немного смутило зависимость на icu(порядка 30Мб). Ну и да, не так уже его приятно использовать из квика со всеми этими экспериментальными Апи. Мы в итоге его выпилили.:)
>Ну если бы сильно нужно было, всегда можно придумать репу с Qt5 и подключить её.(Хотя работает - не трогай).Да, придумать можно, но параллельно поставить еще одну куте, прямо говоря, дело не очень триваильное. Проще LD_PRELOAD или скомпилить статически, наверно. Но да, основная причина в том, что 5.0 не выглядел production-ready.
Скорее всего с 5.1 надо будет уже что-то думать(даже наверно с 5.1.1 или типа того), если таки не получится отказаться от Qt совсем в пользу JS.
С 5.1 якобы починили статическую сборку, хотя и до этого всё было терпимо
За много лет до появляения Qt5 Thiago написал утилиту qtchooser она позволяет загружать нужную версию приложения с нужными либами, внутри там всё очень простоЗависит от контекста, для меня звучит как-то совсем нереально - свичнуться на js с Qt`а.
А шустренький эмулятор телефона для Tizen.
И эффекты органично-симпатишные. Хотеть.
ты можешь юзать неоф сборки для десктопов
Когда уже пошьют пятые кеды? С ними, надеюсь, будет не жизнь, а сказка.)
На новом 8-ми ядерном процессоре с 16 Гб оперативы (:
не так прожорливы кеды, как их малюют
Твоя сказка в захламлённом xsession-errors. )
http://community.kde.org/Frameworks/Building
Хм. Полноценный фреймворк? Было бы отлично, если при этом не разжиреет до невменяемых размеров.