Проект Necessitas (http://sourceforge.net/p/necessitas/wiki/Home/), в рамках которого ведется работа по адаптации инструментария Qt для платформы Android, анонсировал (http://dot.kde.org/2011/06/01/kde-releases-second-alpha-nece...) перевод разработки под крыло сообщества KDE. По заявлению основателя Necessitas, проект перешел под покровительство KDE так как оба проекта имеют сходные цели - развитие, продвижение и обеспечение свободной доступности Qt. Для разработчиков KDE обеспечение полной поддержки платформы Android в Qt сулит интересные перспективы, связанные с распространением приложений KDE для различных типов мобильных устройств.Одновременно представлен (http://mail.kde.org/pipermail/necessitas-devel/2011-May/0000...) второй экспериментальный релиз системы Necessitas, подготовленный уже с частичным использованием инфраструктуры KDE. Для загрузки доступны (http://sourceforge.net/projects/necessitas/files/) предкомпилированные для Linux и Windows версии SDK Necessita...
URL: http://dot.kde.org/2011/06/01/kde-releases-second-alpha-nece...
Новость: http://www.opennet.me/opennews/art.shtml?num=30757
Когда KDE и Qt в одно сольют?
>Когда KDE и Qt в одно сольют?Судя по http://labs.qt.nokia.com/ Qt быстро движется в сторону QML+js. kde вроде тоже прицеливается в эту сторону.
qml+js отличная штука для разработки быстрых и относительно легковесных приложений - где есть тяжелая логика (например работа с сетью/бд) и простой уй с парой кнопок и лейблов. Естессно кедерастам она нравится - клепать никому не нужные плазмоиды будет проще.
> qml+js отличная штука для разработки быстрых и относительно легковесных приложений"Быстрые и легковесные" и js в одном предложении нельзя использовать. Недоязык JS со своей VM быстрым и легковесным быть не может.
>> qml+js отличная штука для разработки быстрых и относительно легковесных приложений
> "Быстрые и легковесные" и js в одном предложении нельзя использовать. Недоязык JS
> со своей VM быстрым и легковесным быть не может.Вы не правы, тк в qml нет мегасложных конструкций, которые бы жрал время исполнения. У вас единожды грузится qml файл, создаются с++ объекты, их проперти соединяются через qml'ные биндинги. Собственно всё, далее работает с++ код сигналов/слотов. Те немногие ф-ии, к-ые все-таки написаны на js компилируются jit'ом и там в общем тоже нечему тормозить.
> Вы не правы, тк в qml нет мегасложных конструкций, которые бы жрал время исполнения. У вас единожды грузится qml файл, создаются с++ объекты, их проперти соединяются через qml'ные биндинги.Не вижу смысла в этом бреде. Все потребности покрываются uic и ручным созданием объектов - хочешь руками, хочешь формошлёпство. Есть какой-то третий вариант?
> Собственно всё, далее работает с++ код сигналов/слотов. Те немногие ф-ии, к-ые все-таки написаны на js компилируются jit'ом и там в общем тоже нечему тормозить
JIT - это трата CPU на компиляцию при загрузке, которая эту загрузку замедляет. Тормозить там есть чему, т.к. JIT по определению оптимизирует гораздо хуже нормального компилятора. И наконец, всё это традиционно жрёт память. А ради чего? Ради ничего.
> JIT - это трата CPU на компиляцию при загрузке, которая эту загрузку замедляет. Тормозить там есть чему, т.к. JIT по определению оптимизирует гораздо хуже нормального компилятора. И наконец, всё это традиционно жрёт память. А ради чего? Ради ничего."Преждевременная оптимизация - корень все зол." (С)
Только если на оптимизацию забивать, однажды становится понятно что проще всего - стереть всю программу и написать заново...
> Только если на оптимизацию забивать,Если вы не знаете, какая разница между преждевременной оптимизацией и оптимизацией вообще, то сразу видно, что вы сами никогда ничем подобным не занимались, и не представляете себе как это делается.
Юзеры, которые требуют чтобы им все оптимизировали любой ценой, просто других свойств и качеств ПО себе не представляют, кроме скорости.
> однажды становится понятно что проще всего - стереть всю программу и написать заново...
Это почему это по-вашему неоптимизированную программу, которая работает правильно якобы проще написать заново?
Как вы это самое "проще" измеряете?
А преждевременно оптимизированную программу, которая работает неправильно, наверное по-вашему очень легко будет потом заставить работать правильно.
Вы наверное считаете, что скорости добиться по-вашему "сложнее" всего, и об этом по-вашему наверное в первую очередь надо думать.А правильности по-вашему наверное "проще" всего добиться, если программа работает быстро.
> Вы не правы, тк в qml нет мегасложных конструкций, которые бы жрал
> время исполнения. У вас единожды грузится qml файл, создаются с++ объекты,
> их проперти соединяются через qml'ные биндинги. Собственно всё, далее работает с++
> код сигналов/слотов. Те немногие ф-ии, к-ые все-таки написаны на js компилируются
> jit'ом и там в общем тоже нечему тормозить.Заблуждение. На с++ там только примитивы. Всю логику сложных виджетов пишут на js.
судя по http://labs.qt.nokia.com/ и пытаясь понять о чём же там всё-таки речь, замечу что на одном qml всё не заканчивается..
>судя по http://labs.qt.nokia.com/ и пытаясь понять о чём же там всё-таки речь, замечу что на одном qml всё не заканчивается..ну да, QtSvg выкидывают. А widget-ы "оставят для совместимости". Хоть и на этом спасибо.
а при чём здесь QtSvg? виджеты остануться, всё будет хорошо..
>виджеты останутьсяАга, кривая реализация поверх SceneGraph без добавления новых возможностей.
нет, не поврех scenegraph, а почти так же как и раньше
>нет, не поврех scenegraph, а почти так же как и раньшеА тут, выходит, врут?