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

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

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

Сейчас речь пойдет об обязательных свойствах, и первое из этих свойств называется Id. Как несложно догадаться, это уникальный идентификатор расширения. Он имеет разный формат в разных версиях Firefox'а. В версии 1.0 это должен был быть полноценный GUID, который можно было сгенерировать, к примеру, с помощью специализированного генератора производства Microsoft (он доступен по адресу www.microsoft.com/downloads/details.asp … laylang=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/firefo … ppversions. Обратите внимание на то, что можно указывать "маски" версий вида 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

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

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

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

XUL-слои

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

Как выглядит типичный XUL-слой, можно увидеть в листинге к данной статье. В целом, думаю, данный документ не вызовет много вопросов, однако после того, как вы ознакомитесь с ним, я дам некоторые пояснения.

<?xml version="1.0"?>
<overlay id="sample"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<statusbar id="status-bar">
<statusbarpanel id="my-panel" label="Hello, World" />
</statusbar>
</overlay>

С первой строчкой, думаю, все совершенно понятно - она стандартна для всех XML-документов, и XUL-файлы, как вы сами можете убедиться, также не являются исключением из их числа. Корневой тег, overlay, дает возможность браузеру "узнать" в данном XML-файле XUL-документ. Кстати, обратите внимание на то, как именно записан URL в строке за overlay'ем. Как известно, разработчики Mozilla Firefox - те ещё шутники. Название же XUL по-английски должно произноситься примерно как "зуул" (zuul). Этот URL отсылает нас к известной комедии "Охотники за привидениями", где встречается одноименный персонаж. Фраза "There is no Dana, only Zuul" из фильма, закодированная в этом URL'е (в котором, кстати говоря, можно также увидеть ещё две отсылки к тому же фильму - "ключника" и "привратника", т.е. keymaster и gatekeeper), стала основой для девиза команды разработчиков, работающих над XUL: "There is no data, there is only XUL".

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

Тег statusbar обозначает "точку соединения" нового виджета с уже имеющимся интерфейсом. В данном случае такой точкой, как видите, является панель состояния браузера (status bar). То, что заключено внутрь данного тега - и есть, собственно говоря, виджет, который мы добавляем на нашу "точку соединения". В данном случае таким виджетом является дополнительная панель, на которой будет написано "Hello, World!".

У многих наших читателей наверняка возникнет совершенно резонный вопрос: а как же, собственно говоря, можно узнать, какие виды виджетов вообще доступны разработчику. Такой список есть на портале Mozilla для разработчиков, и располагается он по адресу https://developer.mozilla.org/en/XUL_controls. Все виджеты там расписаны более чем подробно.

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

<popup id="contentAreaContextMenu">
<menuitem id="context-item1" label="Item 1" oncommand="alert('Item1');"/>
<menuitem id="context-item2" label="Item 2" oncommand="alert('Item2');"/>
</popup>

Собственно, код этого листинга достаточно прост: мы указываем, к чему "подключаемся" - в данном случае таким компонентом браузерного интерфейса является контекстное меню. В него мы добавляем два элемента, которые будут выглядеть на экране как "Item 1" и "Item 2". При нажатии на эти элементы будет выводиться окно с сообщениями, тексты которых совпадают с названиями пунктов меню. Вполне понятно, что в реальных расширениях, добавляющих собственные пункты в контекстное меню Mozilla Firefox, вместо кода, отвечающего за отображение малоинформативных сообщений, вставляют реальный рабочий код, выполняющий реальные же задачи. Впрочем, о коде сейчас ещё говорить несколько преждевременно - мы еще не до конца разобрались с XUL'ом...

Chrome URI

Каким именно образом Firefox обнаруживает элементы интерфейса, записанные в XUL-файлах? Логично было бы предположить, что для этого используются пути к файлам, в которых содержатся XUL-слои. В общем-то, так оно и есть. Только для записи таких путей в форме URI используется не привычное всем "file://", а "chrome://".

Здесь наверняка возникнет вопрос: какое отношение этот Chrome имеет к браузеру Google Chrome? В общем-то, никакого, это, можно сказать, "однофамильцы". Дело в том, что браузеры Mozilla Firefox и Google Chrome, как вам, должно быть, известно, основываются на двух разных "движках" и имеют, соответственно, достаточно рознящееся друг от друга внутреннее устройство. Что касается названия Chrome в случае с Firefox'ом, то оно исторически появилось раньше названия гугловского браузера, но теперь вместо Mozilla Chrome говорят более емкое и короткое определение - просто XUL, которое к тому же лучше отображает сущность этой технологии. В терминологии Mozilla сейчас принято следующее определение: "Chrome is the set of user interface elements of the application window that are outside of a window's content area". То есть, в Chrome включаются все те части интерфейса, которые не содержат в себе непосредственно контента web-страницы, то есть, различные панели инструментов, меню, "прогресс-бары" и т.п.

А вообще, название Chrome не такое уж редкое в мировой ИТ-индустрии. Так называется и разработанная для платформы .NET версия языка Object Pascal, и достаточно известный игровой движок, и даже серия видеокарт от S3. Так что если вдруг придется искать название для какой-нибудь своей разработки, смело называйте её "Хромом" - все поймут и не удивятся.

Но вернемся, собственно, к Chrome URI. Каким образом они вообще выглядят и используются? А вот каким: chrome://browser/content/browser.xul. Попробуйте ввести этот URI в адресной строке Firefox, и вы увидите, что именно скрывается за этим адресом. Собственно, префикс "chrome://", с которого начинается URI, нужен, по большей части, именно для того, чтобы отделять XUL-слои от web-страниц, файлов на жестком диске, папок на FTP-сервере и т.д. За этим префиксом следует название пакета, которое должно быть, по возможности, уникальным, за этим названием идет тип ресурса. Всего разработчикам доступно три различных типа ресурсов: content (сюда входят XUL, JavaScript, XBL биндинги... - собственно, то, что является формой поведения UI приложения) locale (DTD, .properties-файлы и другие вещи, которые содержат в себе строки локализации интерфейса браузера) и skin (CSS и изображения, которые составляют часть темы UI браузера). Как видите, все эти три типа ресурсов достаточно сильно отличаются друг от друга, а потому вряд ли может возникнуть такая ситуация, когда вы спутаете случайно один с другим. Что касается дальнейшей части URI, то это, собственно, путь к ресурсу - то есть, к нашему XUL-файлу. Для преобразования Chrome URI в реальный путь к файлу на диске (в том числе и находящемуся внутри какого-либо архива) браузер использует так называемый Chrome Registry (реестр Chrome). Собственно, лично нам в данном случае нужно от Chrome Registry совсем немного - а именно, чтобы туда попали URI, которые имеют непосредственное отношение к содержимому нашего расширения для браузера.

Для этой цели в Mozilla Firefox (да и в других продуктах Mozilla) существуют специальные средства - файлы, называемые Chrome Manifest'ами. Именно в них содержится информация, которая, скажем так, способствует тому, чтобы Firefox начал адекватно использовать URI вашего расширения в Chrome Registry. Но, к сожалению, поскольку объем газетной статьи не безграничен, продолжим разговор о Chrome Manifest'ах в одном из следующих номеров "Компьютерных вестей".

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

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

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

Chrome Manifest, начало

В прошлый раз мы остановились на обсуждении Chrome Manifest - важного для каждого расширения файла. Тогда я уже рассказывал, для чего нужны эти манифесты, но сейчас, на всякий случай, напомню, что они добавляют URI нашего расширения в Chrome Registry, делая их, таким образом, доступными для браузера. Именно поэтому важно сформировать Chrome Manifest таким образом, чтобы в нем не содержалось никаких ошибок, потому что в противном случае расширение попросту не сможет правильно интегрироваться в Mozilla Firefox.

Во-первых, о названии. Называться файл должен очень и очень просто - chrome.manifest. Как видите, все логично. Во-вторых, содержание. Файл текстовый, что, собственно, объяснимо, т.к. разработчик должен писать его "руками". Как выглядит его содержимое? В целом формат Chrome Manifest достаточно сложен - вернее, имеет достаточно длинное описание, которое вряд ли целесообразно полностью приводить в данной статье, потому что мы здесь рассматриваем не все мыслимые дополнения к Mozilla Firefox, а только расширения. Поэтому в нашем случае можно ограничиться и следующей немудреной строчкой:

content sample chrome/content/

Как видите, в этой строке есть три элемента. Идущий первым по списку обозначает тип пакета Chrome. Второй есть название самого пакета. Ну, и, наконец, третий элемент - это путь к размещению файлов в пакете Chrome.

Строка, несмотря на свою простоту, содержит сразу несколько неочевидных и достаточно тонких моментов. Каких именно? Ну, во-первых, необходимым условием правильной записи является наличие слэша (/) после пути к файлам. Во-вторых, обратите внимание на регистр символов. Не случайно вся строка записана в нижнем регистре. В документации говорится о том, что записывать в нижнем регистре необходимо только название пакета, да и то для версий Firefox и Thunderbird 2.x, которые не умеют нормально работать со смешанным регистром. И, тем не менее, неспроста, надо думать, во всех примерах все строчки записываются целиком в нижнем регистре. Можно и поэкспериментировать, чтобы узнать реальные возможности использования смешанного или только верхнего регистров символов в Chrome Manifest, но лично мне кажется, что это занятие - напрасная трата времени.

Что же на самом деле записано в рассмотренной выше строке? Фактически, указывается, что файлы пакета sample (непривычно читать название пакета с маленькой буквы?) находятся в подкаталоге chrome/content/ относительно файла Chrome Manifest. Файлы со скинами и с локализациями, соответственно, должны находиться в подкаталогах chrome/skin/ и chrome/locale/.

Более подробную информацию о том, как записываются адреса пакетов и многое другое для файла Chrome Manifest, можно узнать в документе, расположенном по следующему адресу: https://developer.mozilla.org/en/Chrome_Registration. Мы же пока не прощаемся с файлом Chrome Manifest. Потому что дальше гораздо интереснее: мы будем регистрировать созданные для расширения XUL-слои.

Chrome Manifest, продолжение: регистрация XUL-слоев

В предыдущих частях серии статей о создании расширений для Mozilla Firefox мы подробно говорили о XUL и о слоях, на которые "распадается" интерфейс браузера при ближайшем рассмотрении. Слои, которые включаются в браузер путем установки расширений, должны каким-то образом регистрироваться в Mozilla Firefox, чтобы браузер их затем правильно "подхватывал" и демонстрировал на радость пользователю. Собственно говоря, для этого нужно всего лишь добавить информацию о созданных для вашего расширения XUL-слоях в создаваемый для него же файл Chrome Manifest. И сделать это очень просто.

Слои XUL добавляются в Chrome Manifest строками следующего вида:

overlay chrome://browser/content/browser.xul
chrome://sample/content/sample.xul

Как видите, и здесь строка является как бы трехкомпонентной. Но компоненты, конечно, имеют уже несколько иное значение. Первый элемент - обозначение того факта, что данная строка добавляет в интерфейс браузера новый слой. Следующий, второй по счету, это "база" для нового слоя - в данном случае этой "базой" является основное окно браузера. Третий элемент - тот XUL-файл, который планируется добавить в интерфейс данным расширением. Во время загрузки расширения содержимое sample.xul связывается с содержимым browser.xul, и пользователь видит интерфейс браузера с уже установленным в нем расширением.

Ну, хорошо, Chrome Manifest успешно записан. Что дальше? А дальше настало время несколько пристальнее взглянуть на сами расширения как таковые - из чего они вообще состоят, и что туда еще можно добавить.

Расширение как единое целое и его структура

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

Напомню, что расширение - это архив, в котором содержатся различные файлы, обеспечивающие его инсталляцию и работу (то есть, XUL-файлы и Manifest'ы, о которых мы уже говорили) и разные вспомогательные файлы, которые также нужны для работы расширения. Как это все выглядит в архиве? XPI-пакет, который и скачивает потом пользователь, может иметь достаточно сложную структуру, но в простейшем случае структура нашего архива будет выглядеть следующим образом:

/install.rdf
/components/*
/components/cmdline.js
/defaults/
/defaults/preferences/*.js
/plugins/*
/chrome.manifest
/chrome/icons/default/*
/chrome/
/chrome/content/

Фактически, то, что непосредственно отвечает за работу вашего расширения, - а это XUL-файлы и различные сопутствующие им скрипты - находится в поддиректории /chrome/content/. Соответственно, в эту папку при разработке расширения их и нужно складывать. Конечно, реальные расширения, выполняющие какую-то более-менее полезную с точки зрения пользователя работу, имеют более сложную внутреннюю структуру в силу собственной архитектурной сложности. Впрочем, мы об этом еще будем говорить немного позже, возможно, в одном из следующих выпусков "Компьютерных вестей".

Тем не менее, это вовсе не означает, что вам нужно будет самостоятельно создавать все эти папки, следить за правильностью названий и потом запаковывать все это в ZIP-архив (который и является XPI-расширением). Сгенерировать "костяк" своего будущего расширения можно с использованием чрезвычайно простого и удобного онлайн-мастера под названием Firefox/Thunderbird Extension Wizard, расположенного по адресу: ted.mielczarek.org/code/mozilla/extensionwiz. В нем вы сразу создаете "болванку", в которой содержится не только иерархия папок, но и информация о названии и версии вашего расширения, сведения о поддерживаемых версиях Mozilla Firefox и Thunderbird и даже кое-какая лицензионная информация.

Конечно, если больше нравится создавать все вручную и упаковывать WinRAR'ом, то никто вам, конечно, этого не запретит. Но, на мой взгляд, разумнее быстро сгенерировать "болванку" расширения, а освободившееся за счет такой нехилой операции время потратить на изучение чего-нибудь "продвинутого" в смысле разработки расширений.

Первое тестирование расширения

Коль скоро у нас есть сгенерированное мастером или созданное своими руками расширение, в которое мы уже что-то добавили посредством новых XUL-слоев, то можно развлечься его тестовым запуском. Возникает вполне резонный вопрос: что же для этого нужно? Оказывается, не так уж и много - достаточно немного настроить Firefox, который должен "увидеть" и "подхватить" расширение.

В каталоге с профилем Firefox (он "лежит" в Documents and Settings, ну а если вы под Linux'ом, то наверняка сами без труда найдете, где у вас профиль Firefox) нужно найти подкаталог Extensions. Если его каким-то чудом не существует, нужно создать такой подкаталог заново. Далее в нем создается пустой текстовый файл с названием, в точности повторяющим идентификатор вашего расширения (sample@example.net или что-то в том же духе). После этого в данный файл нужно записать полный путь к каталогу с вашим расширением. Путь этот, обратите внимание, обязательно должен заканчиваться слэшем (или, в случае Windows, обратным слэшем) и не должен содержать у себя в конце никаких лишних пробелов, табуляций или каких-то других символов-"невидимок". Путь, который вы указываете, должен вести не к XPI-архиву, а к "распакованному" расширению.

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

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

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

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

Казалось бы, все, что можно сказать по поводу создания дополнений к популярному браузеру со страниц газеты, уже сказано... Оказывается, все-таки сказано ещё не все. Поэтому сегодня мы говорим о JetPack - весьма интересном, с точки зрения создателя дополнений к Mozilla Firefox, инструменте.

Общие слова

Думаю, мы достаточно подробно говорили о создании расширений к Mozilla Firefox - по крайней мере, достаточно подробно, чтобы можно было сделать выводы о том, что создание таких расширений - занятие, по своей сложности в корне отличающееся от пляжного отдыха. Несмотря на существование разнообразных инструментов, которые облегчают разработку расширений и их отладку, нельзя сказать, чтобы ситуация в корне менялась. Конечно, глядя на количество существующих сейчас расширений для Mozilla Firefox (а их уже создано, скажем прямо, немало), можно придти к выводу, что эта проблема не такая уж и актуальная для сообщества разработчиков, а потому и говорить о ней столь подробно не имеет совершенно никакого смысла. На самом деле это не совсем так, и проблема имеет место быть. Это прямо и косвенно подтверждается существованием специализированного инструмента от самих разработчиков из Mozilla, призванного сделать процесс разработки расширений для Firefox (равно как, впрочем, и для других программных продуктов Mozilla) более простым и приятным для тех, кто на это отважится.

JetPack (а именно так называется инструмент, о котором мы с вами сейчас будем вести речь) появился сравнительно недавно, около года назад. Нужно сказать, что появление JetPack действительно привело к всплеску интереса со стороны разработчиков к созданию расширений для браузера Firefox, потому что этот пакет смог предоставить программные интерфейсы (API), которые для большинства разработчиков были более привычны, нежели "классические" для продуктов Mozilla технологии, такие, как XUL, о котором мы с вами не так давно говорили. Впрочем, наверное, лучше перейти к рассказу о самом пакете JetPack.

JetPack как он есть

JetPack - это SDK для разработки расширений к программным продуктам производства Mozilla, прежде всего, к браузеру Firefox. Найти этот SDK в Сети чрезвычайно просто, достаточно зайти на его официальный сайт https://jetpack.mozillalabs.com. Там можно, само собой, обнаружить и документацию по всему пакету - к слову, достаточно полную и позволяющую действительно быстро разобраться в создании расширений с его помощью. Помимо самого SDK, для разработки расширений с использованием его наиболее актуальной версии вам понадобятся Python 2.5 (или более новый) и, на выбор, рабочая версия Firefox или Thunderbird, либо же XULRunner SDK с поддержкой Gecko 1.9.2 или новее.

Первоначально в проекте JetPack разработчикам предлагался только API, который имел следующие возможности: поддержка работы со строкой статуса, табами, управление анимацией, привязка скриптов к контенту и т.д.; поддержка подключения расширяющих API внешних библиотек (например, Twitter); поддержка библиотеки jQuery; поддержка отладки расширений с использованием Firebug. С тех пор утекло уже немало воды (согласитесь, за год можно написать достаточно много программного кода, и не только написать, но и отладить, так что в том, что сегодня JetPack уже совсем другой, чем год назад, на мой взгляд, нет совершенно ничего удивительного). Сейчас JetPack SDK включает в себя поддержку написания не только расширений для Firefox, но и "отдельно стоящих" web-приложений. Помимо, собственно, библиотек, SDK также включает ряд утилит командной строки, предназначенных для упаковки разработанного программного кода в пакеты, пригодные к распространению через Интернет. И, самое главное, в SDK есть собственная IDE для разработки расширений - пока она доступна только в предварительной тестовой версии и вряд ли может быть полноценно использована для разработки расширений, да и список возможностей IDE, говоря откровенно, не слишком поражает воображение... Но, в целом, наличие специализированной IDE в состоянии активной разработки не может не радовать.

Технологии

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

Технологически JetPack дает возможность вести разработку с использованием привычных для каждого web-разработчика (ну или, во всяком случае, для подавляющего большинства) технологий, а именно - HTML, CSS и JavaScript. Правда, технологии, используемые в JetPack'е, не сказать чтобы такие уж передовые - например, из спецификации HTML 5 не поддерживается практически ничего. Что касается версии JavaScript, то её номер - 1.8.1. В общем-то, именно в программировании на JavaScript и заключается создание расширений с использованием JetPack. В отличие от "обычных" расширений Mozilla Firefox, где все, по большому счету, основывается так или иначе на XML (потому что тот же XUL - это тоже XML), в JetPack данные записываются с помощью JSON. Выглядит это таким образом, как представлено в листинге.

{
"description": "This package adds a context-menu item.",
"author": "Me (http://me.org)",
"dependencies": ["jetpack-core"]
}

Как видите, JSON делает данные достаточно прозрачными и удобными как для чтения, так и для редактирования. Конкретно приведенный фрагмент JSON-документа - это пример "заглавного" файла для пакета с расширением package.json. Давайте теперь посмотрим на код на JavaScript'е, который как раз и реализует обещанное в JSON'е добавление пункта в контекстное меню браузера. Вы можете увидеть его в листинге.

exports.main = function(options, callbacks) {
var contextMenu = require("context-menu");
// Create a new context menu item.
var menuItem = contextMenu.Item({
  label: "Search with Google",
  // A CSS selector. Matching on this selector triggers
  // the display of our context menu.
  context: "a[href]",
  // When the context menu item is clicked,
  // perform a Googlesearch for the link text.
  onClick: function (contextObj, item) {
   var anchor = contextObj.node;
   console.log("searching for " + anchor.textContent);
   var searchUrl = "http://www.google.com/search?q=" +
    anchor.textContent;
   contextObj.window.location.href = searchUrl;
  }
});
// Add the new menu item to the application's context menu.
contextMenu.add(menuItem);
};

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

Приведенная функция на JavaScript'е - это в некотором роде аналог функции main, знакомой каждому, кто хотя бы раз что-нибудь писал на Си. Как видите, начинается наша функция с того, что мы декларируем свою "причастность" к контекстному меню браузера. Затем добавляем (хотя добавим мы на самом деле его несколько ниже) в контекстное меню новый пункт путем создания нового экземпляра соответствующего объекта, который заполняем нужными свойствами, начиная с подписи пункта "Search with Google" и заканчивая обработчиком события, происходящего при клике по этому пункту меню. Что касается собственно обработчика, то, как легко увидеть, он как раз и реализует поиск с помощью Google путем формирования URL поискового запроса, начинающегося с "http://www.google.com/search?q=", и переходу по этому URL в текущем окне браузера. Ну а в самом конце осуществляем непосредственную "состыковку" этого нашего свежеиспеченного пункта меню и контекстного меню браузера.

Конечно, можно возразить, что ничего здесь нет такого, что нельзя было бы легко реализовать и с использованием XUL'а, но не будем забывать, что этот пример из разряда "Hello, world!", а реальные расширения несколько, скажем прямо, отличаются по своей сложности от этого примера. Кроме того, не будем забывать о том, что XUL нам как бы нужно учить с нуля практически каждому, кто берется за создание расширения для Firefox, в то время как в случае с JavaScript'ом и JSON'ом многие разработчики смогут работать со знакомыми технологиями, с которыми они, образно говоря, знакомы уже всю свою сознательную жизнь. И с этим нельзя не считаться.

Подводя итоги...

...можно сказать, что JetPack'у, конечно, ещё есть куда расти. И дело не только в том, что среда разработки ещё с трудом тянет даже на звание "беты", и даже не в том, что пока что сами создатели пакета предупреждают о том, что текущая версия носит статус тестовой... Просто сама библиотека недостаточно "обкатана" на большом количестве расширений, как "классическая" технология их создания на основе XUL. Ведь на её основе создано уже огромное количество самых разных расширений, а вот на основе JetPack'а, к сожалению, пока расширений разработано не так уж и много. Впрочем, все впереди, и частично даже в наших с вами в руках. Так что не бойтесь этого пакета - может быть, как раз вы сможете сделать его намного лучше, чем он есть сейчас.

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

Добрый день. У меня в браузере Mozilla firefox  24 версии настроены расширения  ну типо iMacros,Multifox и так далее... Тоесть всё замечательно работает,но когда я архивирую браузер и передаю его человеку то у него браузер устанавливается без всякиз расширений.Просто чистый браузер. Есть ли вариант над решением этой беды? СПАСИБО

Берем простенькое дополнение-переводчик: main.js - 371 строка - уровень среднего скрипта, ну немного повыше, main.xul - 10 строк. Вопросы?

А на чем писать, чтобы эти 371 строчки можно было закодить одной-двумя?