Завтра этот блог перестанет существовать, потому напоследок хотелось бы рассказать историю создания нашего органайзера для студентов и поделиться планами на будущее.
Все началось весной 2013 года, когда мы с Raymondo решили наконец автоматизировать учет сроков выполнения заданий, потому как перед сессией появлялась реальная проблема: как собрать все оставшиеся задания в кучу и распределить время их выполнения с учетом приоритетов.
В процессе написания мобильной версии органайзера на QML у меня появился вопрос: можно ли построить такую непротиворечивую модель навигации, которая могла бы с минимальными изменениями подстраиваться под обе основные платформы. То есть которая соответствовала бы HIG, была привычна пользователям, и не вызывала отторжения, чем страдают многие кроссплатформенные программы. Был произведен анализ основных приемов организации экранов на обоих платформах, на основании чего появилась модель, которой хочу поделиться.
Многие разработчики хотят выпускать свои приложения под несколько платформ. Если вы планируете адаптировать программу под Android, нужно учитывать, что разные платформы придерживаются разных правил оформления и поведения. Визуальные решения, идеально вписывающиеся в окружение одной ОС, могут выглядеть чужеродными на другой. Несомненно, подход «один дизайн — много платформ» может сэкономить приличное количество времени, но при этом нужно понимать, что приложение наверняка получится чужеродным, что может оттолкнуть пользователей. Следующие приемы помогут вам избежать наиболее частых ловушек и подводных камней.
Представим на минуту, что существует простая технология, позволяющая писать мобильные приложения под все платформы сразу. Без проблем с производительностью, с легким доступом к железу на низком уровне. Бесплатно*. Приложения выглядят почти как родные. Ведут себя как родные. Просто мечта, а не технология! «Так не бывает» — скажете вы. И будете правы. Почти. Но у сообщества есть отличный шанс изменить ситуацию, благо все предпосылки для этого есть. Если интересно, что уже сделано, и что еще предстоит — прошу под кат.
* Печалит только юридическая неопределенность при статической линковке (LGPL), обязательной, например, под iOS
Сборка дистрибутива — завершающий этап подготовки программы к выходу в свет. К сожалению, ни о какой стандартизации в этой области речи не идет, более того, на некоторых ОС (не будем показывать пальцем), так вообще целый зоопарк форматов.
Итак, в идеале нам нужны дистрибутивы:
После завершения разработки под OS X может остаться ощущение незавершенности — для полного счастья хотелось бы видеть свое приложение в каталоге, тем более, что это, пожалуй, лучшая площадка для продажи десктопных приложений. На эту тему есть статья времен Qt 4.8 в официальном блоге, и еще более старая на хабре. К счастью, больше нет необходимости пересобирать Qt, однако с приходом OS X 10.9 некоторые баги стали критичными, приходится выкручиваться.
Сегодня я хотел бы рассмотреть вопрос кастомизации интерфейса программ на Qt. Основным вариантом является использование Qt Style Sheets. Как становится очевидно из названия, это немного специфичный аналог привычных всем каскадных таблиц стилей (CSS2), без которых немыслим современный интернет. QSS чаще всего применяются для двух вещей: либо доточить какой-нибудь виджет до более родного вида, либо наоборот, сделать интерфейс более нарядным, выделяющимся, возможно одинаковым на всех платформах.
На скриншоте приведен один из диалогов нашего органайзера для студентов, весь интерфейс которого реализован на QSS.
После сотен отладочных запусков стандартная иконка наверняка успела надоесть, потому и начнем с установки новой. По этому поводу написана отдельная статься в документации, однако все оказалось немного сложнее. Каждой платформе потребовался свой подход, одной строкой проблему не решить.
Для начала следует подготовить исходники в разных разрешениях (Windows, OS X, Linux), которые мы будем запекать в файл иконки. Необходимо добавить, что разрешения для OS X в таблице ниже условны, и в идеале иконки одинакового размера должны быть разной степени детализации, для обычных и Retina-дисплеев.
Qt — по-настоящему замечательная библиотека, позволяющая перенести программу на другую операционную систему простой перекомпиляцией. И если разработчик не использовал чего-нибудь ОС-специфичного, она таки будет выглядеть и работать почти как родная. После разработки основного функционала, при которой различия минимальны, наступает стадия полировки и доводки — об этом и будет рассказывать настоящий цикл статей.
Многие разработчики хотят выпускать свои приложения под несколько платформ. Если вы планируете адаптировать программу под Android, нужно учитывать, что разные платформы придерживаются разных правил оформления и поведения. Визуальные решения, идеально вписывающиеся в окружение одной ОС, могут выглядеть чужеродными на другой. Несомненно, подход «один дизайн — много платформ» может сэкономить приличное количество времени, но при этом нужно понимать, что приложение наверняка получится чужеродным, что может оттолкнуть пользователей. Следующие приемы помогут вам избежать наиболее частых ловушек и подводных камней. 
Представим на минуту, что существует простая технология, позволяющая писать мобильные приложения под все платформы сразу. Без проблем с производительностью, с легким доступом к железу на низком уровне. Бесплатно*. Приложения выглядят почти как родные. Ведут себя как родные. Просто мечта, а не технология! «Так не бывает» — скажете вы. И будете правы. Почти. Но у сообщества есть отличный шанс изменить ситуацию, благо все предпосылки для этого есть. Если интересно, что уже сделано, и что еще предстоит — прошу под кат. 
После завершения разработки под OS X может остаться ощущение незавершенности — для полного счастья хотелось бы видеть свое приложение в каталоге, тем более, что это, пожалуй, лучшая площадка для продажи десктопных приложений. На эту тему есть 
