Мысли по поводу Qt 5 с хабры.
Можно и пообсуждать, но тему создал скорее просто для информации...

Если поддержка OpenGL 2.0 будет обязательной даже для обычных приложений на Qt, то это начало конца. Во всяком случае на linux-десктопах, где ситуация с драйверами на видеокарты не очень хорошая.

Amp, скорее всего, речь идет о поддержке рендеринга окон с использованием OpenGL. Естественно, это вещь опциональная. Она, кстати, и сейчас есть. Только носит статус экспериментальной. Включается только перед компиляцией Qt.

Это сообщение отредактировал(а) bsa - 10.5.2011, 11:48

Судя сегодняшнему посту http://labs.qt.nokia.com/2011/05/11/responses-to-qt-5/ это не опционально. Причем они понимают, что ситуация с драйверами нехорошая.

Amp, мдааааа. судя по этой статье это будет не опционально. Лично по мне, так desktop-программы на линукс не нужны. Достаточно с них серверных решений, а desktop - пускай остаётся для винды. Это моё личное ИМХО. Я, ессно, не настаиваю 

Всё правильно делают.  Спека на OpenGL 2.0 датирована 2004 годом. Если у кого-то не хватает сил реализовать даже такую старую как ### мамонта спеку - он идёт лесом. Семеро одного не ждут.

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

Кроме Windows и Linux, Qt используется в мобильных устройствах. Вот у меня есть электронная книга, в ней Linux с Qt 4.5.2. OpenGL там ни к чему - экран 8 градаций серого, периодически нужно полное обновление экрана с предварительным стиранием следов от предыдущих экранов.

Так и используйте 4.x. Вам что, кто-то запрещает?

У них мотивация следующая: на данный момент разница в цене между SoC с ускорителем и без стремится к нулю, а количество без GPU тоже уменьшается. Таким образом, в ближайшем будущем не останется устройств без аппаратного ускорения графики. А даже если это случится, есть альтернатива, которой занимается сообщество.

Qt 5 -> R.I.P. 

rsm, крткст сстр тлнт ?

 

ИМХО, Qt под соусом JavaScript скатится из фреймворка, позволяющего создавать суровые и шустрые вещи (KDE 3/Trinity) в тормозной кошмар для криэйторов неторопливых калькуляторов и текстовых редакторов. А как это будет работать на мобильных девайсах, лучше даже не задумываться. Интерпретатор JavaScript все пилят и пилят, порой заявляя, что ускорили его на over 9000%, и продолжают пилить дальше... Такими темпами он давно уже должен был начать работать с такой скоростью, что вывод опережал бы ввод.

rsm, согласен, но если JavaScript будет касаться только GUI - то и хрен с ним. Интерфейс пользователя с обновлением 100 fps нужен только в играх. В Qt есть ещё много вкусного, которое, я надеюсь, у них хватит ума не переводить на JS - БД, сеть, потоки, XML, etc.

Начинаю ловить себя на мыслях, что лучше бы Qt рипнулся от недостатка финансирования и остался в моей памяти все таким же"теплым и ламповым" фреймворком  Сообщество бы подобные капительные изменения не потянуло и функциональность библиотеки бы топталась на том же уровне еще несколько лет. Как у тех же GTK+ и wxWidgets.

Amp, ты посмотри по опросам (хотя бы на этом форуме), где находится Qt, а где wxWidgets и Gtk+ вместе взятые.
JavaScript используется только в Qt Quick (QML). Не устраивает скорость? Используй Widget подсистему.

bsa, причем тут опросы? Я понимаю, что Qt популярнее wxWidgets и GTK+ вместе взятых, особенно для коммерческих разработок. Просто случись такая ситуация, что Nokia перестанет поддерживать Qt, сообщество бы не смогло поддерживать те темпы развития библиотеки, которые взяты сейчас. Так, занимались бы мелким багфиксингом.

Я также осведомлен, где там используется JS. Но все эти тенденции с OpenGL и запихиванием самих Widgets в дальний угол меня настораживает. Рассуждать конечно пока рано, посмотрим что будет.

Меня вот это напрягает:


Первое предложение подразумевает возведение больших и страшных мостов C++ -> JavaScript, второе - еще более больших и страшных мостов JavaScript -> C++.


 


Вопрос в том, насколько сложным станет до нее добраться...

так же как и сейчас - просто подключить подходящую библиотеку.

Друзья - у кого ещё навеяло воспоминания про дот нэт? =(

честно говоря - нет. У M$ вроде не предвидется таких глобальных изменений, как у Nokia, поэтому обсуждать будет ли он жить или нет IMHO нет смысла...
ааааа... м.б. у тебя ассоциация с тем, как крупная компания делает жёсткие изменения в framework'е не особо спрашивая мнения разработчиков ? Тогда да. Похоже.

P.S.   Раз уж зашёл разговор про дот.нет, то вот улыбнуло 

На мой взгляд у них жестких изменений не было. Просто прикрутили дополнительную библиотеку для декларативного и аппаратно ускоренного UI (WPF) и положили болт на поддержку старой (WinForms).

MFC - COM - Active-X - WinForms - WPF - Silverlight (скорее всего чего-нить да забыл. добавьте, если вспомните, please)
плюс этот hell с .Net - одна версия несовместима с другой...
IMHO у Qt-шников как-то менее революционно всё происходило

Это сообщение отредактировал(а) borisbn - 15.5.2011, 22:05

Ассоциация в том, что отходят от С++ и там и там. 
Те с шарпом носятся как курица с яйцом, эти похоже с жавой скриптом хотят "носиться"  
Что так си всем неугодил? (предвижу восторженные возгласы kemisto )
И, главное, чем этот жава-скрипт лучше?


Это сообщение отредактировал(а) volatile - 15.5.2011, 23:24

volatile, думаю Вы согласитесь, что для того, чтобы грамотно писать на Си++ (допускать меньше ошибок) нужен бооооольшой опыт, как, например, у Вас, mes, boostcoder, bsa, xvr (извиняюсь перед другими участниками, но перечислял тех, кто "на слуху" - самых активных)... В общем на пальцах 1,5 рук мужно пересчитать. А чтобы писать на C#, JavaScript, php и т.п. опыта можно поменьше, результат получается быстрее, программы становятся надёжнее (при условии одинакового небольшого опыта программиста на Си++ и на др. языках). А что касается скорости и переносимости - так они далеко не всегда нужны...
Вот фирмы и занимают эту (немаленькую) нишу.

Пример из недавней практики: нужно было написать программку, заливающую изображение на imagehost. Покрутился я с Qt (опыт работы с ним почти три года) - и бросил. Решил написать на C#, видя его первый раз в жизни. Вы знаете - получилось. И довольно быстро и просто.

Так что - скажу банальность - IMHO нужно выбирать инструмент под задачу, а задач, решаемых исключительно при помощи Си++ - не так уж и много. Ну... это моё IMHO. Не настаиваю.

Это сообщение отредактировал(а) borisbn - 16.5.2011, 01:49

Спасибо за комплимент, но ставить меня в один ряд с такими ассами пока не стоит.

Примерно такими-же фразами распрощались когда-то с асмом. Похоже С/С++ ждет та-же участь?
Вобще тенденция настораживает (не с Qt, а вообще в программировании). Приложения становятся большими, неповоротливыми.
Такое впечатление, что уже и ОС пишут на чём-то а'ля бейсик. (Виста похоже на 80% на нем написана, после почти провала висты, семерку немного переписали на менее продвинутом языке, чуть побыстрее стала.).
Наверное это правильно. Писать программы так быстрее. А юзеры пусть потом тормозят на четырех-ядерных пнях и выкладывают бабки за гигагагерцы (и произодители харда, тут без работы не останутся). Система... Против нее не попрешь.
Но, честно говоря, немного жаль.

Мы ж рассматриваем изменения в контексте самого фреймворка .NET. MFC - плюсовая технология. COM с Active-X вообще как-то странно ставить в один ряд с библиотеками для построения графического интерфейса. Моя мысль была следующая - они (майкрософт) не заменяли одну библиотеку на другую и не реструктуризировали классы фреймворка. Появлялись дополнительные инструменты и никто (кроме их маркетинга) не заставлял отказываться от старых. 

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