В общем изучив спеки midp 1.0, 2.0 понял что работает это везде - это хорошо. Главная задача работать везде, а не только на экзотических новых фруктах-> читай смартфонах.
Апи канваса понравился, но даже game апи, введённый в midp2, весьма низкоуровневый. Понятно, что слабать свой высокоуровневый канвас на базе этого теоретически можно(хотя не всё можно, например повороты, искажения объектов и тд - это же не попиксельно делать?:D)
Посему вопрос, что используют явовцы, когда надо чтобы работало везде, но надо чтобы api был удобный.
Аля:
create container 1
create image 2
create image 3
add image 2 and image 3 to container 1
rotate container 1 on 35 deg
scale containter 1 up 2.0
move containter to bottom canvas

ну и тд.

Да, почитал про m3g, оно конечно хорошо, но на мобильниках дешёвых робед ли?
Проприетарные вендорлокины не вариант, поэтому апи доступные под странными несовместимыми с gpl лицензиями или доступные только под 2,5 телефона - не вариант

Вот плачу тебе мой милый лор, ведь ты полон умных голов, постигнувших сею стезю.

PS: Даже на дешёвых ноклах, есть игрушки, в которых всё работает очень плавненько. Хотя и вглядевшись, не увидел там ротейтов и тд, скорее используется sprite, но в некоторых гоночках кажется юзаются полигоны.

Обычная сериализация в json это конечно прекрасно, но надо не совсем это. В общем допустим у нас есть объект, допустим этот объект целое дерево объектов. Допустим в нём есть как данные, так и методы. Вот хочется взять его, упаковать вместе с методами и потом распаковать где-нибудь и запустить. Про кучу подводных камней типа уж точно не работающих замыканий и вообще разные доступные контексты - не напоминать, это и ежу понятно. Предположим, что все методы работают _только_ с теми данными, которые есть в объекте. Костыль такой конечно навоять можно, но вдруг уже навояли, вдруг там ещё в чьей-то реализации заволялась возможность упаковывать в объект те объекты, на которых в свойствах есть лишь ссылки.

Сначала общее рассуждение. Допустим мне нужны разные девайсы с разными характеристиками, допустим есть разные проекты с открытыми спеками, которые подходят в качестве основы(beagbleboard, igep, sheevaplug). Допустим также, что модификации не столь значительны, то есть добавить тот порт, убрать этот, изменить дизайн корпуса или поместить в корпус с тачскрином. Также допустим вопрос поддержки со стороны софта вообще не волнует, ибо эта работа берётся на себя. Сколько это стоит, к примеру у них http://www.globalscaletechnologies.com? Или у кого-нибудь ещё? Каковы условия?(ну там минимальный размер партии, срок выполнения, права на внесённые изменения и тд)

Теперь более конкретно. Допустим есть sheevaplug, в его основе лежит чип с поддержкой vga и наличие у OpenRD-Ultimate всех возможных и невозможных входов и выходов как бы намекает, что подобное сделать можно с sheevaplug. Так вот, основываясь на вышесказанном сколько будет стоить производство этакого sheevaplug, но заключённого в 7и дюймовый корпус, одна сторона корпуса с тачскринным дисплеем, в числе портов должны быть хотя бы 3и usb, хотя бы 1 sata(хорошо если внутренний и есть место внутри для 2,5 винта, но не обязательно) и конечно же vga или dvi|hdmi

Пример с 7и дюймовым sheevaplug - это чисто теоретический пример, любые совпадения случайны и любые сценарии практического применения мифичны. Вопрос лишь в том, о какой сумме, размере партии и сроках производства идёт речь.

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

Раз уж весна, солнце, день чудесный, то. Дорогой лор, пишу тебе вот по какой теме: Есть некая дева, есть желание чего-нибудь ей задарить. Поскольку о ней я знаю только имя, примерно характер и место работы(коллектив женский там), то возникла мысль подарить ей хороший букет, когда в следующий раз зайду. За одно и остальным представительницам красивого пола задарить по цветку хотя бы, чтобы не обидно было:) Но есть одно но, ведь не всем нравятся цветы? Как быть? Есть что-то более подходящее? Ну или скажем такое же, чтобы продумать запасной вариант - типо раз не нравятся цветы, то получай ... Что ещё нравится может? Не очень хочется оказаться в ситуации: "а цветы я не люблю..." Хотя конечно не смертельно, всегда можно спросить что любишь:) Прошу помощи однако. Альтернативные варианты тоже принимаются, скажем не задарить, а пригласить.

python, Java, .NET - отметаются, моно - может быть, если оно умеет, с C# пока не сталкивался. В общем задача на много времени вперёд(несколько лет как минимум), поэтому языки типо JS, lua и прочего - отметаются. По этой же причине вопрос этот решаться будет неспешно, так как ещё финансирование не созрело. Принимаются только те языки, которые можно назвать зрелыми и универсальными. Не обязательно, чтобы поддержка была такая однозначно простая, как у динамических языков. Можно и с костылями, но всё же тащить с собой скажем gcc - не особо хочется:), хотя и можется. Также жизненно необходима интеграция(человеческая, а не марсианская) с С, так как на нём предполагается ядро и все базовые компоненты и это не обсуждается. Язык же с сериализацией кода будет работать поверх этой созданной платформы. Рассматриваю пока в качестве кандидатов: C(не совсем удобно, но привычно, хотя в некоторых случаях придётся тащить большой багаж), perl5(почти идеальный вариант и по портируемости и по удобству, но производительность - это проблема), perl6(тоже что и предыдущий, но более идеальный, однако производительность паррота пока говно, и не ясно будет ли толковый JIT, ну и ещё ракудо не созрел),CommonLisp(кажется, что идеал, в виде sbcl, но это язык с которым у меня нет опыта, однако это не проблема. Производительность видимо не проблема, раз компилируемый. Вопрос сразу к лисперам, как оно там, при значительном динамическом обновлении рабочего кода, ничего?).

Отдельно замечу, что проект будет по архитектуре чем-то напоминать emacs, другое предназначение совсем, но по архитектуре похоже. То есть 90% кода предполагается делать на том самом языке с сериализацией кода. Зачем это нужно? - для динамического обновления приложения, изменения его логики на лету и тд. Для данного приложения это жизненно необходимо. В отличие от емакса будет более модульно, из микрокомпонент, но это не суть важно, в контексте сабжевой задачи можно считать просто, что 10% кода это некая программа на С, которая загружает некоторый кусок(90%) на другом языке и общается с ним. Что порекомендует всезнающий олл? Вопрос прежде всего к тем, кто имеет не теоретические, а практические знания.

PS: фанатов языков прошу не беспокоить, до известного предела я готов посмотреть на какие-то варианты, но только до известного предела.

http://www.netbooknews.com/2296/ipad-alternative-toshiba-journe/ Для Ъ там arm планшет на 7мь дюймов от тошибы на снапдрагоне. Лёгкий, удобный, не грамозкий, металлический(насколько видно по видео, может ошибаюсь). С hdmi, usb, miniusb, пультом. Один жирный минус - win ce, но там похоже весь софт вебный, так что почти пофигу.

В общем появилась необходимость в нормальном комбобоксе выбора кодировок. К которому можно было бы цеплять список предворительно отсортированных кодировок. Примерно так, как это реализовано в gedit, когда вы открываете файл, там внизу комбобок выбора кодировок и там реализована возможность отсортировать кодировки ну тд. Одно но, как видно тут: http://git.gnome.org/browse/gedit/tree/gedit/gedit-encodings-combo-box.h Данная фича наглухо(ну не совсем на глухо), но почти захардкодена в gedit. А мне надо заюзать её как минимум в двух своих приложениях. Отсюда вопрос, а есть ли подобное отдельно? Желательно в виде двух компонент, одна из них кобобокс+диалог редактирования|сортировки как в gedit. А другая - сортированный список кодироков, как опять же это сделано в gedit - http://git.gnome.org/browse/gedit/tree/gedit/gedit-encodings.c. Советы - выдрать, разделить, и заюзать - не принимаются, потому что именно этим завтра-послезавтра и займусь. Сейчас не к спеху, но хочется. Также советы сменить тулкит не принимаются, на ходу коней не меняют. Заранее благодарю за возможную помощь, дамы и господа.

Собственно сабж, интересует сухие ответы, по теме. Например: аудациус виснет при импорте неutf8 .cue файлов. Или - не показывает длинну последнего трека. Вероятно не относящихся к теме сообщений избежать не получится, но хотелось бы чтобы их было меньше. Сабж интересует потому, что патчу сейчас сабж на предмет достающих меня багов. Но если вдруг вас тоже что-то достаёт, то может попутно я их тоже отловлю. Я бы сказал так - отловлю наверняка, в том случае если это не потребует переворашивать сам плеер наизнанку. К сожалению там некоторые вещи с точки зрения архитектуры сделаны через одно место.

В общем в поисках правды поддержки cue в audacious напал на две неприятности, первая в том что эта самая поддержка там говно и в зачатном состоянии, хоть блин садить да и изучай как там устроено написание плагинов... Но не об этом сабж, сабж о том, что ffmpeg существенно лагает проигрывая ape, прежде всего при перемещении. При этом перемещаясь не всегда на ту позицию на которую указано было. Ну и иногда просто пропускает куски файла, что трындецки раздражает. Я мало чего понимаю как там декодирование форматов устроено, но сам ffmpeg говорит что за декодирование ape отвечает ffape. Флак и другие форматы играют чётко, значит видимо где-то проблема в самом ffape. О всевидящий алл, где может быть касяк? На решение я и не надеюсь, но хотя бы ссыль или что-то такое, что даст возможность покопать глубже - было бы великолепно.

Сразу говорю, все варинты отсыла к другим плеерам, особенно к тем которые на Qt - идут в зад. Теперь о теме, насколько видно из поиска уже кто-то упоминиал, что cue не правильно переваривается, длинна треков берётся явно из libпотолок, хотя и титлы верно кажет. Пока я не закопался капитально в исходники и не попытался найти в чём касяк, добрые людие скажите как это фиксится или может уже пофиксили? PS: может я конечно чего-то не понимаю, но с какого перепугу gtkшный ui такой глючный и почему его пишут на чистом С, в век gtkbuilder? Неужели авторы любители веществ...

В общем при одном аргументе, mksquashfs берёт эту папку и запихивает все лежащие в ней файлы и папки прямо в корень создаваемой fs. Получается mksquashfs dir fs.squashfs dir/file fs/file

Когда аргументов 2 и более, она не разворачивает аргументы и получается так: mksquashfs dir1 dir2 fs.squashfs dir1/file fs/dir1/file dir2/file2 fs/dir2/file

Хочется чтобы вне зависимости от количества аргументов, она их содержимое обрабатывало по первому сценарию, но как?

Пишу пока на perl, скоро задействую С. Задача заключается в том, что нужно динамически добавлять некоторые виджеты в контейнеры. Всё гуи желательно держать в файлах, то есть форму главного окна, и все добавляемые потом виджеты. Желательно не городить огород и не хранить всё это в одном-двух файлах, содержащих окна, а использовать файлы для логически понятного хранения. Например: если нужно добавить динамически контейнер с виджетами, то подгружаем файл с этим контейнером и виджетами и вуаля. Собственно вопросов то несколько. - какой дизайнер позволяет создавать контейнеры не добавляя сначала окно? - glade не даёт. Я с libglale+perl проверил, если убрать из xml окно, а всё остальное оставить - работает. - а правомерно ли это вообще? То есть будет ли потом это работать в gtkbuilder+C ? Просто не хочется потом всё переиначивать.

PS: да конечно я сейчас заюзаю glade и небольшим скриптом буду удалять виджет окна, но вопрос тут скорее на перспективу, правильно ли так обходиться.

Так, ситуация такая, монтируется некоторое количество бранчей в папку. Некоторые из бранчей как водится - read only. Ну и когда что-то, находящееся на них удаляется - создаются эти самые whiteouts на writable бранчах. Так вот, всё хорошо, когда нет потребности объединить эти самые бранчи после размонтирования и создать единый образ. То есть объединить папки и несколько образов squashfs. Как следствие нужно избавиться от whiteouts, но при этом реально удалить файлы, которые были прикрыты этими whiteouts. Проблемы написать соответствующий скрипт конечно же нет, но может уже где-то такое готово? Может быть есть нечто вроде merge_branch_after_aufs brach1 branch2 brach3 и тд? Если написал задачу неясно, прошу простить. Просто в сложных конфигурациях без этого похоже не обойтись.

Написал велосипед по простой причине, заюзал тут squashfs для ....(маты) (ваши машиты) ... - для создания образа cstrike. Который потом объединил с обычным каталогом с помощью aufs2. Получилось ускорение запуска и работы, учитывая что у меня бук с 5400 винтом. Почти тоже самое планурую проделать с некоторыми другими wine программами и конечно же - portage. Так вот после того как свёл воедино свои хотелки - понял что мне нужен небольшой скриптик, который будет делать за меня грязную работу, и который будет достаточно настраиваемый, чтобы работал не только как объединитель squash образа с каталогом, но и умел бы работать с другими фс, и умел бы переделывать squash образ после того, как изменений накопилось бы много ну и тд. Первая мысль - написать, вторая мысль - пишу велосипед, ведь вряд ли этого ещё нет. Написать то напишу - но если уже есть?

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

Допустим qdbusviewer позволяет это смотреть, но читать его исходники, а дальше исходники Qt не совсем то что хочется, хотя как вариант... Нужно узнать именно средствами сишного libdbus. Может я что-то пропустил, очевидное, но на ум приходит только получить интроспекцию, но там нет полного пути нодами? Наверное просто нужно выспаться, но если кто знает точный ответ - прошу отписаться.

В общем название темы возможно слишком неточное, но в силу полного отстутсвия опыта в этой теме обозвал как мог. Поэтому чтобы пояснить что мне надо - опишу задачу:)

Условия:

-имеется вебкамера, или любой другой источник изображения и звука. Хотя звук и видео подаётся потоком, разумеется нет никаких препятствий в перекодировании в нужные кодеки или разбивку на кадры.

-имеются видео и звук, которые также можно перекодировать и разбить, но главное что нет и не может быть точного совпадения между видео с источника и этим видео, лиш часть образов может совпадать, а точнее быть похожими.

Задача:

Сопоставить первое со вторым, найти и указать места совпадения и указать процент совпадения.

Пример:

Есть две вебкамеры, с них идут видеопотоки. Есть 3и снимка лиц, допустим в jpeg. Нужно найти все места появления этих лиц в видеопотоках этих двух вебкамер. Как дополнительное задание можно проделать тоже самое со звуком.

Итого: в принципе, без звука можно обойтись, но если есть что-то для звука - то это прекрасно. Также я не ищу готового решения, но если оно есть - то это прекрасно. Вопрос же в том, есть ли некоторые "кирпичики" в свободногом доступе под кошерными gpl/lgpl или хотя бы bsd на более-менее распространённых языках. Почему более-менее распространённых, потому что всё равно придётся обёртывать дальше, и лучше чтобы можно было соединить посредством dll или допустим dbus. Впрочем подозреваю что пусть даже экзотика - главное чтобы вообще это было:) В общем если кто-то слышал о библиотеках это реализующих, законченных продуктах или уж на совсем худой конец - литературе, пожалуйста откликнитесь.

В общем интересуюсь, интересно сие, для использование на флешке, хранится в основном будет всякая текстовая информация, так что неплохо бы компрессию. Ну и обкатать reiser4 неплохо бы в этом режиме, вопрос только один - оно собирается под arm? Был у кого-нибудь опыт?