Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > С/С++: Кроссплатформенное программирование, 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 - пускай остаётся для винды. Это моё личное ИМХО. Я, ессно, не настаиваю ![]() |
Автор: 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 |
Так и используйте 4.x. Вам что, кто-то запрещает? |
Автор: bsa 12.5.2011, 12:21 | ||
У них мотивация следующая: на данный момент разница в цене между SoC с ускорителем и без стремится к нулю, а количество без GPU тоже уменьшается. Таким образом, в ближайшем будущем не останется устройств без аппаратного ускорения графики. А даже если это случится, есть альтернатива, которой занимается сообщество. |
Автор: rsm 12.5.2011, 17:31 | ||
Qt 5 -> R.I.P. ![]() |
Автор: borisbn 12.5.2011, 17:34 |
rsm, крткст сстр тлнт ? |
Автор: rsm 12.5.2011, 21:38 |
![]() ![]() ИМХО, 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 рипнулся от недостатка финансирования и остался в моей памяти все таким же"теплым и ламповым" фреймворком ![]() |
Автор: 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 | ||||||
Меня вот это напрягает:
Первое предложение подразумевает возведение больших и страшных мостов C++ -> JavaScript, второе - еще более больших и страшных мостов JavaScript -> C++.
![]() ![]()
Вопрос в том, насколько сложным станет до нее добраться... |
Автор: bsa 13.5.2011, 17:52 |
так же как и сейчас - просто подключить подходящую библиотеку. |
Автор: _GRIN_ 14.5.2011, 01:27 |
Друзья - у кого ещё навеяло воспоминания про дот нэт? =( |
Автор: borisbn 14.5.2011, 10:23 |
честно говоря - нет. У M$ вроде не предвидется таких глобальных изменений, как у Nokia, поэтому обсуждать будет ли он жить или нет IMHO нет смысла... ааааа... м.б. у тебя ассоциация с тем, как крупная компания делает жёсткие изменения в framework'е не особо спрашивая мнения разработчиков ? Тогда да. Похоже. P.S. ![]() ![]() ![]() |
Автор: Amp 15.5.2011, 20:02 |
На мой взгляд у них жестких изменений не было. Просто прикрутили дополнительную библиотеку для декларативного и аппаратно ускоренного UI (WPF) и положили болт на поддержку старой (WinForms). |
Автор: borisbn 15.5.2011, 22:04 |
MFC - COM - Active-X - WinForms - WPF - Silverlight (скорее всего чего-нить да забыл. добавьте, если вспомните, please) плюс этот hell с .Net - одна версия несовместима с другой... IMHO у Qt-шников как-то менее революционно всё происходило |
Автор: volatile 15.5.2011, 23:22 |
Ассоциация в том, что отходят от С++ и там и там. Те с шарпом носятся как курица с яйцом, эти похоже с жавой скриптом хотят "носиться" ![]() Что так си всем неугодил? (предвижу восторженные возгласы 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 | ||
Спасибо за комплимент, но ставить меня в один ряд с такими ассами пока не стоит.
Примерно такими-же фразами распрощались когда-то с асмом. Похоже С/С++ ждет та-же участь? Вобще тенденция настораживает (не с Qt, а вообще в программировании). Приложения становятся большими, неповоротливыми. Такое впечатление, что уже и ОС пишут на чём-то а'ля бейсик. (Виста похоже на 80% на нем написана, после почти провала висты, семерку немного переписали на менее продвинутом языке, чуть побыстрее стала.). Наверное это правильно. Писать программы так быстрее. А юзеры пусть потом тормозят на четырех-ядерных пнях и выкладывают бабки за гигагагерцы (и произодители харда, тут без работы не останутся). Система... Против нее не попрешь. Но, честно говоря, немного жаль. |
Автор: Amp 16.5.2011, 09:46 | ||
Мы ж рассматриваем изменения в контексте самого фреймворка .NET. MFC - плюсовая технология. COM с Active-X вообще как-то странно ставить в один ряд с библиотеками для построения графического интерфейса. Моя мысль была следующая - они (майкрософт) не заменяли одну библиотеку на другую и не реструктуризировали классы фреймворка. Появлялись дополнительные инструменты и никто (кроме их маркетинга) не заставлял отказываться от старых. В случае же с Qt я встречаю фразы вида "оставить для совместимости", "вынести в отдельную библиотеку", "уйти от этого подхода в будущем". Это несколько настораживает. Надеюсь на лучшее ![]() |