Как самому сделать любимый браузер еще лучше

Создание расширений к Mozilla Firefox

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

Изучение премудростей Install.rdf (продолжение)

Как вы, может быть, помните, в прошлый раз мы остановились на знакомстве с файлом Install.rdf, нужным для успешной установки нашего расширения в браузер. Знакомство вышло весьма поверхностным из-за того, что значительную часть статьи я посвятил технологии RDF вообще.

Сейчас речь пойдет об обязательных свойствах, и первое из этих свойств называется Id. Как несложно догадаться, это уникальный идентификатор расширения. Он имеет разный формат в разных версиях Firefox'а. В версии 1.0 это должен был быть полноценный GUID, который можно было сгенерировать, к примеру, с помощью специализированного генератора производства Microsoft (он доступен по адресу www.microsoft.com/downloads/details.aspx?familyid=94551F58-484F-4A8C-BB39-ADB270833AFC&displaylang=en). Но, начиная с версии Firefox 1.5, идентификаторы приобрели уже "человеческий вид", то есть, их можно записывать в виде "extensionname@organization.tld" (только, естественно, без кавычек и с реальными названиями расширения и его создателя). Конечно, вряд ли вам придется реализовывать в своем расширении поддержку давно не актуальной версии 1.0 "Огненного лиса", но, тем не менее, на всякий случай эту тонкость нужно иметь в виду. Выглядеть же это все должно следующим образом:

<em:id>myextension@mysite.com</em:id>
<em:id>{daf44bf7-a45e-4450-979c-91cf07434c3d}</em:id>

Что ж, с Id все более-менее ясно, поехали дальше. Следующий по списку параметр - version. В нем указывается версия расширения - обратите внимание, версия расширения, а не минимально поддерживаемая версия браузера или что-либо другое. Подробно правила именования версий изложены тут: https://developer.mozilla.org/en/Toolkit_version_format. Если же вы решите не мудрствовать лукаво, а придерживаться "классической" схемы major.minor.release.build, то никаких сложностей с указанием номера версии, по идее, возникнуть не должно. Ну а на практике это все будет выглядеть примерно следующим образом:

<em:version>2.0</em:version>
<em:version>1.0.2</em:version>
<em:version>0.4.1.2005090112</em:version>

Следующее по счету свойство, которое должно быть описано в Install Manifest'е, - это тип дополнения. Поскольку, помимо расширений, в Firefox аналогичным образом устанавливаются темы оформления и локализации браузера, то необходимо явно указать, к чему именно относится ваш пакет. Принадлежность к определенному классу надстроек обозначается соответствующим цифровым кодом - для расширений его значение равняется двум, а все остальное нас пока что не слишком интересует. Ну а вот так это будет выглядеть в RDF'е:

<em:type>2</em:type>

А вот дальше у нас на очереди будет уже более сложное свойство, которое описывает как раз совместимость конкретного расширения с конкретными версиями браузера. И не только браузера - ведь механизм, используемый для установки расширений в Mozilla Firefox, работает ничуть не худшим образом и в почтовике Thunderbird, и в "интернет-комбайне" SeaMonkey, и в календаре Sunbird, и в других программных продуктах. В общем, получается, что свойство targetApplication - едва ли не самое важное в списке всех необходимых для файла Install.rdf свойств. Обратите внимание на то, что, в отличие от рассмотренных нами выше свойств, targetApplication является составным, то есть включает в себя несколько значений, описывающих не только сам поддерживаемый данным расширением программный продукт, но и его версии. Выглядит же все это в RDF'е вот как:

<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>1.5</em:minVersion>
<em:maxVersion>3.0.*</em:maxVersion>
</Description>
</em:targetApplication>

В приведенном выше фрагменте атрибут em:id соответствует GUID'у (идентификатору) соответствующего программного продукта, em:minVersion - минимальной из поддерживаемых расширением версий этого продукта, em:maxVersion - максимально поддерживаемой версии. Полный список GUID'ов и существующих версий можно найти по адресу https://addons.mozilla.org/en-US/firefox/pages/appversions. Обратите внимание на то, что можно указывать "маски" версий вида 3.0.* и т.п. Возникает резонный вопрос: а что делать, если расширение должно поддерживать несколько продуктов сразу? Хотя мы сейчас говорим только о расширениях для Firefox, тем не менее, никто не мешает использовать их в том же SeaMonkey. Что ж, ответ на этот вопрос прост: сколько у вас есть поддерживаемых приложений, столько и нужно свойств targetApplication в Install.rdf. Кстати, еще одна тонкость: начиная с версии 1.9 движка Gecko, используемого в том числе и в Firefox, можно использовать вместо GUID'а строчку "toolkit@mozilla.org" (без кавычек, конечно же), и тогда вы избежите составления длинного списка targetApplication'ов, потому что автоматически расширение будет считаться совместимым со всеми версиями всех приложений, использующими движок указанных версий.

Ну вот мы, наконец, дошли до последнего обязательного свойства в Install.rdf. Оно называется просто - name. Это название вашего расширения, которое пользователь будет видеть при загрузке и инсталляции. Вот оно какое:

<em:name>My Extension</em:name>

Ну вот, собственно, и все обязательные для Install Manifest'а свойства. Обо всех остальных (а вы наверняка захотите включить некоторые из них в этот файл), напомню, можно узнать по адресу https://developer.mozilla.org/en/Install_Manifests.

Иконка

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

Само создание иконки - тема, выходящая далеко-далеко за рамки данной статьи. Да и не в этом, в общем-то, дело - просто не всякому разработчику хватит художественных способностей для создания действительно качественной и привлекательной внешне иконки. Что касается чисто технической стороны вопроса, то, в общем случае, иконка описывается также в Install.rdf'е, но для версий Mozilla Firefox, начиная с 3.6 (собственно, речь не столько об этом браузере этой версии, сколько о движке Gecko версии 1.9.2 или новее), вполне достаточно вложить в XPI-архив (о его комплектовании мы еще будем говорить дальше подробнее) иконку в формате PNG, имеющую название Icon.png.

XUL

Что ж, создав Install Manifest и задумавшись о необходимости поиска отражающей сущность создаваемого дополнения красивой иконки, можно перейти к главному. А главное в случае написания расширений для Mozilla Firefox - это XUL. Пусть эта аббревиатура и кажется не очень красивой, с точки зрения русскоязычного человека, именно с ней (или, вернее, с тем, что за ней скрывается) мы с вами и будем иметь дело в процессе создания расширений для "Огненного лиса".

Расшифровывается XUL как XML User Interface Language, то есть, примерно как "XML-язык пользовательского интерфейса". Фактически, XUL - это то, на чем написан сам интерфейс браузера Firefox, и, собственно, именно по этой причине XUL и приходится использовать разработчикам расширений для этого браузера. Поскольку XUL создавался именно под нужды написания кросс-платформенного браузера, то его объектная модель и общая структура во многом схожи с аналогичными для Dynamic HTML (DHTML), а потому те, кто знаком с DHTML, смогут несколько быстрее освоить и XUL. Но "несколько" - это все-таки именно несколько. Если вы помните, когда-то достаточно давно тому назад я рассказывал в "Компьютерных вестях" об HTMLayout - библиотеке, позволяющей конструировать GUI "настольных" приложений на основе HTML. В общем-то, в основе HTMLayout и XULRunner (платформы для XUL) лежит одна и та же идея, заключающаяся в том, чтобы вынести описание интерфейса в HTML или XML-файл и освободить разработчика от его ручного кодирования или жесткого "прописывания" UI в исполняемом файле.

Понять, насколько мощной и интересной платформой является XULRunner, на которой работает XUL-интерфейс, позволит пример, расположенный по адресу www.hevanet.com/acorbin/xul/top.xul. Откройте эту ссылку и скажите честно: ожидали ли вы увидеть что-нибудь подобное в браузере? Этот пример хорош тем, что можно посмотреть и исходные тексты XUL-интерфейсов, чтобы понять, в чем именно заключается сущность XUL и как все это работает на практике.

Что ж, думаю, пока что разговор о создании расширений для Mozilla Firefox придется прервать с тем, чтобы вернуться к нему через неделю, когда вы уже вволю насладитесь демонстрацией возможностей XUL.

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by