Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Я не очень знаком с BADA, но там Linux и C++ — этого достаточно :-)
Основная проблема — не портировать. Основная проблема — поддержка. Делать комерческий продукт на коммунити поддерживаемом продукте — не айс.
Да тоже обрадовало, что кто-то решился взятся за порт.
Когда-то давно я пытался портировать QtEmbedded с QWS под мак, но там были посложнее проблеммы (в частности QVFB был жестко завязан на X11). Просто хотел отлаживать QWS приложения под маком.
Но Lighthouse более правильное решени — абстагироваться от оконных систем вообще и от QWS в частности.
Каждая новая версия Qt несет в себе огромное колиество вкусностей.
Основная проблема — не портировать. Основная проблема — поддержка. Делать комерческий продукт на коммунити поддерживаемом продукте — не айс.
Да тоже обрадовало, что кто-то решился взятся за порт.
Когда-то давно я пытался портировать QtEmbedded с QWS под мак, но там были посложнее проблеммы (в частности QVFB был жестко завязан на X11). Просто хотел отлаживать QWS приложения под маком.
Но Lighthouse более правильное решени — абстагироваться от оконных систем вообще и от QWS в частности.
Каждая новая версия Qt несет в себе огромное колиество вкусностей.
Стесняюсь спросить, а почему вдруг не айс?
МойСиквел? Не говоря о RH, который поддерживается как раз комьюнити. Нужна просто служба «ответов на звонки» сбоку. И это случится, я уверен.
МойСиквел? Не говоря о RH, который поддерживается как раз комьюнити. Нужна просто служба «ответов на звонки» сбоку. И это случится, я уверен.
>Основная проблема — не портировать. Основная проблема — поддержка. Делать комерческий продукт на коммунити поддерживаемом продукте — не айс.
Ну ежели коммьюнити набъет cydia кучей Qt софта, то дело по любому быстрее пойдет. Тем более всё равно для того, чтобы прогу на Qt в appstore приняли придется покупать коммерческую лицензию на Qt.
Ну ежели коммьюнити набъет cydia кучей Qt софта, то дело по любому быстрее пойдет. Тем более всё равно для того, чтобы прогу на Qt в appstore приняли придется покупать коммерческую лицензию на Qt.
Good job!
Интересно, а какое тогда отношение этот порт к этому имеет?
www.qt-iphone.com/Introduction.html
www.qt-iphone.com/Introduction.html
Интересно, а примут созданное решение в App Store?
для qt есть варианты коммерческого лицензирования. если конечный продукт будет под пропиетартной лицензией (а не под lgpl/gpl), то проблем быть не должно.
lgpl разрешает исползовать Qt с коммерческим продуктом. Так что LGPL очень даже подходит.
С коммерческим разрешает, а вот с проприентарным — только при условии динамической линковки. Так что для AppStore нужно будет либо полностью открыть свой код, либо покупать коммерческую лицензию.
устал уже спорить с этим мифом. Про динамическу и статическую линковку нигде в lgpl не сказано. Это уже додумки и по lgpl никто не запрещает статически линковаться.
Более того, динамическая линковка как таковой по сути не является, часть кода даже при динамической линковке линкуется статически (как минимум хедеры).
Там есть дин пункт (вроде 6a), который трактуется некоторыми как статическая линковка, но это не так.
Даже Qt у себя официально писали, что вопрос не однозначный и они рекомендуют (не запрещают) для подстраховки линковаться динамически. Но это рекомендация, а не запрет.
Более того, динамическая линковка как таковой по сути не является, часть кода даже при динамической линковке линкуется статически (как минимум хедеры).
Там есть дин пункт (вроде 6a), который трактуется некоторыми как статическая линковка, но это не так.
Даже Qt у себя официально писали, что вопрос не однозначный и они рекомендуют (не запрещают) для подстраховки линковаться динамически. Но это рекомендация, а не запрет.
Верно, слов «динамическая» и «статическая» линковка в тексте лицензии нет. Но должна быть возможность слинковатся с более новой версией библиотеки. Варианты решения — открытие исходного кода, динамическая линоковка, .obj-файлы с свбодном доступе
это тоже не однозначно. Так как линквка может быть и на стадии сборки, этого никто явно не запрещает.
С другой стороны, если нужно избежать статической линковки, но при этом без нее нельзя, то есть несколько вариантов решения. Самый простой — это пишется неки wrapper (API proxy) с которым статически линкуется LGPL билбиотека. Исходный код этого враппера свободно выкладывается в свободный доступ, а само комерческое приложение линкуется динамически с этим враппером.
Так-же обходят и GPL. Только вместо врапперов используют отдельные приложения, взаимодействие с котоыми происходит любым доступным IPC методом (пайпа, сокеты, файлы ...)
С другой стороны, если нужно избежать статической линковки, но при этом без нее нельзя, то есть несколько вариантов решения. Самый простой — это пишется неки wrapper (API proxy) с которым статически линкуется LGPL билбиотека. Исходный код этого враппера свободно выкладывается в свободный доступ, а само комерческое приложение линкуется динамически с этим враппером.
Так-же обходят и GPL. Только вместо врапперов используют отдельные приложения, взаимодействие с котоыми происходит любым доступным IPC методом (пайпа, сокеты, файлы ...)
Одного не пойму, что мешает слинковаться с Qt динамически и положить Qt либы рядом с бинарником кроме того, что весить это кучу будет? Но в application bundle так и делают все макоразрабы.
в iOS принято линковаться статически. Динамическая линковка только с системными общими библиотеками. Разработка под iOS в многом отличатеся от Mac OS.
Тогда надо у троллей видимо спрашивать что они думают насчет статической линковки. Но вообще это же косвенно нарушает LGPL.
Кстати второй вопрос, а не пойдет ли вразрез с требованиями Яббла использование qml'я?
Кстати второй вопрос, а не пойдет ли вразрез с требованиями Яббла использование qml'я?
ну я ж говорю, что спрашивали. Они однозначный ответ не дают, лишь рекомендуют динамически линковаться во избежании там чего. Но статическая линковка не запрещена ими явно.
Ну тут вообще сложный вопрос. По идеи даже с динамической линковкой конечный пользователь не может заменить версию либы на более свежую. Но с другой стороны если тролли не возражают, то и проблем не должно быть.
Всем привет )
Сейчас 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
сейчас уже пишут что через сторы вообще нельзя распространять
И вот вопрос насколько обоснованы их требования?
Спасибо
Сейчас 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
сейчас уже пишут что через сторы вообще нельзя распространять
И вот вопрос насколько обоснованы их требования?
Спасибо
да добавлю, что уже несколько раз пользовался статической линковкой в Qt проектах без малейшего угрызения совести.
Проекты были буржуйскиим и проходили аудит как по коду так и юридический.
Один раз юристы спросили, нельзя ли было обойтись динамической линковкой. Это противоречило ТЗ, о чем я им сообщил. Как вариант, можно бло подправить ТЗ и реализовать статическую линковку. Но они сказали что вопрос не критичен и согласились оставить как есть. Так что не только я один считаю так.
Проекты были буржуйскиим и проходили аудит как по коду так и юридический.
Один раз юристы спросили, нельзя ли было обойтись динамической линковкой. Это противоречило ТЗ, о чем я им сообщил. Как вариант, можно бло подправить ТЗ и реализовать статическую линковку. Но они сказали что вопрос не критичен и согласились оставить как есть. Так что не только я один считаю так.
статическая линковка от динамической в этом плане не отличаются.
Неверно, код библиотеки не собирается. Он уже собран в виде статической библиотеки (в посикс системах это .a файл, в винде вроде .obj). У меня может даже не быть исходников от статической библиотеки.
Более того система может проигнорить статически слинкованую библиотеку и использовать вместо нее динамическую системную. По крайней мере в Linux можно так сделать. В elf-загрузчике в ядре есть такой трик. Наткнулся на него когда возился с бинарным упаковщиком.
В какой-то RTOS я видел вообще, что статическая библиотека грузится в отдельное дарсеное пространство, как динамическая. И получается что если приложение А слинковано со статической библиотекой и содержит его бинарный код. То приложение Б можте этим воспользоватся. Но это уже из очень извращенных форм.
А вот код, который содержится в заголовочных файлах библиотеки собирается вместе с моим приложением. Вот это уже можно рассматривать как нарушение лицензии. Но это происходит как при статической так и при динамической линковке.
Более того система может проигнорить статически слинкованую библиотеку и использовать вместо нее динамическую системную. По крайней мере в Linux можно так сделать. В elf-загрузчике в ядре есть такой трик. Наткнулся на него когда возился с бинарным упаковщиком.
В какой-то RTOS я видел вообще, что статическая библиотека грузится в отдельное дарсеное пространство, как динамическая. И получается что если приложение А слинковано со статической библиотекой и содержит его бинарный код. То приложение Б можте этим воспользоватся. Но это уже из очень извращенных форм.
А вот код, который содержится в заголовочных файлах библиотеки собирается вместе с моим приложением. Вот это уже можно рассматривать как нарушение лицензии. Но это происходит как при статической так и при динамической линковке.
он не собирается, он линкуется статически. Разные вещи. Как раз об этом ничего в лицензии не сказано.
По вашей логике архив нарушает лицензию, так как все в один файл «собирается вместе».
А если библиотека использует inline-функции, её вообще нельзя использовать — они же вставляются «как есть»? И шаблоны, кстати, тоже нельзя, а в Qt их достаточно много…
Если не использовать private API то ничего противоречащего нет. Так что никаикх проблем с аппрувом не долджно быть.
А внешний вид ПО? Его look and feel?
а это не жестко регламентировано, вот например одно из моих приложений:
itunes.apple.com/ru/app/id408648085?mt=8
многиче части совсем не подходят под лукэндфил
главное не вводить пользователя в заблуждение, тоесть использовать элементы интефеса не по назначению. А пользоватся своим стилем и дазайном — всегда пожалуйста:
как вариант даже можно привести twitter.app — который по сути предложил новый вариант юхер интерфейса для айпэда
Примеров в действительности очень много.
itunes.apple.com/ru/app/id408648085?mt=8
многиче части совсем не подходят под лукэндфил
главное не вводить пользователя в заблуждение, тоесть использовать элементы интефеса не по назначению. А пользоватся своим стилем и дазайном — всегда пожалуйста:
как вариант даже можно привести twitter.app — который по сути предложил новый вариант юхер интерфейса для айпэда
Примеров в действительности очень много.
То есть чисто теоретически есть даже шанс, что наш qutIM примут в аппстор, если он будет стабильно работать и более менее соответствовать критериям приемки?
на стабильность его даже проверять не будут, судя по количеству очень бажного софта в аппсторе.
Ну приложения на Mono, Unity3D и других фрейворках же принимают, почему бы и на Qt не принимали?
Ну приложения на Mono, Unity3D и других фрейворках же принимают, почему бы и на Qt не принимали?
То есть в реальности лишь проверяется соответствие заявленному функционалу да отсутствия использования недокументированных хаков?
Я думал там строже проверка
Я думал там строже проверка
что именно там происходит — непонятно, но есть очень большая увереность что вся техническая проверка происходит автоматически. Исходники то на аппрув не отсылаются. Да и если приватный апи завернуть в «разрешенный» враппер, то аппрув проходит.
А человеческими усилиями производится проверка на отсутсвие порно/экстимизма/национализма/терроризма и другиз запрещенных тем.
А человеческими усилиями производится проверка на отсутсвие порно/экстимизма/национализма/терроризма и другиз запрещенных тем.
Private API 100% проверяются автоматикой. В одном проекте сталкивались с таким, reject происходит буквально через 5 секунд после загрузки. Одновременно приходить письмо со списком «нехороших» API.
А можно чуть подробнее про заворачивание запрещенного API во враппер?
А можно чуть подробнее про заворачивание запрещенного API во враппер?
ну все очень просто. Как приват АПИ отслеживатся?
конечно с помощью чегонибудь типа «otool» и «nm» для определения слинкованых библиотек и симоволов.
пусть например нужно вызвать приватный метод AAAA, если мы его вызовем в коде напрямую, либо через селектор. то при сборке у нас будет зависимость на внешний симовл AAAA. С помощью nm можно легко отследить это. Так-же можно отследить локальные символы, которые имеют те-же имена что и глобальные (например UITouch._phase в Three20 имел такую проблему, даже статья на эту тему была).
Так вот что нужно делать чтоб небыло зависимостей? «Ленивая линковка и вызов» с помощью dlopen, dlsym. Первый грузит метод второй линкует метод.
Потом можно с помощью рантайма ( objc_getClass, sel_registerName, objc_msgSend -valueForKey: object_getInstanceVariable, object_getIvar) делать что на мнужно. Такое не отслеживается. Технически сильно возможно, но дмую заморачиваться над этим в эппле ну будут.
конечно с помощью чегонибудь типа «otool» и «nm» для определения слинкованых библиотек и симоволов.
пусть например нужно вызвать приватный метод AAAA, если мы его вызовем в коде напрямую, либо через селектор. то при сборке у нас будет зависимость на внешний симовл AAAA. С помощью nm можно легко отследить это. Так-же можно отследить локальные символы, которые имеют те-же имена что и глобальные (например UITouch._phase в Three20 имел такую проблему, даже статья на эту тему была).
Так вот что нужно делать чтоб небыло зависимостей? «Ленивая линковка и вызов» с помощью dlopen, dlsym. Первый грузит метод второй линкует метод.
Потом можно с помощью рантайма ( objc_getClass, sel_registerName, objc_msgSend -valueForKey: object_getInstanceVariable, object_getIvar) делать что на мнужно. Такое не отслеживается. Технически сильно возможно, но дмую заморачиваться над этим в эппле ну будут.
Увы, но GPL-лицензия не совместима с AppStore, поэтому его могут не принять или удалить. Хотя, если у вас есть весь копирайт на код + коммерческая лицензия на Qt, то можно эксклюзивно для AppStore выпустить не-GPL :-)
Очень хотелось бы, чтоб какая-нибудь коммерческая организация бы взялась за релизацию этого порта и представила миру (пусть даже за деньги) Lighthouse плагин,
developer.qt.nokia.com/forums/viewthread/1759/ — как раз для lighthouse и, кажется, за деньги :)
Кстати, мне кажется, что я эти демки видел до этой статьи и кажется они отсюда.
www.qt-iphone.com/Introduction.html
www.qt-iphone.com/Introduction.html
К сожалению, насколько я знаю, оконечные результаты сией работы в gitorious отсутствуют, поэтому если кто-то захочет подхватить эстафету, ему понадобится опять начинать с голого Lighthouse.
Зато у нас есть вот это:
qt.gitorious.org/+grym/qt/grym-android-lighthouse
Ветка «ios» содержит конфиги и патчи, которые нужны для сборки основных модулей Qt для эмулятора и для устройства. Lighthouse-плагин, скорее всего, делать не будем, но подсказать можем.
Присоединяйтесь!
Зато у нас есть вот это:
qt.gitorious.org/+grym/qt/grym-android-lighthouse
Ветка «ios» содержит конфиги и патчи, которые нужны для сборки основных модулей Qt для эмулятора и для устройства. Lighthouse-плагин, скорее всего, делать не будем, но подсказать можем.
Присоединяйтесь!
там же ссылка есть, с нуля начинать не нужно:
qt.gitorious.org/+qt-developers/qt/lighthouse/trees/master/src/plugins/platforms/uikit
qt.gitorious.org/+qt-developers/qt/lighthouse/trees/master/src/plugins/platforms/uikit
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Представляю доказательства возможности портировать Qt Lighthouse на iOS (UIKit)