Недавно приобрел себе читалку Qumo Libro (писал об этом в Buzz'е), и был совершенно уверен, что программировать её нельзя, поскольку слово "прошивка" четко обозначало (раньше, как минимум) что-то, что заливается в ППЗУ и намертво.
И только после покупки набрел на форум сайта The-eBook.org, где обнаружилось, что писать программы для этой книжки можно, да к тому же не на какой-нибудь обрезанной Java, а на самом обычном C.
Ну, дернуло и меня этим заняться, особенно всвязи с тем, что в Libro НЕТ ШАХМАТ!! :( Но на то, чтобы подступиться к программированию, потратил кучу времени. Крупицы требуемых полезных сведений были разбросаны чуть ли не по всему форуму, и стоило большого труда всё это собрать воедино.
Между прочим, Qumo Libro программно совместима с Qumo Colibri, Digma e*, Gmini, Sibrary, и другими подобными электронными книгами, поэтому данное руководство и для вышеозначенных книг тоже должно подойти.
В общем, всвязи со всем этим, решил написать небольшую статью для тех, кто вдруг тоже купит себе читалку, совместимую с Qumo Libro, и захочет для этого девайса что-нибудь написать!
вторник, 8 февраля 2011 г.
четверг, 3 февраля 2011 г.
Отображаем число подписчиков на кнопке Google buzz
В поставляемых Google'ом кнопках подписки нет возможности отобразить текущее число подписчиков.
Решив этот минус исправить, сделал себе такую вот кнопку для желающих подписаться на мой Buzz (туда транслируется данный блог, а также пощу некоторые менее формальные сообщения):
Здесь скриншот, собственно кнопка - в правой колонке на блоге (это на всякий случай, для читателей по RSS и через Buzz). Если кто-то хочет себе такую же, в этом посте объясняю, как это сделать.
Решив этот минус исправить, сделал себе такую вот кнопку для желающих подписаться на мой Buzz (туда транслируется данный блог, а также пощу некоторые менее формальные сообщения):
Здесь скриншот, собственно кнопка - в правой колонке на блоге (это на всякий случай, для читателей по RSS и через Buzz). Если кто-то хочет себе такую же, в этом посте объясняю, как это сделать.
среда, 2 февраля 2011 г.
Пишем Wix Extension (CompilerExtension)
Насколько мне известно, WiX - это одна из наиболее развитых и продуманных XML-систем. Причем, сделано так, что этим может пользоваться даже человек. Сегодня я еще раз убедился в том, что WiX предоставляет действительно классные возможности.
Проблема
Дело в том, что у нашего продукта множество вариаций. Версии Базовый и Стандарт, различные локализации, вариации для Saas и т.д... Все это выливается в необходимость создания большого числа однотипных установщиков.
Раньше мы использовали для этого Microsoft Setup Project, однако количество багов и слабые возможности этого решения вынудили все это переделать на WiX, чем я и занялся.
В процессе переделки возникла следующая идея: раньше для каждого типа установщиков мы создавали по специальному xml-файлу конфигурации, причем эти файлы часто друг от друга не сильно отличались. Теперь же хотелось сделать так, чтобы исключить дублирование фрагментов описанных xml-файлов.
Поиск решения
Решение вроде бы напрашивалось само собой: в библиотеке WixUIExtension имеются элементы XmlFile и XmlConfig. Однако, для генерации больших файлов они не подходят. Попробовав их использовать, я выяснил, что 10 строк обычного xml с их помощью преобразуется аж в 100(!!).
Ну и конечно, XmlFile и XmlConfig не позволяют подключить интеллисенс, ведь для нашего файла конфигурации специально была создана тщательно документированная xsd-схема, благодаря чему создание и изменение файлов конфигурации было довольно удобным.
Поэтому, для активной генерации xml элементы XmlFile и XmlConfig явно не подходят. В процессе поиска альтернативного решения, я обратил внимание на Wix Extensions, и задумал написать собственный такой модуль расширения, который бы позволил максимально быстро и эффективно развертывать наш конкретный xml, и желательно, позволял бы использовать нашу же xsd-схему при его создании/изменении.
Например, это могло бы выглядеть примерно так:
И все, что внутри <DeployConfigFragment>, хотелось бы чтобы в неизменном виде развертывалось в xml-файл DeployConfig.xml.
ДА! Я согласен, что это неправильно идеологически. Лучше разделять xml разного смысла, заключая inner xml в CDATA... Однако, в этом случае мы лишаемся интеллисенса, а этого бы очень не хотелось.
В общем, в итоге именно на таком варианте я и остановился, и приступил к исследованию возможности создания WiX Extensions.
Однако, в интернете оказалось не так уж и много документации по вопросу создания WiX Extension'ов, и поэтому мне пришлось лезть в исходники WiX и WiX Contrib Project.
В общем, этом посте я детально рассмотрел процесс создания CompilerExtension расширения для WiX.
Проблема
Дело в том, что у нашего продукта множество вариаций. Версии Базовый и Стандарт, различные локализации, вариации для Saas и т.д... Все это выливается в необходимость создания большого числа однотипных установщиков.
Раньше мы использовали для этого Microsoft Setup Project, однако количество багов и слабые возможности этого решения вынудили все это переделать на WiX, чем я и занялся.
В процессе переделки возникла следующая идея: раньше для каждого типа установщиков мы создавали по специальному xml-файлу конфигурации, причем эти файлы часто друг от друга не сильно отличались. Теперь же хотелось сделать так, чтобы исключить дублирование фрагментов описанных xml-файлов.
Поиск решения
Решение вроде бы напрашивалось само собой: в библиотеке WixUIExtension имеются элементы XmlFile и XmlConfig. Однако, для генерации больших файлов они не подходят. Попробовав их использовать, я выяснил, что 10 строк обычного xml с их помощью преобразуется аж в 100(!!).
Ну и конечно, XmlFile и XmlConfig не позволяют подключить интеллисенс, ведь для нашего файла конфигурации специально была создана тщательно документированная xsd-схема, благодаря чему создание и изменение файлов конфигурации было довольно удобным.
Поэтому, для активной генерации xml элементы XmlFile и XmlConfig явно не подходят. В процессе поиска альтернативного решения, я обратил внимание на Wix Extensions, и задумал написать собственный такой модуль расширения, который бы позволил максимально быстро и эффективно развертывать наш конкретный xml, и желательно, позволял бы использовать нашу же xsd-схему при его создании/изменении.
Например, это могло бы выглядеть примерно так:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <!-- ... --> <DeployConfigFragment File="[TARGETDIR]\DeployConfig.xml" xmlns="http://www.deskwork.ru/2010/DeployConfig"> <SolutionsList> <Solution Name="Softline.Portal.Helper" Id="21e394a2-7dab-4565-aaad-2540d360daf2" Require="true" Order="0" /> <Solution Name="Softline.Portal.Libraries.MediaLibrary" Id="3b3ae4b1-26e7-4680-bd5c-db7e10de86e9" Require="true" Order="1"> <Features> <Feature Name="Softline.Portal.Libraries.MediaLibrary.Softline_MediaLibrary" Id="fcc74650-a765-48af-91f6-247d50e7a907"> <ActivateRequire>true</ActivateRequire> </Feature> </Features> </Solution> </SolutionList> </DeployConfigFragment> <!-- ... --> </Wix>
И все, что внутри <DeployConfigFragment>, хотелось бы чтобы в неизменном виде развертывалось в xml-файл DeployConfig.xml.
ДА! Я согласен, что это неправильно идеологически. Лучше разделять xml разного смысла, заключая inner xml в CDATA... Однако, в этом случае мы лишаемся интеллисенса, а этого бы очень не хотелось.
В общем, в итоге именно на таком варианте я и остановился, и приступил к исследованию возможности создания WiX Extensions.
Однако, в интернете оказалось не так уж и много документации по вопросу создания WiX Extension'ов, и поэтому мне пришлось лезть в исходники WiX и WiX Contrib Project.
В общем, этом посте я детально рассмотрел процесс создания CompilerExtension расширения для WiX.
Подписаться на:
Сообщения (Atom)