Прощай, Smeegol

Если честно, то очень сомневаюсь что там всё ок, раз вместо одного нового метода можно использовать один старый.

а юзеры будут ждать, что после обновления с андроида 1.6 на 2.2 начнут нормально работать ...

Начнут, только если разработчики дождались выхода нового SDK и реализовали поддержку новых возможностей ОС. Юзеры, ожидающие от приложений времён 1.6 поддержки фич 2.2 — дебилы ССЗБ.

К тому же, тебе уже сказали, что возможность выбора используемых фич в зависимости от версии API в run-time куда больше зависит от языка, чем от тулкита, и Qt тут не при чём. Можно, конечно, сделать загрузчик бинарников так, чтобы dlsym он делал при первом вызове функции, но это чревато — если программа попыталась вызвать отсутствующую функцию без предварительной проверки её существования, ей (программе) станет очень плохо. Так пусть уж лучше при установке пользователь увидит сообщение, что программе нужна более новая версия системы/библиотеки и программа не установится/запустится, чем запустится, какое-то время проработает, а потом внезапно навернётся в никуда.

Там есть какое-то стандартное API для extension'ов, а их как раз можно и выбирать в зависимости от версии

> А как автоматизация тестирования в таких случаях реализуется? Разные тесты, или тесты одни, но с разными либами?

я не пробовал делать автоматическое тестирование.

> Если честно, то очень сомневаюсь что там всё ок, раз вместо одного нового метода можно использовать один старый.

только в одиночных случаях.. чаще в старом api просто нет альтернативы новому, и просто фича отключается.

> Там есть какое-то стандартное API для extension'ов, а их как раз можно и выбирать в зависимости от версии

там - это в qt или в meego?

> Начнут, только если разработчики дождались выхода нового SDK и реализовали поддержку новых возможностей ОС

приложение вполне себе новое. разработка началась даже после выхода 2.3. но устройств с 1.6 и 2.1 по прежнему хватает. и некоторые 2.1 устройства как раз сейчас получают, или недавно получили, обновления на 2.2.

К тому же, тебе уже сказали, что возможность выбора используемых фич в зависимости от версии API в run-time куда больше зависит от языка, чем от тулкита, и Qt тут не при чём.

так я ведь потому и удивился, что выбрали именно qt и c++. потому что в этом языке (c++) нет такой возможности. а в qt она если и есть - то костыльная. но пока что все указывает на то, что ее скорее нет вообще.

Так пусть уж лучше при установке пользователь увидит сообщение, что программе нужна более новая версия системы/библиотеки и программа не установится/запустится, чем запустится, какое-то время проработает, а потом внезапно навернётся в никуда.

для этого в AndroidManifest.xml можно просто указать minsdkversion=8 :) тогда прогу юзер даже в маркете не увидит.

просто задача несколько иная.

В meego

Плюс можно Qt Quick юзать, там этой проблемы нету в принципе ибо оно фактически другой ЯП

>> А как автоматизация тестирования в таких случаях реализуется? Разные тесты, или тесты одни, но с разными либами?

я не пробовал делать автоматическое тестирование.

Тогда понятно. Насколько я понимаю нет ни одного приемлемого метода для вашего случая. Все будут с недостатками.

да, использовать питон/жабу и другие managed языки с qt bindings - это само собой сработает. вопрос в том что из них будет официальным, поддерживаемым, работающим на всех девайсах, и всех версиях meego, и через 10 лет :)

> Все будут с недостатками.

это и расстраивает. непонятно как пойдет развитие платформы с таким фундаментальным пробелом. надеюсь, решение есть, или появится.

На нетбуках MeeGoo не будет, на смартфонах - тоже не будет, если что - http://www.reuters.com/article/2011/02/09/nokia-meego-idUSLDE7180X420110209

Где будет MeeGo? Правильно - нигде.

> Андрей ... (Andrew ...)

А давайте переводить Michael как Михаил, Damon как Дмитрий и т.д.

Хм… Тоже вариант, но это не обратная совместимость. В таком случае интроспекции в Qt вам хватит.

Кстати про обратную совместимость с версиями в которых используемой фичи ещё не было. Создаём шаблонный класс (чтобы жил на стороне приложения, а не на стороне библиотеки), внутри которого проверяем версию библиотеки и в зависимости от того есть ли в этой версии та или иная фича, дёргаем либо код из библиотеки, либо реализацию этого кода на месте.

на основании чего ты считаешь что это может сработать? работающий пример можно?

QtQuick

А суть в том, что C++ гробит проекты.

т.е. это официальный managed-язык для meego? не умрет?

Официальнее не куда. Это часть Qt framework!

Работающий пример чего? Обёртки вокруг класса или метаинформации в Qt?

> дёргаем либо код из библиотеки, либо реализацию этого кода на месте.

хотелось бы добавить, что обычно (точнее даже - всегда) такие штуки нужны для кода который нельзя «реализовать на месте». т.е. это чаще всего части os, которые нельзя просто у себя в userland переписать ручками, типа управления сервисами всякими, мультимедией, контактами, календарями и пр.

надо либо дергать аналогичную функцию из старой версии либы, если есть, либо ничего не делать.

пример того что ты предложил.. класс, который может вызывать функцию нового API, если версия библиотеки новая, либо, допустим, ничего не делать если библиотека старая. я считаю что это на этапе загрузки эльфа загнется, при старой библиотеке.

Чёрт. А ведь и правда, так и будет. Я толкиенист…

Тогда только интроспекция.

>То, что проект MeeGo всё меньше интересуется рынком нетбуков, стало ясно на последнем FOSDEM

То, что проект MeeGo все меньше интересуется рынком и пытается тихо в норке умереть, стало ясно после новости об отмене разработки смартфона на MeeGo.

И что мы имеем? Недоделанную систему, которая не для нетбуков и не для телефонов. А для чего? Для планшетов? А кто будет их выпускать?

Т.е. мертвое оно.

Самое интересное - как две такие здоровые кампании смогли так бездарно завалить систему с наработками?.. Вон Самсунг Bada сотворил и ничего...

Эндрю?

По дефолту

> Плюс можно Qt Quick юзать, там этой проблемы нету в принципе ибо оно фактически другой ЯП

Что-то я про него забыл. Его для написания программ можно использовать? Или только Qt api дергать можно? В смысле: сам Qt Quick является полноценным языком?

Хотя если создавать приватный объект через QMetaType и дергать его через QMetaObject будет работать.

дада, и еще интересно можно ли из него дергать нативный сишный код (и, наоборот, дергать quick из нативного), наподобие jni в жабе.

почему оно будет работать? как будет происходить связывание твоего приложения с qt library call? если вызов функции есть в эльфе - значит функция есть в импортах. значит эльф не загрузится.

Объект тулкита будет использовать только get,set , а все остальное свое .. тулкиту данные строки нужны , а мне внутри приложения ее методы . Тулкит может запросто сделать QString s( s_in.get); . Ну это если совсем в лоб

Qt Quick consists of:

* QML: JavaScript-like declarative language

офигеть, как не пистон так js ))

> declarative

это значит что на нем нельзя писать код, а можно только описывать какие-то данные, так? типа xml или json

А как в Qt бинарную совместимость чуть ли не с Qt 4.3 тянут?

Намек на «непосильный» труд, состоящий в том, чтобы «тянуть» бинарную совместимость между минорными версиями такой серьезной либы. Это же не студенческая поделка.

Самое интересное - как две такие здоровые кампании смогли так бездарно завалить систему с наработками?

Кстати да, тут выше кто-то поднимал тему, что у миго с финансированием проблемы .. ну вот не верю , что нокла + интел не потянули финансирование на уровне космонавта хотя бы

скорее так (из википедии):
Выражение «декларативный язык» иногда употребляется для описания всех таких языков программирования как группы, чтобы подчеркнуть их отличие от императивных языков.

меня твоя терминология только еще больше путает. можно какой-то пример, как это делается, или линк на доку?

в принципе - да, понятно, что если это интерфейс с набором pure virtual methods, то пока не вызовешь метод не будет ошибки, и этим можно воспользоваться. но я не уверен, что такая совместимость (на базе C++) сработает в долгосрочной перспективе. между парой минорных релизов как максимум.. тут без managed обертки не обойтись. objc идеально подходит, на мой взгляд.

ну.. по описанию ближе к xml, чем к javascript (который нифига не декларативный)

Я на другую нить разговора немного отвечал .. там был ответ на мой бред :)

ой, сорри, запутался в ответах :)

и пожертвовал разработками, основанными на GTK.

Даже не знаю, что и сказать. Удачи разработчикам, основанным нам qt.

Я за то, чтобы запретить комментировать новости. Кроме троллизма тут больше никакой интересной информации.

ну это такое ..., для методистов больше.

Тут другое.
Это все скорее как метод (способ), «стабильность» тут может быть как побочный эффект: может быть , а может и не быть.
Никто ничего не обещал , учитывая само растяжимое понятие javascript.

Грядет какая-то новая формация людей:
им достаточно ссылки на описание «пыли на задней крышке монитора» для веры в стабильность ЯП и либ.

>под линухом с gtk приходится несколько отдельных билдов собирать. еще можно попытаться через dlopen/dlsym выкрутиться, не знаю насколько это будет сложно.

я для классов-оберток для gobjectо-производных в таких случаях делал вызываторы конструкторов g_ololo_new, а те, если не было символа в библиотеке, throwали. точнее, они возвращали null, а базовый класс который знал про gobject видел null и throwaл.

> Объект тулкита будет использовать только get,set , а все остальное свое .. тулкиту данные строки нужны , а мне внутри приложения ее методы . Тулкит может запросто сделать QString s( s_in.get); . Ну это если совсем в лоб

И как же тулкит доберётся хоть до данных, хоть до get/set, если весь код статически прилинкованного QString находится внутри твоего приложения и наружу никак не торчит? Даже если тулкит наплюёт на принцип инкапсуляции и полезет напрямую во внутренности QString-а, в обход всех его методов, то что, тупо надеяться на авось, что в твоей строке все поля/структуры «для личного пользования» никуда не уехали и находятся там же (с теми же смещениями относительно самого объекта строки), где и в QString-е тулкита?

Не говори ерунду. Ладно ещё «конечности» вроде QtWebKit статически приделывать, т.к. остальные модули от него не зависят и ничего оттуда дёргать не будут, но совать в приложение кусок ядра, которым так или иначе пользуются почти все компоненты тулкита...

Да я уже и сам понял что ерунду сказал .. скорее имел ввиду не один какой либо класс статически слинковать , а например весь модуль работы с сетью или всю графику

как такое получалось? допустим, ты линкуешься к либе gtk 2.20, пишешь прогу что использует только API 2.10, запускаешь на системе с 2.10.. у меня уже на загрузке эльфа ругня в этой ситуации.

У… Можно я просто оставлю ссылки на документацию по QMetaType и QMetaObject, а сам пойду человека встречу? В реализацию этого бардака я пока не лазил и, как это обычно бывает в случае Qt, боюсь того что там могу увидеть.

вообще, я начал с того, что составил xls со списком того, что поддерживается с какой версии.

далее пишем: нижняя версия библиотеки - 2.12 например. далее, создал классы g::object g::copyableobject и notnull - для производных от gobject и просто диких структур. первый - это для хреней с сигналами(окна) - тупо в падлу копировать обработчики и состояния. второй для всяких ресурсов типа GdkPixbuf, третий - для прочих структур. 1й и 3й не терпят null.

пусть есть Ololo * g_ololo_new(int x)
Ololo * g_ololo_new_with_stuff(int x, void * stuff)

я делаю фальшивые g_ololo_new... которые делают
{
static Ololo (* _g_ololo_new)(int x);
if(!_g_ololo_new){
g_atomic_pointer(&_g_ololo_new, dlsym(«g_ololo_new»,RTLD_NEXT));
if(!_g_ololo_new)throw ....;
}
return g_ololo_new(args)
}
вышенаписанное делается макросом или можно нашаблонить. не самый лучший подход, но он работает. главное помнить, что при создании некоторых элементов могут прилететь исключения not_supported.

если надо, могу прислать реализацию этой муры, как только до дома доберусь