Представляю доказательства возможности портировать Qt Lighthouse на iOS (UIKit)

http://labs.qt.nokia.com/2011/03/11/new-proof-of-concept-uikit-based-lighthouse-platform/
  • Перевод
Я закончил реализацию тестового порта Lighthouse плагина, котрый работает «поверх» UIKit (исходный код доступен в репозиротии qt-lighthouse на гиториоусе). Пока не настолько впечатляющий, как порт под Android (но может быть немножечко более впечатляюще, чем порт под новую пратформу INTEGRITY, по крайней мере для меня).
image

А это значит, что если вы внимательно выполните все инструкции в прилагающемся README файле (который можно найти в ветке src/plugins/platforms/uikit/ репозитория qt-lighthouse), то сможете собрать (частично) Qt для iOS (как для симулятора, так и для устройств), а также запустить пару Qt Quick приложений из стандартных примеров. Обращаю ваше внимание, что это не настоящий порт на iOS и не имеет ни какой официальной поддержки или официального статуса. Существует огромная вероятность, что многие части Qt API не работают, даже те, которые успешно собрались (не говоря уже о тех, которые не удалось собрать).
В общем, цель данного R&D проекта заключалась в том, чтоб запустить парочку QML приложений на айфоне для проверки потенциальной возможности этой затеи вообще. Ну и конечно, чтоб показать насколько QML технология крута.

Сборка и линковка Qt

Это была самая утомительная часть, которая вначале сильно разочаровала. Я столкнулся с огромным количеством проблем, начиная с ошибок компилятора, связанных с тем, что некторые инструкции были недоступны, заканчивая тем, что значения функций и переменных внезапно менялись или обнулялись в рантайме. В итоге я обнаружил, что базовый mkspec (файл настроек сборки Qt) для gcc под мак содержал в себе специфичные для настольной версии Мак ОС значения окружения. Естественно это и взрывало мозг тулчайну от iOS. После этого я подправил переменные окружения в mkspec на более или менее правильные. И благодаря тому, что iOS по сути своей — это POSIX платформ, практически все сразу заработало.

Плагин для платформы Qt Lighthouse

Я выбрал самый легкий путь, и сделал так-же, как и в плагине для Cocoa: блитил backstore QImage на UIView (точнее на CALayer). Явно, это не самое оптимальное решение (и заметно не вооруженным глазом, если запустить QML flickr demo), но решение вполне соответсвует понятию «R&D проект». Хотя все-же была парочка проблем. Например, во время интеграции обработчика очереди событий (QEventLoop), система убивала iOS приложение, если во время обработки события управление не передавалось главному циклу приложения в определенные временные рамки.
Хорошим решением для отрисовки, было бы использовать OpenGL поверхность в качестве backstore в Qt. Тогда вся отрисовка бы происходила в эту поверхность. А в UIKit представить эту поверхность как буфер для CALayer соотвествующего UIView. Таким образом бы получился бы общий видеобуфер, в который бы Qt рисовал, а UIKit iOS подсистема бы воспринимала как «свой родной» и отрсиовывала его со всей своей иерархией, не особо разбираясь как туда и чего попало.

Результат

Lighthouse способен работать на iOS (как минимум после небольших патчей) и QML очень крутая технология :-). Ну и стоить подметить, что для Lighthouse — это полезный плагин, ну и плюс как минимум очень поучительный опыт.

Вот парочка видео-демо:

Qt Mobility на iOS — акселерометр используется для эмуляции глубины пространства:

QML интерфейс:

QGraphicScene


Очень хотелось бы, чтоб какая-нибудь коммерческая организация бы взялась за релизацию этого порта и представила миру (пусть даже за деньги) Lighthouse плагин, позволяющий писать коммерческие решения для iOS на Qt. Это бы в очередной раз подтвердило и укрепило слоган :«code less, create more and deploy everywhere».
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 60
  • НЛО прилетело и опубликовало эту надпись здесь
    • +4
      Я не очень знаком с BADA, но там Linux и C++ — этого достаточно :-)
      Основная проблема — не портировать. Основная проблема — поддержка. Делать комерческий продукт на коммунити поддерживаемом продукте — не айс.
      Да тоже обрадовало, что кто-то решился взятся за порт.
      Когда-то давно я пытался портировать QtEmbedded с QWS под мак, но там были посложнее проблеммы (в частности QVFB был жестко завязан на X11). Просто хотел отлаживать QWS приложения под маком.
      Но Lighthouse более правильное решени — абстагироваться от оконных систем вообще и от QWS в частности.

      Каждая новая версия Qt несет в себе огромное колиество вкусностей.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Вы, наверное, хотели сказать «лестных отзывов»? Хотя, если речь о троллях, то отзывы могут действительно быть от остальных жителей леса :)))
        • +1
          Стесняюсь спросить, а почему вдруг не айс?
          МойСиквел? Не говоря о RH, который поддерживается как раз комьюнити. Нужна просто служба «ответов на звонки» сбоку. И это случится, я уверен.
          • +3
            MySQL? RH=RedHat? Вы что-то путаете, там некислый бизнес вокруг крутится.

            PostgreSQL — вот это коммьюнити.
          • 0
            >Основная проблема — не портировать. Основная проблема — поддержка. Делать комерческий продукт на коммунити поддерживаемом продукте — не айс.

            Ну ежели коммьюнити набъет cydia кучей Qt софта, то дело по любому быстрее пойдет. Тем более всё равно для того, чтобы прогу на Qt в appstore приняли придется покупать коммерческую лицензию на Qt.
            • 0
              зачем покупать коммерческую лицензию для аппстора? Обоснуйте.

              По поводу cydia — на нем серьезные бизнес-проекты не ориентиованы.
              • 0
                >зачем покупать коммерческую лицензию для аппстора? Обоснуйте.

                Вроде как там проблемы с софтом под GPL, или на LGPL это не распространяется?

                >По поводу cydia — на нем серьезные бизнес-проекты не ориентиованы.

                Да хотя-бы массовый софт начали делать, тоже двигатель прогресса
            • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Good job!
            • 0
              Интересно, а какое тогда отношение этот порт к этому имеет?
              www.qt-iphone.com/Introduction.html
              • 0
                Никакого.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Видюхи я так понял с него как раз
                • 0
                  Интересно, а примут созданное решение в App Store?
                  • 0
                    для qt есть варианты коммерческого лицензирования. если конечный продукт будет под пропиетартной лицензией (а не под lgpl/gpl), то проблем быть не должно.
                    • +1
                      lgpl разрешает исползовать Qt с коммерческим продуктом. Так что LGPL очень даже подходит.
                      • 0
                        С коммерческим разрешает, а вот с проприентарным — только при условии динамической линковки. Так что для AppStore нужно будет либо полностью открыть свой код, либо покупать коммерческую лицензию.
                        • +2
                          устал уже спорить с этим мифом. Про динамическу и статическую линковку нигде в lgpl не сказано. Это уже додумки и по lgpl никто не запрещает статически линковаться.
                          Более того, динамическая линковка как таковой по сути не является, часть кода даже при динамической линковке линкуется статически (как минимум хедеры).

                          Там есть дин пункт (вроде 6a), который трактуется некоторыми как статическая линковка, но это не так.
                          Даже Qt у себя официально писали, что вопрос не однозначный и они рекомендуют (не запрещают) для подстраховки линковаться динамически. Но это рекомендация, а не запрет.
                          • 0
                            Верно, слов «динамическая» и «статическая» линковка в тексте лицензии нет. Но должна быть возможность слинковатся с более новой версией библиотеки. Варианты решения — открытие исходного кода, динамическая линоковка, .obj-файлы с свбодном доступе
                            • 0
                              это тоже не однозначно. Так как линквка может быть и на стадии сборки, этого никто явно не запрещает.
                              С другой стороны, если нужно избежать статической линковки, но при этом без нее нельзя, то есть несколько вариантов решения. Самый простой — это пишется неки wrapper (API proxy) с которым статически линкуется LGPL билбиотека. Исходный код этого враппера свободно выкладывается в свободный доступ, а само комерческое приложение линкуется динамически с этим враппером.
                              Так-же обходят и GPL. Только вместо врапперов используют отдельные приложения, взаимодействие с котоыми происходит любым доступным IPC методом (пайпа, сокеты, файлы ...)

                              • 0
                                Одного не пойму, что мешает слинковаться с Qt динамически и положить Qt либы рядом с бинарником кроме того, что весить это кучу будет? Но в application bundle так и делают все макоразрабы.
                                • 0
                                  в iOS принято линковаться статически. Динамическая линковка только с системными общими библиотеками. Разработка под iOS в многом отличатеся от Mac OS.
                                  • 0
                                    Тогда надо у троллей видимо спрашивать что они думают насчет статической линковки. Но вообще это же косвенно нарушает LGPL.
                                    Кстати второй вопрос, а не пойдет ли вразрез с требованиями Яббла использование qml'я?
                                    • 0
                                      ну я ж говорю, что спрашивали. Они однозначный ответ не дают, лишь рекомендуют динамически линковаться во избежании там чего. Но статическая линковка не запрещена ими явно.
                                      • 0
                                        Ну тут вообще сложный вопрос. По идеи даже с динамической линковкой конечный пользователь не может заменить версию либы на более свежую. Но с другой стороны если тролли не возражают, то и проблем не должно быть.
                                        • 0
                                          да и разработчик не всегда может, нужно кроме динамической линковки еще соблюсьи бинарную совместимость.
                                          Так что еще один камень в огород запрета статической линковки.
                                          Тори не против (нокиевские троли естественно, так как LGPL — это уже подарок от Нокиа).
                                          • 0
                                            Гуд… жаль мака нету, погонял бы этот порт. Но думаю рано или поздно займусь этим делом.
                                            Получается ведь, что Qt это эдакая новая реинкарнация javaME в плане портабельности
                                        • 0
                                          Всем привет )

                                          Сейчас apple разрешил динамическую линковку в ios8

                                          www.qt.io/download/
                                          Mobile app distribution through public app stores — для Community по их таблице не поддерживается

                                          Тут есть пояснение
                                          www.qt.io/qt-licensing-terms/
                                          For example some means of distribution, such as online application stores, may have rules that are in conflict with LGPL, in which case those cannot be used with the LGPL licensing option of Qt.

                                          раньше вроде как они были не против free версии с динамической линковкой в android
                                          сейчас уже пишут что через сторы вообще нельзя распространять

                                          И вот вопрос насколько обоснованы их требования?

                                          Спасибо

                                • 0
                                  да добавлю, что уже несколько раз пользовался статической линковкой в Qt проектах без малейшего угрызения совести.
                                  Проекты были буржуйскиим и проходили аудит как по коду так и юридический.
                                  Один раз юристы спросили, нельзя ли было обойтись динамической линковкой. Это противоречило ТЗ, о чем я им сообщил. Как вариант, можно бло подправить ТЗ и реализовать статическую линковку. Но они сказали что вопрос не критичен и согласились оставить как есть. Так что не только я один считаю так.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • 0
                                    статическая линковка от динамической в этом плане не отличаются.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • 0
                                        Неверно, код библиотеки не собирается. Он уже собран в виде статической библиотеки (в посикс системах это .a файл, в винде вроде .obj). У меня может даже не быть исходников от статической библиотеки.
                                        Более того система может проигнорить статически слинкованую библиотеку и использовать вместо нее динамическую системную. По крайней мере в Linux можно так сделать. В elf-загрузчике в ядре есть такой трик. Наткнулся на него когда возился с бинарным упаковщиком.
                                        В какой-то RTOS я видел вообще, что статическая библиотека грузится в отдельное дарсеное пространство, как динамическая. И получается что если приложение А слинковано со статической библиотекой и содержит его бинарный код. То приложение Б можте этим воспользоватся. Но это уже из очень извращенных форм.

                                        А вот код, который содержится в заголовочных файлах библиотеки собирается вместе с моим приложением. Вот это уже можно рассматривать как нарушение лицензии. Но это происходит как при статической так и при динамической линковке.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • 0
                                            он не собирается, он линкуется статически. Разные вещи. Как раз об этом ничего в лицензии не сказано.
                                            • 0
                                              По вашей логике архив нарушает лицензию, так как все в один файл «собирается вместе».
                                              • 0
                                                А если библиотека использует inline-функции, её вообще нельзя использовать — они же вставляются «как есть»? И шаблоны, кстати, тоже нельзя, а в Qt их достаточно много…
                              • 0
                                Если не использовать private API то ничего противоречащего нет. Так что никаикх проблем с аппрувом не долджно быть.
                                • 0
                                  А внешний вид ПО? Его look and feel?
                                  • 0
                                    а это не жестко регламентировано, вот например одно из моих приложений:
                                    itunes.apple.com/ru/app/id408648085?mt=8
                                    многиче части совсем не подходят под лукэндфил

                                    главное не вводить пользователя в заблуждение, тоесть использовать элементы интефеса не по назначению. А пользоватся своим стилем и дазайном — всегда пожалуйста:
                                    как вариант даже можно привести twitter.app — который по сути предложил новый вариант юхер интерфейса для айпэда
                                    Примеров в действительности очень много.
                                    • 0
                                      То есть чисто теоретически есть даже шанс, что наш qutIM примут в аппстор, если он будет стабильно работать и более менее соответствовать критериям приемки?
                                      • 0
                                        на стабильность его даже проверять не будут, судя по количеству очень бажного софта в аппсторе.
                                        Ну приложения на Mono, Unity3D и других фрейворках же принимают, почему бы и на Qt не принимали?
                                        • 0
                                          То есть в реальности лишь проверяется соответствие заявленному функционалу да отсутствия использования недокументированных хаков?
                                          Я думал там строже проверка
                                          • 0
                                            что именно там происходит — непонятно, но есть очень большая увереность что вся техническая проверка происходит автоматически. Исходники то на аппрув не отсылаются. Да и если приватный апи завернуть в «разрешенный» враппер, то аппрув проходит.
                                            А человеческими усилиями производится проверка на отсутсвие порно/экстимизма/национализма/терроризма и другиз запрещенных тем.
                                            • 0
                                              Private API 100% проверяются автоматикой. В одном проекте сталкивались с таким, reject происходит буквально через 5 секунд после загрузки. Одновременно приходить письмо со списком «нехороших» API.

                                              А можно чуть подробнее про заворачивание запрещенного API во враппер?
                                              • +1
                                                ну все очень просто. Как приват АПИ отслеживатся?
                                                конечно с помощью чегонибудь типа «otool» и «nm» для определения слинкованых библиотек и симоволов.
                                                пусть например нужно вызвать приватный метод AAAA, если мы его вызовем в коде напрямую, либо через селектор. то при сборке у нас будет зависимость на внешний симовл AAAA. С помощью nm можно легко отследить это. Так-же можно отследить локальные символы, которые имеют те-же имена что и глобальные (например UITouch._phase в Three20 имел такую проблему, даже статья на эту тему была).

                                                Так вот что нужно делать чтоб небыло зависимостей? «Ленивая линковка и вызов» с помощью dlopen, dlsym. Первый грузит метод второй линкует метод.
                                                Потом можно с помощью рантайма ( objc_getClass, sel_registerName, objc_msgSend -valueForKey: object_getInstanceVariable, object_getIvar) делать что на мнужно. Такое не отслеживается. Технически сильно возможно, но дмую заморачиваться над этим в эппле ну будут.
                                        • 0
                                          Увы, но GPL-лицензия не совместима с AppStore, поэтому его могут не принять или удалить. Хотя, если у вас есть весь копирайт на код + коммерческая лицензия на Qt, то можно эксклюзивно для AppStore выпустить не-GPL :-)
                                          • 0
                                            Весь копирайт на код (ну практически) есть.
                                • 0
                                  Очень хотелось бы, чтоб какая-нибудь коммерческая организация бы взялась за релизацию этого порта и представила миру (пусть даже за деньги) Lighthouse плагин,

                                  developer.qt.nokia.com/forums/viewthread/1759/ — как раз для lighthouse и, кажется, за деньги :)
                                  • 0
                                    не похоже это на серьезный коммерческий проект :-)
                                  • 0
                                    Кстати, мне кажется, что я эти демки видел до этой статьи и кажется они отсюда.
                                    www.qt-iphone.com/Introduction.html
                                    • 0
                                      да, демки не являются частью статьи, это я добавил для наглядности. Ибо любая статья на хабре должна содержать картинку до ката и видюшки после :-)
                                      Но этот IANFromAfrica пошел тем-же путем: Qt Lighthouse плагин.
                                      • 0
                                        Но он видимо дальше ушел. Я вижу, что оно даже не тормозит
                                        • 0
                                          ну думаю не особо. Торможения как раз связаны с тупым копирование бэкстора в UIView, а реализовать так как я предположил в переводе (через общую видеопамять) не так уж и сложно. Думаю день два поковырять.
                                    • 0
                                      К сожалению, насколько я знаю, оконечные результаты сией работы в gitorious отсутствуют, поэтому если кто-то захочет подхватить эстафету, ему понадобится опять начинать с голого Lighthouse.

                                      Зато у нас есть вот это:
                                      qt.gitorious.org/+grym/qt/grym-android-lighthouse

                                      Ветка «ios» содержит конфиги и патчи, которые нужны для сборки основных модулей Qt для эмулятора и для устройства. Lighthouse-плагин, скорее всего, делать не будем, но подсказать можем.

                                      Присоединяйтесь!
                                    • НЛО прилетело и опубликовало эту надпись здесь

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.