Comments 117
А Safe Renderer мне не видится такой уж сложной штукой, разве что проблема в ограниченности ресурсов. Думаю, очень быстро напишут стороннюю OpenSource реализацию и будет как всегда — две совершенно одинаковых, но не совместимых способа сделать одно и то же.
а родная не хотела дружить со свежими питонами — тоже сперва огорчился, но всё оказалось не так страшно
И это действительно так. Реализация очень простая, можно даже сказать примитивная.
Вся ценность в сертификации. Это очень сложно (и очень дорого) — сертифицировать ПО. Ваш продукт с самописным рендерером просто не пустят на рынок, потому что вы не соответствуете стандартам.
А Qt Safe Renderer прошёл сертификацию, и приобретая его вы на самом деле больше платите за сертификат, чем за техническое решение.
Ждем! А запуск любых приложений? QML часть или с С++ тоже?
И да. В QtQuick Controls 2 появится когда-нибудь TreeView?
А расскажите про поддержку Андроида и перспективы этой поддержки. Дело в том, что поддержка есть (я довёл пару программ до Google Play без особых приключений), но Google начал ставить палки в колёса и на данный момент собрать нормально работающее окружение для разработки на Qt под Android — задача мутная и есть основания считать, что дальше будет только хуже.
Если кто в курсе, то было бы интересно почитать…
Если я правильно понял, про что речь, то нельзя сказать, что Гугл намеренно вставляет палки, потому что они просто обновляют свой SDK, и проблемы сторонних индейцев их не сильно волнуют, у кого там что сломалось с новой версией API.
Ну и да, настроить окружение для разработки c Qt под Android это не всегда дело пяти минут. И хорошо бы в документации Qt этот процесс был рассмотрен более подробно (но опять же, невозможно предусмотреть, что Гугл изменит в следующий раз). А до тех пор будут писаться например такие манулы.
Например, BMW прикатили вот такой концепт-кар
Это немного не BMW
Есть задача как раз на эту тему, и там пилит лично Lars Knoll (CTO). Он говорит, что к релизу 5.12 (конец осени 2018) будет поддержка уже немалой части стандарта (но видимо ещё не всего полностью).
могу попытаться объяснить, зачем
время от времени на формумах рунета кто-нибудь да и спросит, как написать "сайт" на QML. Не хотят люди изучать еще JS+React/Angular+HTML+CSS.
Лично мне WASM нравится больше чем WebGL стриминг.
Стоимость подбирается под возможности покупателя или одна для всех?
Там есть ещё опция для стартапов (но только для Application Development) — такая же лицензия, но без тех.поддержки, зато дешевле.
Но вообще да, это стандартная цена для всех. Вот если у вас команда от 5 разработчиков, то начинается прогрессирующая скидка. Или если у вас есть чем заинтересовать (готовы к сотрудничеству на маркетинговой почве, например), то тоже можно получить более интересные условия. Можно также купить подписку на несколько лет вперёд — стоимость будет значительно ниже.
Там раньше были указаны цены, но сейчас зачем-то убрали. 100 долларов в месяц, если платить ежемесячно, и 80 долларов — если купить сразу на год.
На всякий случай уточню: те продукты/устройства/приложения, которые вы уже продали/распространили, пока была действующая лицензия, после её истечения конечно же в тыкву не превратятся, и ваши пользователи/клиенты вполне могут продолжать ими пользоваться. Ограничение касается только будущих поставок/продаж.
А так — да, я тоже с этим решением не согласен, но эффективный менеджмент его принял без меня.
Вспомнилось тут:
Ребята, что делают словарик yarxi (Смоленский Вадим и Всеволод Алексеев) объявляли краудфандинг на 1500$ чтобы embracedero RAD Studio купить и делать софтинку.
Их многие корили, почему Delphi, а не Qt. Во бы они сейчас попали на бабло…
Смоленский предвидел это!
Что то я никак не разберусь в разнице между GPL и LGPL.
изменённые и расширенные версии [copyleft] программы обязаны быть свободными [тоже быть copyleft].
Как уже ответили, есть же Open Source версия, за которую денег платить не надо. И насколько я вижу, конкретно это приложение вполне может использовать Qt под LGPL.
Переработка (new compiler pipeline) QML Engine;А что с лицензированием QML compiler? Окончательно передумали его открывать? Как я понимаю, разработка под iOS без Qt Quick Compiler не имеет смысла — всё будет тормозить и жрать батарею? На гитхабе есть нечто qmlrc, кто нибудь его пробовал, как оно? Как Ahead-of-Time/qmlcache соотносится с Qt Quick Compiler по производительности/энергоэффективности? Кажется очень соблазнительным разрабатывать GUI для C++ приложений под все побильные платформы разом с помощью Qt Quick, но терзают смутные сомненья. Не поделится ли кто подобным опытом?
Я несколько раз пытался разобраться в этом вопросе, но получал какую-то неполную и даже противоречивую информацию.
Сначала Qt Quick Compiler обещали отдать в Open Source с релизом Qt 5.8. Однако, там было сказано "...integrate the Qt Quick Compiler functionality".
В Qt 5.8 появился механизм кэширования QML, который, по заявлениям главы RnD, пришёл "на замену" Qt Quick Compiler и предоставляет сравнимый уровень улучшения производительности (времени загрузки приложения). И типа теперь Qt Quick Compiler "уберут".
Я не совсем уверен, что замена это полноценная, равно как и не понимаю зачем его "убирать". Постараюсь выяснить (тут как раз это понадобилось для одного проекта) и напишу о результатах в дополнении к статье.
Постараюсь выяснить и напишу о результатах
Выяснил и написал.
Как Ahead-of-Time/qmlcache соотносится с Qt Quick Compiler по производительности/энергоэффективности?
Производительность улучшилась (байт-код показал лучшие результаты по сравнению со сгенерированным C++), а насчёт энергоэффективности — как я понимаю, будет на том же уровне.
А что iOS? Вот вы скомпилили QML в вашем проекте новым QQC, закидываете приложение на iPhone, оно запускается без интерпретирования QML/JS уже сразу с «оптимизированным» байт-кодом — всё то же самое как и на любой другой платформе. Или я чего-то не знаю про iOS?
Ну тогда вот и ответ. Хотя, как я написал в дополнении про новый QQC и кэшинг, JIT там позволит получить дополнительную оптимизацию, то есть «голой» интерпретации уже и так не будет. Но так как я в этом не очень разбираюсь, может я сейчас какую-то чушь сказал. Подождём официальную статью, там вроде должен будет сам CTO высказаться.
клонированный камент
Очень не хватает Qt Lite (легковесной версии с минимум виджетов и прочего).
Тащить в небольшой проект 50+ МБ бинарников из за пары кнопок/менюшек как то не хочется.
Пресловутый Qt Lite как таковой "не существует", название это получило распространение только "благодаря" маркетингу.
Qt Lite — это новая система конфигурации Qt и уменьшение зависимостей между модулями, благодаря чему как раз таки и можно пересобрать Qt в легковесную сборку, в которой будут только те компоненты, которые вам нужны. Что, кстати, и позволило запуститься на микроконтроллерах с 7 метровым приложением, потребляющим 4 метра оперативки.
Qt Lite — это новая система конфигурации
Забавно.
Я не знал, что такой вариант существует и это название уже "занято")
Да, я-то отвечал думая что вы как раз о нём )
Ну, вкратце, примерно два года назад анонсировали исследование на тему более тонкой конфигурации сборки Qt, и в релизе 5.8 она появилась, но маркетинг немного неправильно её продвинул в массы.
Очень не хватает Qt Lite (легковесной версии с минимум виджетов и прочего).
допетерошные версии Qt вполне себе Qt-Lite
у вас должна быть хотя бы одна активная подписка, иначе нельзя ни вести разработку, ни продавать уже готовый продукт.
Жесть, теперь еще больше контор задумается, стоит ли переходить или начинать на Qt разработку.
Ну остается же Open Source версия под LGPL, которая покрывает большую часть задач…
Или все хуже и придется искать альтернативу?
Конечно остаётся. И я надеюсь, Qt никогда не откажется от своего лицензионного дуализма (будет доступен и под Open Source). Другое дело что большинство новых компонентов доступно только под GPL.
пренебрегли в пользу embedded/automotive
Зачем платить, когда можно пользоваться бесплатной версией? Вот и пришлось переориентировать бизнес.
На Unreal Engine делают игры класса AAA, где большие бюджеты большие, поэтому там работает.
где большие бюджеты большие
Зато GUI приложений делают на несколько порядков больше по количеству. Порог можно и в 100$/приложение/год установить.
Зато GUI приложений делают на несколько порядков больше по количеству.
А вы уверены в этом? Такие технологии как .NET, Electron вытесняют C++ как язык, для разработки GUI. При этом зачем платить, года я 7 лет обходился OpenSource решением?
Платить больше затем, что окупается. Также, как в случае с Unreal. Например за возможность пользоваться Qt Quick Compiler или Qt Charts можно было бы заплатить, если бы у них была прогрессивная цена лицензии (начиная с 0$). Правда пришлось бы допилить Qt Charts что бы он по всем направлениям превосходил QWT и другие аналоги, но если бы Qt Chart распространялся аналогично Unreal — комьюнити было бы более заинтересовано в его использовании и развитии. Наверняка и другие компоненты полезные есть.
Обходится то можно, но если есть возможность для более комфортной разработки по адекватной цене — зачем отказываться? Qt Charts — это пример порочного круга: ими не хотят пользоваться т.к. они не всегда подходят из-за политики лицензирования, а изучать разные варианты одного и того же только ради разных типов лицензирования тоже не хочется, в результате и в крупных коммерческих проектах Qt Charts тоже выглядят не слишком привлекательно — QWT уже знаком, зачем переучиваться.
невозможно перейти от lGPL проекта к commercial лицензии
Если вы про пункт в лицензионном соглашении, то случаи такого перехода были, но конечно больше в порядке исключения. Во всяком случае, это не невозможно.
выглядит так, будто направлением развития «библиотека для кросс-платформенного GUI» пренебрегли в пользу embedded/automotive
Тот же embedded может быть на Linux, на какой-нибудь RTOS, на Windows и так далее. Не говоря о том, что доля "простых" десктопных приложений по-прежнему составляет значительную часть прибыли от продажи лицензий, а там тоже Windows/Mac/Linux. По-моему, вполне кроссплатформенно.
мобильных
Ну вот тут да. Для мобильной разработки (если нужны только мобильные платформы, особенно если только одна), я лично взял бы что-то другое.
доля «простых» десктопных приложений по-прежнему составляет значительную часть прибыли от продажи лицензийНо для развития этого направления делается сравнительно мало. Всё по инерции. Кроме того сегодня мало Windows/Mac/Linux что бы считаться «кросс-платформенным». То, что web вариант развивают — это хорошо, но гладкого перехода на Android/iOS и даже просто между ними не хватает. Хотелось бы, что бы можно было значительную часть приложения портировать с десктопа на мобильные платформы, а поскольку поддержка мобильных платформ хромает, то это не очень выходит.
надеюсь, Qt никогда не откажется от своего лицензионного дуализма (будет доступен и под Open SourceНе уверен, что они могут убрать (L)GPL лицензии для «старых» компонентов, даже если бы захотели. Там есть код, авторские права на который не принадлежат исключительно Qt Company, его пришлось бы переписать, но тогда появится несовместимый форк (силами комманды KDE, полагаю), который оставит QtCompany за бортом.
Всё так, но я уже не раз слышал от продаванов "а зачем нам Open Source, без него же легче продавать". Если вот таких кадров постепенно окажется большинство, а тем более в менеджменте, то можно всякого ожидать.
без него же легче продаватьПочему? Они какие-то доказательства этому утверждению приводят? Потому что аргументы против привести легко, я уже приводил тут. Почему они считают, что без открытой версии они вообще смогут что-то кроме automotive продать? Мне кажется, за пределами automotive главным ассетом Qt Company является широкое комьюнити, которому можно продать дополнительные услуги. Потому что конкурентных преимуществ, за которые стоит платить, у Qt самого по себе уже почти не осталось — конкуренты настигают. Раньше из конкурентов был только wxWidgets, но теперь ситуация другая. Да и весь этот устаревший хлам из собственных контейнеров, потоков, moc, qmake и прочего больше не нужен, только мешает. Раньше это было преимуществом, но теперь — наоборот. Выходит что главная ценность — что люди знают, как пользоваться Qt. Но для людей с технологией уже практически не осталось стимулов в неё вникать. Перспективы не видно.
Ну тут надо понимать, что зачастую они до этого занимались продажей "обычного" софта, где всё просто: нет денег — нет стульев. А тут вдруг двойная лицензия, в которой можно использовать продукт "забесплатно". Через пару месяцев они конечно "въезжают" в специфику, и меньше задают таких вопросов, но поначалу бывает вот так.
а зачем нам Open Source, без него же легче продаватьМне кажется, ответ тут: «мы не продаём Qt-платформу, она нам не принадлежит, мы продаём дополнительные компоненты к ней и число проданных компонентов зависит от числа пользователей основной части. Если основная часть была бы платной (если бы это было возможно вообще) — она бы никому не нужна была и, следовательно, компоненты тоже». Как Android.
Продлять
1. Почему на сайте доступен только онлайн-инсталлятор? На канале в 100 МиБ установка загрузка компонентов идёт со скоростью 300-400 КиБ/сек. Кажется, offline-инсталлятор даже в большем объёме загрузился бы быстрее.
2. Зачем при установке Qt насильно ставить Qt Creator? А если он не нужен? Или, как в моём случае, использую новую версию Qt со старым Qt Creator?
3. С одной стороны есть план перехода на QBS, а с другой Qt Creator 4.6+ на большом QBS-проекте стал работать безумно медленно (на маке у меня вообще слайд-шоу), когда 4.4 работает вполне шустро.
Там при скачивании, чуть ниже download под стрелочкой ссылка
Почему на сайте доступен только онлайн-инсталлятор
Верно уже ответили, оффлайн тоже есть. Но вот кстати говоря Device Creation пакеты доступны только в онлайн установщике (оффлайновый бы весил ~50 ГБ, если не больше).
загрузка компонентов идёт со скоростью 300-400 КиБ/сек
Если вы про первый этап, где идёт загрузка мета-информации, то это известная проблема, в обозримом будущем должны оптимизировать. Если вы про загрузку уже самих компонентов, то это зависит от зеркала, к которому подключился установщик.
Зачем при установке Qt насильно ставить Qt Creator? А если он не нужен?
Тогда можно взять исходники из репозитория, и собрать только Qt :)
Но вообще "насильно" он ставится только в первый раз, а потом новая версия к вам попадёт только если вы пойдёте в Update components, а не в Add or remove components, насколько я помню.
на большом QBS-проекте стал работать безумно медленно (на маке у меня вообще слайд-шоу)
Я бы рекомендовал такое поведение зарепортить.
3. Можно, но это нужно собирать. А цель-то — скачать и программировать. На вопрос «зачем насильно» всё же не ответили :)
4. Ок, подумаю, как лучше сделать. Не присылать же весь qbs-проект :) Но всё-таки странно, т.к. не только у меня, но и у коллег, и не только на маке, но и на linux'е.
А как выбрать правильное зеркало?
Немного костыльно, но можно. Почему это не интегрировали в сам установщик — возможно, чтобы все не навалились на одно зеркало, а работало автоматическое распределение.
А цель-то — скачать и программировать
Ну так вот он и ставится из коробки :)
На вопрос «зачем насильно» всё же не ответили
Я спрошу у команды релизеров.
подумаю, как лучше сделать. Не присылать же весь qbs-проект
Будет уже хорошо если вы напишете что после обновления c 4.4 до 4.6 сборка с Qbs стала тормозить, причём независимо от платформы.
Я спрошу у команды релизеров
Я спросил.
В старых версиях Qt при установке на одном из шагов выполнялась их "проверка" и "регистрация" в Qt Creator (те самые "auto-detected"), и этот процесс был организован не самым лучшим образом, потому что наличие Qt Creator требовалось обязательно.
В новых версиях этой зависимости уже нет, но для обеспечения совместимости со старыми версиями Qt Creator по-прежнему нельзя исключить из списка устанавливаемых компонентов. Со временем старые версии "смоются" в историю, и тогда станет больше свободы действий.
Если вы очень хотите иметь возможность исключить Qt Creator из списка устанавливаемых компонентов уже сейчас, то вы можете оставить такой отзыв в багтрекере, и может это ускорит процесс.
Странное решение. В мире становится все больше кроссплатформенных фреймвлрков а они гайки прикручивают. Пилчт сук на котором сидят.
активно пытаются пролезть и сюдаНе очень, имхо. Реально необходимые вещи не делаются: нет активности в направлении улучшения native-like look, не переходят на Quick Compiler как основной инструмент работы с QML, а вместо этого пилят какие-то непонятно зачем нужные JIT и AOT, не переходят на контейнеры и механизмы стандартной библиотеки, а вместо этого поддерживают свои клоны, которые уже устарели. В направлении QtCore и всего что связано именно с кросс-платформенным GUI (в первую очередь X11/Win/Mac/Android/iOS, а не embedded) инновации забуксовали.
When you use this add-on, the application's startup time is significantly improved and you no longer need to deploy .qml files together with the application.
Пруф. При этом не исключается наличие JIT, для оптимизации. Сделано для такие систем как iOS, где нельзя сделать нормального JIT.
Читаем дальше:
The popular Just-in-time (JIT) compilation technique is used to generate machine code on the fly, which speeds up the execution of JavaScript and QML binding expressions.
Unfortunately this approach has some disadvantages: On application startup, several .qml files need to be parsed and dynamically compiled before the user interface can become visible and interactive.
Получается, что QML JIT — это недо Qt Quick Compiler.
Compiled Qt Quick is an elegant solution to these problems: .qml files as well as accompanying .js files can be translated into intermediate C++ source code. This entirely eliminates the need of deploying QML source code, it reduces the application startup time and allows for a much faster execution on platforms that do not permit Just-in-time compilation.На платформах с JIT разнецы может не быть, если повезет, но JIT не быстрее.
Они не говорят, что компилируют весь JavaScript. Они говорят про QML, который является языком разметки. Т.к. разметка достаточно формальна, то можно из
Button {
text: "Button"
}с генерировать создание объекта на стороне C++, а не через интерпретацию. Раньше Digia не рекомендовала писать бизнес логику на JS, т.к. это медленно, но с JIT это станет возможно.
Можно конечно пойти и спросить у CTO, но у меня такого впечатления нет. Насколько я вижу, qtbase — один из наиболее активных репозиториев.
Когда у меня из таргет-платформ только iOS, например, то не выбрал бы, и я так и написал в том комментарии.
Но ведь они поддерживаются, и разрабатывать под них можно. Вот скажем у меня какое-нибудь погодное приложение / текстовый редактор / туду-лист / дашборд какого-нибудь мониторинга, и у моих клиентов Windows, Mac OS, Android и iOS. Я беру Qt и пилю на все 4. Специфичная фигня типа телефонной книги мне не нужна, потому возможностей Qt вполне хватает. Кросплатформенно получилось? По-моему, да.
в свободном доступе
Если вы про Qt Configuration Tool, то в Open Source он вряд ли появится. Пока все ждут чтобы он хотя бы перестал быть "эксклюзивом" Device Creation.
отсутствия информации, что и когда можно отключить, особенно для linux, с его x11
Ну вот это как раз почему он коммерческий компонент.
"Не разбираешься в системе конфигурации? Плати денег и можешь просто щёлкать мышью по переключателям".
Звериный оскал капитализма.
Например, чтобы умные указатели можно было создавать аналогом std::make_unique или std::make_shared?
Не все могут использовать C++17 в своих проектах (некоторые не могут и C++11, и потому сидят на 5.6). И да, ряд вещей из std "продублирован" в Qt. Но я не понял, что именно вы хотите сапгрейдить.
А вообще, если мечтать, то в идеале хотелось бы (не в порядке важности):
- выкинуть qmake и qbs[1], перейти на современный cmake как основную платформу
- выкинуть контейнеры типа QVector, QThread и перейти на stl-аналоги
- выкинуть QVariant и перейти на std::any или может даже std::variant
- выкинуть QJson и сделать органичную поддержку RapidJson
- выкинуть Qt Test и сделать органичную поддержку Catch + адаптировать GUI часть Qt Test
- улучшить возможности для native-like look на всех платформах
- отказаться от повсеместного использования сырых указателей и перейти на unique/shared_ptr
- выкинуть moc (уже есть). Возможно, забить на совместимость и переработать внутренние механизмы так, что бы без moc макросы стали не такими стрёмными.
- Объединить и открыть Quick compiler и JIT
- Для того что распространяется по GPL добавить Ureal-engine-like опцию лицензирования (плати если начал зарабатывать)
- Продолжить развитие поддержки mobile платформ, что бы не было ограничений типа "если мне не нужна телефонная книга".
[1]: Теоретически qbs мог бы стать даже лучше cmake и вытеснить его, но судя по истории развития qbs, Qt Company не имеет подобных амбиций по отношению к qbs, а снова пилит свою собственную систему сборки без претензий на универсальность (в отличии от cmake), и то не успевает.
Но я не понял, что именно вы хотите сапгрейдить.
Например, хочу чтобы вместо кода
QSharedPointer<LongClassName> handler(new LongClassName());был код
auto handler= make_shared<LongClassName>());— без повторения названия класса и с выделением памяти для raw-указателя и reference counter'а в одной области памяти, одной операцией — с соответствующей выгодой в производительности.
Хочу, чтобы они стали moveable.
Не очень вникал, но вроде некоторые части std правильнее работают с многопоточным доступом, что тоже должно дать выгоду в производительности.
Ответ не сильно изменился, к сожалению. Над QQmlEngine/QJSEngine работа идёт (new compiler pipeline и прочая оптимизация), так что можно ожидать наконец-таки возможности отладки, но никаких конкретных сроков нет.
Пока можно проголосовать за реквест. Чем больше голосов, тем выше приоритет (который, кстати, уже выше обычного, потому что реквест поступил от коммерческого пользователя).
(триста тридцать пять)
Конечно будут поддерживаться, и удалять их планов нет. Но и нового функционала не ожидается — Qt Widgets считаются стабильными и завершёнными (всё-таки больше 20 лет разработки), дальше только поддержка. Такое бывает.
Если чего-то не хватает — создавайте реквест, и если будет много голосов за него, то может что и случится. Тем более что относительно недавно наняли целого продакт манагера для десктопного направления, правда он пока больше с PySide занят.
Насколько я знаю, там есть какие-то юридические проблемы с копированием/воспроизведением стиля iOS. Почему таких проблем не возникло у V-Play — не знаю. Я могу спросить у команды Qt Quick Controls, что там за история.
Насчёт покупки разработок V-Play — если не ошибаюсь, то V-Play купили у The Qt Company лицензию на создание собственного SDK, так что покупка "в обратную сторону" кажется маловероятной :)
В остальном — добавление новых стилей не входит в список первоочередных задач (как минимум TableView в этом списке стоит гораздо выше). Хотя я и согласен, что наличие стиля под Android и отсутствие стиля под iOS выглядит странно.
Я могу спросить у команды Qt Quick Controls, что там за история
Спросите, пожалуйста.
Спросил и добавил в статью.
Вариант же имитации native look потенциально не имеет таких ограничений — можно реализовать полный набор фич, в т.ч. допилить native feel аналоги компонентов недоступных на платформе, было бы достаточно разработчиков. Но вопрос одобрения со стороны Apple, конечно, остаётся открытым.
часть «feel» — вообще нереальна. То есть GUI может и будет выглядеть «родным», но первый же свайп / скролл / пинч выдадут «подделку».Неужели настолько сложно сделать имитацию, которая для, скажем, 95% пользователей будет неотличимой?
если мы будем выдавать наш стиль за «родной» стиль iOS, то Apple может сказать что-то неприятноеА зачем «выдавать», можно открыто говорить, что это имитация. Если внешне они будут почти одинаковыми по ощущениям — кому какое дело?
Неужели настолько сложно сделать имитацию, которая для, скажем, 95% пользователей будет неотличимой?
Я когда после Mac OS/iOS беру в руки ведро или сажусь за Шиндошс ПЦ — у меня появляется ощущение, что продукция Apple ещё очень дёшево стоит, и они могли бы и в пять раз больше просить. Сложно даже начать представлять объём труда, вложенный в UX, и каких размеров команда занималась этим на протяжение стольких лет. Повторить их результат в несколько раз меньшей командой будет очень сложно и займёт очень много времени, даже имея оригинал для копирования.
Это такое моё мнение. Команда QQC просто сказала: "...to imitate the "feel" is even harder".
Повторить их результат в несколько раз меньшей командой будет очень сложно и займёт очень много времени, даже имея оригинал для копирования.Но, всё же, далеко не так сложно как его разработать с 0, так что команда как у Apple не понадобится. Да и не уверен я, что команда, которая занималась контроллами для iOS настолько уж большая.
На счёт Anroid/iOS я даже имея бесплатный (рабочий) iPhone не сделал бы выбор в пользу iOS — каждый раз раздражаюсь, если приходится брать в руки iPhone. До 2012 года качество исполнения iOS действительно было выше чем Android, но сегодня этого уже нельзя однозначно утверждать. С MacOS то же самое, никаких преимуществ даже над KDE Neon в UX я не вижу, а вот кучу нестандартных решений, где на то нет необходимости кроме «что бы отличаться» — вижу, и это раздражает. А по цене они и так на 30-50% больше просят чем Samsung и Google, если станут просить ещё больше — продажи наверняка в разы сократятся. Они и так уже вынуждены сокращать маржу, в этом году Samsung догнал Apple по доле полученной прибыли (не дохода).
По результатам голосования за статью о Qt на микроконтроллерах с большим отрывом лидирует вариант за публикацию, так что автор (Trilla) вчера её туда отправил, однако сегодня ему пришёл ответ от НЛО:
Публикации рекламного характера вне корпоративного блога и хаба «Я пиарюсь» запрещены правилами сайта. Пожалуйста, удалите из вашей публикации все элементы рекламы
Ну, значит не будет статьи.
Новости Qt, июнь 2017 — май 2018