Комментарии 16
Представим на минуту, что существует простая технология, позволяющая писать мобильные приложения под все платформы сразу. Без проблем с производительностью, с легким доступом к железу на низком уровне. Бесплатно*. Приложения выглядят почти как родные.
Вот! Именно в этом почти вся заковыка. Потому-то Qt-based приложения и не смогут конкурировать с нативными. Жаль конечно, но это реальность (о которую мне в своё время пришлось больно удариться)… При всём моём уважении к Digia…
Сейчас, когда основные платформы по сути отказались от дизайна, смешаться с ними стало гораздо проще, по крайней мере попробовать стоит.
Как показывает практика, дело не столько в самом дизайне элементов управления, сколько в их поведении. Нужно делать анимацию, скорость отклика, тип взаимодействия с элементом таким, каким его привыкли видеть на каждой конкретной платформе.
Нужно делать анимацию, скорость отклика, тип взаимодействия с элементом таким, каким его привыкли видеть на каждой конкретной платформе.
И именно в этом состоит основная сложность. Едва ли Qt предоставит такую унифицированность для всех поддерживаемых ею платформ… Впрочем, я сужу по десктопной разработке.
Возможно, вы правы.
На desktop-е же получается и довольно успешно. Чем оно должно отличаться от мобильных? Все для этого есть, только вот некому заниматься всем этим. Людей не хватает.
На desktop-е же получается и довольно успешно.
Я был бы рад согласиться с вами, но мой опыт показывает обратное. В частности, на Mac OS X Lion (и старше) у меня не получилось создать Qt-приложение, которое выглядело бы как родное Cocoa-приложение. Вернее, как бы получилось, но, во-первых, оно было наводнено Objective-C-вставками, а во-вторых, некоторые элементы всё равно остались чуток «неродными».
Я уже не говорю о том, что Qt-приложение запускалось и работало ощутимо медленнее родного…
А можно чуть подробнее, какие элементы, какая версия библиотеки, для чего использовалась куча вставок?
Можно, но это будет оффтопом, поскольку мы выйдем за рамки данной статьи. Поэтому просто поверьте мне на слово. Когда-то я не согласился с двумя пользователями на Stackoverflow, объяснившими проигрышность Qt-приложений на Mac OS X. И это несогласие стоило мне 8 месяцев работы, в итоге выброшенных в корзину…
Впрочем, если не верите на слово — можно в личной переписке. Объясню всё подробно.
Впрочем, если не верите на слово — можно в личной переписке. Объясню всё подробно.
Как угодно, но кроме веры на слово у меня тоже есть опыт такой разработки, который мне кажется вполне успешным.
Выглядит вполне убедительно!
Я тоже не соглашусь с предыдущим оратором насчет медлительности Qt'a. Быстрый он, как ни крути.
Я тоже не соглашусь с предыдущим оратором насчет медлительности Qt'a. Быстрый он, как ни крути.
Быстрый он, как ни крути.
Возможно, это справедливо для самых последних версий Qt. А вот на примере Qt 5.0.1 я убедился: родное Cocoa-приложение запускалось примерно в 4 раза быстрее. К тому же работа некоторых виджетов (в частности, QTextEdit) происходила с визуальной задержкой (да, с небольшой, но всё же), а вот на родном Cocoa-приложении работа аналогичного виджета была просто мгновенна.
Поймите, я не ругаю Qt. Digia делает прекрасную работу. Однако если говорить именно о Mac (Linux и Windows — это отдельный разговор), то родное Cocoa-приложение всегда будет в выигрыше. Опять-таки, для будущих версий Qt это утверждение может быть и потеряет свою актуальность, но на данный момент это так.
Было бы интересным сравнить с другими кросс платформенными тулкитами, скажем, с python kivy.
И еще вопрос: стоит ли распыляться на все платформы сразу, когда рынок фактически поделен между android, ios и догоняющей win? Все-таки правило 80/20 работает…
И еще вопрос: стоит ли распыляться на все платформы сразу, когда рынок фактически поделен между android, ios и догоняющей win? Все-таки правило 80/20 работает…
На Python я не пишу, но вот этот ответ выглядит достаточно полным. Фреймворков много, из известных кроссплатформенных еще можно вспомнить Mono Touch, однако набор платформ, стоимость лицензии, нативность интерфейса, скорость работы у всех разная, нужно поработать со всеми, чтоб можно было сравнивать. Qt наш основной инструмент, потому и остановились на Qt Quick.
Хвататься за все платформы сразу, конечно, не стоит, начнем с Android. С другой стороны, если кому-то интересно писать именно под Windows Phone — почему нет, многопоточность рулит!
С документацией не все так плохо, да и перенос с QtQuick 1.0 в основном заключается в смене версии в каждом файле (хотя бывают и более интересные вещи, например баги с хранением массивов в variant). А компонентов и правда нет =\
В свое время, когда только узнал про QML, я думал, что люди будут создавать компоненты, делиться ими, библиотечки свои создавать. Но таких практически нету. И это грустновато.
Можно не городить велосипедов, а постараться улучшить QtQuick Controls — пока они не особо юзабельны.
В свое время, когда только узнал про QML, я думал, что люди будут создавать компоненты, делиться ими, библиотечки свои создавать. Но таких практически нету. И это грустновато.
Можно не городить велосипедов, а постараться улучшить QtQuick Controls — пока они не особо юзабельны.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мобильное приложение на Qt Quick: возможности и перспективы