Pull to refresh

Comments 60

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

Каждая новая версия Qt несет в себе огромное колиество вкусностей.
UFO just landed and posted this here
Вы, наверное, хотели сказать «лестных отзывов»? Хотя, если речь о троллях, то отзывы могут действительно быть от остальных жителей леса :)))
Стесняюсь спросить, а почему вдруг не айс?
МойСиквел? Не говоря о RH, который поддерживается как раз комьюнити. Нужна просто служба «ответов на звонки» сбоку. И это случится, я уверен.
MySQL? RH=RedHat? Вы что-то путаете, там некислый бизнес вокруг крутится.

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

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

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

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

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

Да хотя-бы массовый софт начали делать, тоже двигатель прогресса
UFO just landed and posted this here
UFO just landed and posted this here
Видюхи я так понял с него как раз
Интересно, а примут созданное решение в App Store?
для qt есть варианты коммерческого лицензирования. если конечный продукт будет под пропиетартной лицензией (а не под lgpl/gpl), то проблем быть не должно.
lgpl разрешает исползовать Qt с коммерческим продуктом. Так что LGPL очень даже подходит.
С коммерческим разрешает, а вот с проприентарным — только при условии динамической линковки. Так что для AppStore нужно будет либо полностью открыть свой код, либо покупать коммерческую лицензию.
устал уже спорить с этим мифом. Про динамическу и статическую линковку нигде в lgpl не сказано. Это уже додумки и по lgpl никто не запрещает статически линковаться.
Более того, динамическая линковка как таковой по сути не является, часть кода даже при динамической линковке линкуется статически (как минимум хедеры).

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

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

Сейчас 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 проектах без малейшего угрызения совести.
Проекты были буржуйскиим и проходили аудит как по коду так и юридический.
Один раз юристы спросили, нельзя ли было обойтись динамической линковкой. Это противоречило ТЗ, о чем я им сообщил. Как вариант, можно бло подправить ТЗ и реализовать статическую линковку. Но они сказали что вопрос не критичен и согласились оставить как есть. Так что не только я один считаю так.
UFO just landed and posted this here
статическая линковка от динамической в этом плане не отличаются.
UFO just landed and posted this here
Неверно, код библиотеки не собирается. Он уже собран в виде статической библиотеки (в посикс системах это .a файл, в винде вроде .obj). У меня может даже не быть исходников от статической библиотеки.
Более того система может проигнорить статически слинкованую библиотеку и использовать вместо нее динамическую системную. По крайней мере в Linux можно так сделать. В elf-загрузчике в ядре есть такой трик. Наткнулся на него когда возился с бинарным упаковщиком.
В какой-то RTOS я видел вообще, что статическая библиотека грузится в отдельное дарсеное пространство, как динамическая. И получается что если приложение А слинковано со статической библиотекой и содержит его бинарный код. То приложение Б можте этим воспользоватся. Но это уже из очень извращенных форм.

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

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

А можно чуть подробнее про заворачивание запрещенного API во враппер?
ну все очень просто. Как приват АПИ отслеживатся?
конечно с помощью чегонибудь типа «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 и, кажется, за деньги :)
не похоже это на серьезный коммерческий проект :-)
да, демки не являются частью статьи, это я добавил для наглядности. Ибо любая статья на хабре должна содержать картинку до ката и видюшки после :-)
Но этот IANFromAfrica пошел тем-же путем: Qt Lighthouse плагин.
Но он видимо дальше ушел. Я вижу, что оно даже не тормозит
ну думаю не особо. Торможения как раз связаны с тупым копирование бэкстора в UIView, а реализовать так как я предположил в переводе (через общую видеопамять) не так уж и сложно. Думаю день два поковырять.
К сожалению, насколько я знаю, оконечные результаты сией работы в gitorious отсутствуют, поэтому если кто-то захочет подхватить эстафету, ему понадобится опять начинать с голого Lighthouse.

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

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

Присоединяйтесь!
Пардон, не заметил. Видимо, это не тот порт, который мы смотрели.
UFO just landed and posted this here
Sign up to leave a comment.

Articles