Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > С/С++: Кроссплатформенное программирование, Qt/Gtk+/wxWidgets > [Qt5] Статья с хабры про Qt 5


Автор: borisbn 10.5.2011, 10:29
http://habrahabr.ru/blogs/qt_software/118964/ с хабры.
Можно и пообсуждать, но тему создал скорее просто для информации...

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

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

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

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

Автор: kemiisto 11.5.2011, 19:08
Цитата(Amp @  11.5.2011,  17:20 Найти цитируемый пост)
Причем они понимают, что ситуация с драйверами нехорошая. 

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

Автор: Amp 11.5.2011, 19:40
Цитата(kemiisto @  11.5.2011,  19:08 Найти цитируемый пост)
Если у кого-то не хватает сил реализовать даже такую старую как ### мамонта спеку - он идёт лесом.

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

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

Автор: kemiisto 12.5.2011, 08:17
Цитата(math64 @  12.5.2011,  07:10 Найти цитируемый пост)
Кроме Windows и Linux, Qt используется в мобильных устройствах.

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

Автор: bsa 12.5.2011, 12:21
Цитата(math64 @  12.5.2011,  08:10 Найти цитируемый пост)
Вот у меня есть электронная книга, в ней Linux с Qt 4.5.2. OpenGL там ни к чему - экран 8 градаций серого, периодически нужно полное обновление экрана с предварительным стиранием следов от предыдущих экранов. 

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

Автор: rsm 12.5.2011, 17:31
Цитата(http://habrahabr.ru/blogs/qt_software/118964 @  Мысли по поводу Qt 5)
JavaScript

Qt 5 -> R.I.P. smile

Автор: borisbn 12.5.2011, 17:34
rsm, крткст сстр тлнт ?

Автор: rsm 12.5.2011, 21:38
Цитата(borisbn @  12.5.2011,  19:34 Найти цитируемый пост)
крткст сстр тлнт?

smile smile

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

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

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

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

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

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

Автор: rsm 13.5.2011, 17:32
Цитата(borisbn @  13.5.2011,  10:38 Найти цитируемый пост)
если JavaScript будет касаться только GUI

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

Цитата
...предлагается сфокусироваться на переходе к модели, где C++ используется в основном для реализации модульного бэкэнда функциональности для Qt Quick

<...>

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

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

Цитата(Amp @  13.5.2011,  13:34 Найти цитируемый пост)
лучше бы Qt рипнулся от недостатка финансирования и остался в моей памяти все таким же"теплым и ламповым"

smile smile

Цитата(bsa @  13.5.2011,  14:00 Найти цитируемый пост)
JavaScript используется только в Qt Quick (QML). Не устраивает скорость? Используй Widget подсистему

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

Автор: bsa 13.5.2011, 17:52
Цитата(rsm @  13.5.2011,  17:32 Найти цитируемый пост)
Вопрос в том, насколько сложным станет до нее добраться... 

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

Автор: _GRIN_ 14.5.2011, 01:27
Друзья - у кого ещё навеяло воспоминания про дот нэт? =(

Автор: borisbn 14.5.2011, 10:23
Цитата(_GRIN_ @  14.5.2011,  01:27 Найти цитируемый пост)
Друзья - у кого ещё навеяло воспоминания про дот нэт?

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

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

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

Автор: borisbn 15.5.2011, 22:04
Цитата(Amp @  15.5.2011,  20:02 Найти цитируемый пост)
На мой взгляд у них жестких изменений не было.

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

Автор: volatile 15.5.2011, 23:22
Цитата(_GRIN_ @  14.5.2011,  01:27 Найти цитируемый пост)
Друзья - у кого ещё навеяло воспоминания про дот нэт? =( 

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

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

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

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

Автор: volatile 16.5.2011, 02:54
Цитата(borisbn @  15.5.2011,  23:59 Найти цитируемый пост)
бооооольшой опыт, как, например, у Вас, mes, boostcoder, bsa 

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

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

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

Автор: Amp 16.5.2011, 09:46
Цитата(borisbn @  15.5.2011,  22:04 Найти цитируемый пост)
MFC - COM - Active-X - WinForms - WPF - Silverlight (скорее всего чего-нить да забыл. добавьте, если вспомните, please)

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

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)