А ещё clip работает только по прямоугольным границам Item и вызывает перерисовку через дополнительный фрейм-буфер. Короче, не взлетит. Что предполагал автор комментария — останется тайной.
Поинтересуйтесь у владельцев (в основном, бывших) Galaxy Nexus, как Google их лихо кинул с обновлением до KitKat ровно через 2 года после выхода устройства. Или у владельцев Nexus 7 2012 на тему того, когда у них будет Lollipop (правильный ответ — никогда)
Теоретически возможно. На практике контроллеры зачастую могут не поддерживать необходимые элементы оформления для того, чтобы нарисовать «какой хочется» виджет и обеспечить полностью правильный look-and-feel.
За примером далеко ходить не надо — при попытке реализовать стиль элементов в духе этого же самого Material Design, мы натыкаемся на то, что не можем реализовать эффект ripple, так как стилю тупо не передаются события мыши/тач-панели и их координаты. И мы обламываемся, пытаясь начать с самого что ни на есть банального ButtonStyle.
Нет, исключительно для статьи на Хабре я бы этот компонент точно писать не стал — мне лениво :)
На самом деле, я сейчас в свободное время разрабатываю Android-приложение на C++/QML и пытаюсь сделать максимально нативный интерфейс. Плюс некоторые компоненты используются в проектах, создаваемых по работе. Сейчас у нас накопился целый набор визуальных компонентов на QML в стиле Material Design, но он сыроват, да и сделан в рабочее время. Если удастся договориться с руководством, выложим на Github под какой-нибудь свободной лицензией.
Это не совсем так — мы не можем жёстко задать соотношение сторон родительского элемента. Соответственно, нам либо придётся опираться только на один линейный размер (например, ширину, что не очень красиво), либо выбирать наименьший из линейных размеров (что некрасиво, неудобно и создаст довольно сложные байндинги для каждого из свойств). Короче, именно в конкретном случае получится ненужное усложнение на ровном месте.
Размеры контейнера жёстко задаются в соответствии с гайдлайном. Конкретно в его случае будет более правильным для корректного масштабирования просто умножать все хардкодные значения на размер dp на данном устройстве (3 для xxhdpi и так далее).
Вообще, тема масштабирования QML-интерфейсов — это большая и отдельная история ещё как минимум на несколько постов. В случае с Android-приложениями и строгим следованием guidelines в целом более выгодной стратегией с моей точки зрения является как раз таки использование коэффициента масштабирования для всех элементов интерфейса. Благо, на Android это делается очень просто, если будет интересно, могу написать отдельный пост о том, как именно.
Да ничего особенного не произойдёт. Интерпретатор QML проследит, чтобы Item перешёл в то состояние, которое было последним, и все его свойства установились соответствующим образом. В случае с данным переходом, вращение иконки будет завершено, а вот анимация верхнего и нижнего прямоугольников в «бутерброде» не будет завершена и они просто направятся обратно в исходное положение. Я попробовал (предварительно уменьшив скорость анимации), выглядит вполне прилично.
А ещё можно у каждого из экземпляров Animation установить свойство alwaysRunToEnd в true, тогда анимация свойства будет всегда завершаться полностью перед началом следующей анимации. Но в данном случае это не имеет смысла.
Один пример уже привели в комментарии выше. Кстати, хотел написать сразу в посте, но решил не засорять его лишней информацией — этим примером Google слегка нарушает собственные гайдлайны. Если судить по ним, боковая панель в приложениях с Material Design (в отличие от Holo) должна перекрывать и AppBar с иконкой, и даже заходить на область статусной строки (это поддерживается в Android 5.0).
Второй пример — сделать переход вглубь стека приложения без замены AppBar, только с заполнением области данных приложения новым контентом. Пример есть в том же руководстве по Material Design (см. третье видео).
Ну, следующий логичный этап — сделать приложения для смарт-часов (Apple Watch, Android Wear в первую очередь), которые бы при приближении к iBeacon-маячку, запущенному на iPad, выводили бы на экран часов QR-код билета.
Целевая аудитория маленькая, но стремительно растущая, плюс достаточно социально активная. Да и с рекламной точки зрения было бы красиво.
Мне кажется, что при упавшей корневой ФС запуск ядра и shell будет наименьшей из моих проблем :) Опять же, LiveCD и прочие сторонние источники загрузки всегда есть под рукой, так что решаемая таким образом задача видится мне довольно надуманной.
А объясните пожалуйста, в чем принципиальный смысл отдельного раздела под /boot? Для /home и прочих /media понимаю и сам пользуюсь (корень на SSD), но к чему отделять на десктопе /boot от корня — так и не уловил.
К слову, тот же CMake (через инструментарий CPack) точно умеет делать при сборке продукта DEB, RPM и инсталляторы под Windows на основе NSIS. Про Mac OS X не скажу, надеюсь, прокомментирует кто-нибудь знакомый со сборкой CMake под OS X на практике.
DEB и RPM мы долгое время делали именно штатными средствами CMake, так что (при отсутствии высоких требований к дополнительным функциям пакетного менеджера) вполне могу советовать ознакомиться.
Если мы сами задаём пути для установки приложения и библиотек, задачу можно тривиально решить аж двумя путями:
Java-way. Вместо запуска исполняемого файла прописываем ярлык на написанный и установленный нами скрипт, прописывающий LD_LIBRARY_PATH перед запуском.
Unix-way. Специально для решения этой проблемы есть такая волшебная штука, как RPath. Хорошая, годная поддержка сборки с RPath из коробки есть, например, в CMake (искать по слову «rpath»).
Если запилят — хорошо, давно не хватало, в первую очередь, как пользователю, использующему Windows только и исключительно на домашнем ПК.
За примером далеко ходить не надо — при попытке реализовать стиль элементов в духе этого же самого Material Design, мы натыкаемся на то, что не можем реализовать эффект ripple, так как стилю тупо не передаются события мыши/тач-панели и их координаты. И мы обламываемся, пытаясь начать с самого что ни на есть банального ButtonStyle.
На самом деле, я сейчас в свободное время разрабатываю Android-приложение на C++/QML и пытаюсь сделать максимально нативный интерфейс. Плюс некоторые компоненты используются в проектах, создаваемых по работе. Сейчас у нас накопился целый набор визуальных компонентов на QML в стиле Material Design, но он сыроват, да и сделан в рабочее время. Если удастся договориться с руководством, выложим на Github под какой-нибудь свободной лицензией.
Вообще, тема масштабирования QML-интерфейсов — это большая и отдельная история ещё как минимум на несколько постов. В случае с Android-приложениями и строгим следованием guidelines в целом более выгодной стратегией с моей точки зрения является как раз таки использование коэффициента масштабирования для всех элементов интерфейса. Благо, на Android это делается очень просто, если будет интересно, могу написать отдельный пост о том, как именно.
Если эта тема интересует, рекомендую ознакомиться с серией постов о масштабировании интерфейсов от Nuno Pinheiro, создателя темы Oxygen из KDE и сотрудника KDAB.
А ещё можно у каждого из экземпляров Animation установить свойство alwaysRunToEnd в true, тогда анимация свойства будет всегда завершаться полностью перед началом следующей анимации. Но в данном случае это не имеет смысла.
Второй пример — сделать переход вглубь стека приложения без замены AppBar, только с заполнением области данных приложения новым контентом. Пример есть в том же руководстве по Material Design (см. третье видео).
Целевая аудитория маленькая, но стремительно растущая, плюс достаточно социально активная. Да и с рекламной точки зрения было бы красиво.
У меня в Logitech M705 пара комплектных Duracell про работала почти ежедневно 3,5 года без каких-либо видимых проблем.
DEB и RPM мы долгое время делали именно штатными средствами CMake, так что (при отсутствии высоких требований к дополнительным функциям пакетного менеджера) вполне могу советовать ознакомиться.