From 6ef1fa4618e08426b874529619a66adbd3d1fcf0 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:07:59 +0100 Subject: unslug ja: move --- files/ja/conflicting/mozilla/add-ons/index.html | 248 ++++++++++++ .../how_to_submit_a_patch/index.html | 55 +++ .../conflicting/mozilla/developer_guide/index.html | 143 +++++++ .../mozilla/firefox/releases/index.html | 416 +++++++++++++++++++++ 4 files changed, 862 insertions(+) create mode 100644 files/ja/conflicting/mozilla/add-ons/index.html create mode 100644 files/ja/conflicting/mozilla/developer_guide/how_to_submit_a_patch/index.html create mode 100644 files/ja/conflicting/mozilla/developer_guide/index.html create mode 100644 files/ja/conflicting/mozilla/firefox/releases/index.html (limited to 'files/ja/conflicting/mozilla') diff --git a/files/ja/conflicting/mozilla/add-ons/index.html b/files/ja/conflicting/mozilla/add-ons/index.html new file mode 100644 index 0000000000..03b01cfbdd --- /dev/null +++ b/files/ja/conflicting/mozilla/add-ons/index.html @@ -0,0 +1,248 @@ +--- +title: Building an Extension +slug: Building_an_Extension +tags: + - Add-ons + - Extensions +--- +

 

+

序章

+

このチュートリアルでは、基本的な拡張機能を作る手順を段階を追って説明していきます。まずはFirefoxのステータスバーパネルに「Hello, World!」を表示してみましょう。

+
+

注意 このチュートリアルは、Firefox 1.5 の拡張機能の作成方法です。それ以前のバージョンの作成方法については、別のチュートリアルを参照してください。

+
+

開発環境を準備する

+

拡張機能は、ZIPファイルの形式で固めて配布するか、さもなくば 拡張子がxpiのファイル（実体はZIP形式です）をバンドルします。XPIファイルの構造は下記のとおりです。

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

自作のソースをzipに固めるのにMakefileやシェルスクリプトを書きたくないのであれば、上記と同じようにファイルを配置してみるのが一番簡単です。たとえ準備ができているとしても、一度このように広げて確認してみると、Firefox 1.5 のアドオンの仕組みがずっと簡単になります。

+

それでは始めましょう。まずハードディスク上に、拡張機能用のフォルダ（例：「C:\extensions\myExtension\」や「~/extensions/myExtension/」等）を作って下さい。このフォルダの中に「chrome」という名前のフォルダを作成します。この「chrome」の中に「content」というフォルダを作成します。（UNIX系のシステムであれば、拡張機能のrootディレクトリから「mkdir -p chrome/content」と叩くだけで2つのディレクトリが作成できます。）

+

次に、あなたの拡張機能用フォルダ（root とします）に、chrome フォルダと並んで 2つの新規ファイルを作成します。1つは「chrome.manifest」で、もう1つは「install.rdf」です。

+

開発環境の準備に関するもっと多くの助言が、Mozillazine Knowledge Base にもありますので、そちらも参考にしてください。

+

インストールマニフェストを作る

+

拡張機能の root フォルダに作った install.rdf を開いて、下記のように書いて下さい。

+
<?xml version="1.0"?>
+
+<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+     xmlns:em="http://www.mozilla.org/2004/em-rdf#">
+
+  <Description about="urn:mozilla:install-manifest">
+    <em:id>sample@foo.net</em:id>
+    <em:version>1.0</em:version>
+    <em:type>2</em:type>
+
+    <!-- Target Application this extension can install into,
+         with minimum and maximum supported versions. -->
+    <em:targetApplication>
+      <Description>
+        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
+        <em:minVersion>1.0+</em:minVersion>
+        <em:maxVersion>1.5.0.*</em:maxVersion>
+      </Description>
+    </em:targetApplication>
+
+    <!-- Front End MetaData -->
+    <em:name>Sample!</em:name>
+    <em:description>A test extension</em:description>
+    <em:creator>Your Name Here</em:creator>
+    <em:homepageURL>http://www.foo.com/</em:homepageURL>
+  </Description>
+</RDF>
+
+ +

Install Manifests には必須のプロパティもオプションのプロパティも全て網羅されています。

+

ファイルを保存します。

+

XUL でブラウザを拡張する

+

Firefox のユーザインタフェースは XUL と JavaScript で書かれます。XUL はボタン、メニュー、ツールバー、ツリーといったユーザインタフェースの部品を提供するための XML の文法です。ユーザーの行動は JavaScript を使って関数のように結び付いています。

+

ブラウザを拡張するために、我々は部品を加えるか修正することでブラウザのユーザーインタフェースの一部を修正します。我々は新しい XUL DOM 要素をブラウザウインドウに挿入することによって部品を追加し、スクリプトにイベントハンドラを付加することによって修正します。

+

ブラウザは browser.xul ($FIREFOX_INSTALL_DIR/chrome/browser.jar に含まれる content/browser/browser.xul)と呼ばれる XUL ファイルに実装されています。browser.xul では、ステータスバーについてこんな風に定義されているのを見つける事ができます。

+
<statusbar id="status-bar">
+ ... <statusbarpanel>s ...
+</statusbar>
+
+

<statusbar id="status-bar"> は、XUL オーバーレイ方式のための「マージポイント」です。

+
XUL オーバレイ方式
+

XUL オーバレイ方式とは、動的に他の UI 部品を XUL ドキュメントに紐付ける方法です。XUL オーバーレイ方式は、拡張子「.xul」のファイルに XUL のかたまりを記述しておくと、「マスター」ドキュメントにあるマージポイントで紐付けて追加してくれます。これらのかたまりで部品を追加したり削除したり変更したりが可能になるのです。

+

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>
+
+

status-bar という名前の <statusbar> で、ブラウザウィンドウの中のくっつけたい「マージポイント」を指定しています。

+

<statusbarpanel> はその子要素で、マージポイントに追加したい部品です。

+

上記のサンプルコードを sample.xul という名前のファイルに書いて、先ほど作った chrome/content に保存して下さい。

+

オーバーレイを使っての部品の追加やユーザーインターフェースの修正に関する詳細は、下記を参照して下さい。

+

Chrome URIの書式

+

XUL ファイルは、 "Chrome パッケージ" と呼ばれる ユーザーインターフェースコンポーネントのかたまりの一部です。これらは「file://」といったURIではなく、「chrome://」といった URI で呼び出されます（これはプラットフォームの依存度を下げるためです）。XUL ファイルの URI を インストールされたアプリケーションに引き継ぐために、Mozillaの開発者がこの解決策を考えつきました。

+

ブラウザのウィンドウは chrome://browser/content/browser.xul です。試しにこの URL を Firefox のロケーションバーに打ち込んでみてください！

+

Chrome URI はいくつかの要素から成り立っています。

+ +

つまり、chrome://foo/skin/bar.png だと、foo テーマの skin セクションの bar.png というファイルを呼び出すのです。

+

あなたが Chrome URI を使って内容をロードするとき、 Firefox はこれらのURIを実際のディスク上のソースファイル(もしくはJARパッケージ)に変換するのに、Chromeレジストリを使用します。

+

Chrome Manifestの作成

+

Chrome Manifest に関するさらに詳細な情報と、それがサポートするプロパティについては、Chrome Manifest を参照して下さい。

+

先ほど root フォルダに chrome というディレクトリと並べて作成した chrome.manifest を開いて下さい。

+

下記の一文を追加します。

+
content     sample    chrome/content/
+
+

(最後のスラッシュ "/" を忘れない事！ さもないと、拡張機能はロードされません。)

+

注意: Firefox/Thunderbird 2 とそれ以前のバージョンでは混合/大文字をサポートしていないので、必ず小文字のパッケージ名 ("sample") を使ってください。 - {{ Bug(132183) }}

+

ここで指定しているのは、

+
    +
  1. chrome パッケージの物の種類
    2. +
  2. chrome パッケージの名前
    3. +
  3. chrome パッケージファイルの場所
    4. +
+

つまりこの行は、「chrome パッケージ名が sample」で「content ファイルが chrome/content (chrome.manifestの相対パス) にある」という事を表しているのです。

+

「content」「locale」「skin」に相当するファイルは、それぞれchrome のサブディレクトリである「content」「locale」「skin」のディレクトリ下に配置しなくてはならない事を注意してください。

+

ファイルを保存して下さい。あなたが拡張機能を入れて Firefox を起動した時に(このチュートリアルの後で)、chrome パッケージが登録されます。

+

オーバーレイの登録

+

Firefoxでオーバーレイを表示する時はいつでも、そのオーバーレイをブラウザウィンドウにマージする必要があります。ですから、 chrome.manifest ファイルに次の一文を追加して下さい。

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

これはFirefox に、「 browser.xul をロードする時に sample.xul を browser.xul にマージする」という意味です。

+

テスト

+

最初に、我々はあなたの拡張機能の存在を Firefox に伝えなくてはなりません。昔、Firefox 1.0 の頃にはこれは、あなたの拡張機能を XPI としてパッケージ化して、ユーザインタフェースを通じてそれをインストールする事を意味していました。これが実に辛い。でも、今はもっとずっと簡単です。

+
    +
  1. あなたの環境の プロファイルフォルダを開いてください。
    2. +
  2. そこにある extensions という名前のフォルダを開いて下さい。(なければ作成して下さい。)
    3. +
  3. 新しいテキストファイルを作成して、その中にあなたの機能拡張フォルダのパス（例：「C:\extensions\myExtension\」とか「~/extensions/myExtension」とか。）を書いて、そのファイルをあなたの拡張機能のIDと同じ名前（例：「sample@foo.net」）で保存して下さい。
    4. +
+

これで拡張機能のテストの準備ができました！

+

Firefoxを起動します。Firefox はあなたの拡張機能のディレクトリへのテキストリンクを検出して、そして拡張機能をインストールしてくれます。ブラウザウインドウが表示されると、ステータスバーパネルの右側でテキスト「Hello, World!」と表示されているのが見えるでしょう。

+

戻って「.xul」ファイルを修正した場合も、ファイルを閉じて Firefox を再起動すれば、その結果が反映されます。

+

These don't actually match the described extension and confuse people. -Nickolay CENTER> Image:Helloworld_tools_menu.PNG Image:Helloworld_extensions_wnd.PNG </CENTER

+

パッケージ化

+

あなたの拡張機能が動作する今、あなたは配備とインストールのためにそれをパッケージすることができます。

+

あなたの拡張機能のフォルダのコンテンツ（rootフォルダ自体を圧縮するのではなく、中身だけ）をZipで圧縮し、そのZipファイルの拡張子を「.xpi」に変更します。Windows XP ではもっと簡単で、root フォルダの下の全てのファイル・ディレクトリを選択して右クリックして、「送る」->「圧縮(zip形式)フォルダ」を選択します。これで拡張子「.zip」のファイルができます。あとはファイル名を変更すればおしまい！

+

次に「.xpi」ファイルをあなたのサーバーにアップロードして、MIMEタイプが「application/x-xpinstall」になっている事を確認して下さい。これであなたはリンクを張って、みんながダウンロードしてFirefoxにインストールする事を可能にできます。

+
addons.mozilla.org の利用
+

Mozilla Update は、あなたが無料であなたの拡張機能を配布する事ができるサイトです。あなたの拡張機能は、非常に人気が高くなっても安定的にダウンロードできるように、Mozillaのミラーサーバー上にも格納されます。Mozillaのサイトはまた、ユーザーにより容易なインストレーションを提供し、さらにあなたが新バージョンをアップロードした時には、既存のユーザーにその新バージョンを自動で提供します。さらに Mozilla Update では、ユーザーのコメントをあなたにフィードバックさせる事も可能です。あなたがあなたの拡張機能を Mozilla Update で配布する事は、強く推奨されているのです！

+

http://addons.mozilla.org/developers/|http://addons.mozilla.org/developersを訪ねて、アカウントを作って機能拡張を配布してみて下さい。

+

注意: あなたの拡張機能は、もし丁寧な説明文と動作のスクリーンショットがあれば、より早く知られて、もっとダウンロードされるでしょう。

+
拡張機能のWindowsレジストリへの登録
+

Windows では、拡張機能の情報をレジストリに登録する事ができます。これによって拡張機能は次回自動的に呼び出されてアプリケーションが起動されます。これはアプリケーションインストーラに拡張機能として容易にインテグレーションフックを加えることを許すものです。詳細はWindowsレジストリへの拡張機能の登録を参照の事。

+

XUL オーバーレイ方式の追加情報

+

UI部品をマージポイントに追加するだけでなく、XUL のかたまりをオーバーレイの中で使う事もできます。

+ +
+
+
+
+ （例：「<statusbar id="status-bar" hidden="true"/>」(ステータスバーを隠す)）
+
+
+
+ +
+
+
+
+ （例：「<statusbar id="status-bar" removeelement="true"/>」）
+
+
+
+ +
<statusbarpanel position="1" .../>
+
+<statusbarpanel insertbefore="other-id" .../>
+
+<statusbarpanel insertafter="other-id" .../>
+
+

新しいユーザーインターフェースコンポーネントの作成

+

自分で作ったウィンドウとダイアログボックスを「.xul」ファイルを分けて作ったり、UI部品を操作するためのDOMメソッドを「.js」ファイルに実装する事で、機能として提供できます。また、「.css」ファイルにスタイルを定義しておけば、色の設定など、見た目を触る事もできます。

+

XUL開発のためのもっと詳しい情報は、XULの文章を参照して下さい。

+

Defaults ファイル

+

Defaults ファイルは、拡張機能の root フォルダの下の defaults/ というフォルダにあって、ユーザーのプロファイルを後押しするのに使います。デフォルトの情報はdefaults/preferences/ の下の「.js」ファイルに格納されます。ファイルをここに置いておけば Firefoxのプリファレンスシステムが起動時に自動的に読み込んでくれますので、あなたのプログラムはプリファレンスAPIを通じてデフォルトの情報を参照する事が可能です。

+

XPCOM コンポーネント

+

Firefox は拡張機能で XPCOM コンポーネントの利用をサポートしています。ですからあなたは JavaScript や C++ で(Gecko SDKを使って) 簡単にあなたのコンポーネントを作る事ができます。

+

自作の「.js」「.dll」ファイルはcomponents/ ディレクトリに置いて下さい。そうすれば拡張機能をインストールした最初のFirefox起動時に、自動的に登録されます。

+

詳細については How to Build an XPCOM Component in Javascript および Creating XPCOM Components bookを参照してください。

+
アプリケーションコマンドラインの操作
+

カスタム XPCOMコンポーネントの可能な用途のひとつは、Firefox または Thunderbird にコマンドラインハンドラを追加することです。このテクニックを使えば、あなたの拡張機能をアプリケーションとして実行できます:

+
 firefox.exe -myapp
+
+

I should move the useful parts of this to the Command Line page. -Nickolay ファンクションを含んだコンポーネントを追加する事によって、これは実行されます。 function NSGetModule(comMgr, fileSpec) { return myAppHandlerModule; } このファンクションはFirefox 起動を起動するたびに、Firefox から呼び出されます。 #Firefox はmyAppHandlerModuleの「registerSelf()」を呼ぶことによって、 myAppHandlerModule を登録します。 #それから「getClassObject()」によって myAppHandlerModule のハンドラファクトリを入手します。 #ハンドラファクトリはその「createInstance()」を使ってハンドルを作るために使われます。 #最終的にハンドルの「handle(cmdline)」で、コマンドライン(cmdline)の 「handleFlagWithParam()」と「handleFlag()」を処理します。 詳細については、Chrome: Command Lineと forum Discussion を参照して下さい。

+

Localization (地域化)

+

複数言語をサポートするために、あなたは エンティティや文字列のバンドル を使ってコンテンツから文字列を分離するべきです。開発時にやっておけば、後から戻ってきてやるよりもずっと楽ですよ！

+

拡張機能の地域化の情報は、「locale」ディレクトリの中に格納します。例えば、サンプル機能拡張に国依存の情報を追加したい場合、ディレクトリ「chrome」(「content」ディレクトリがあるのと同じ場所です）の中に「locale」ディレクトリを作り、そこにファイル「chrome.manifest」を作成して下記の一文を記述します。

+
locale sample sampleLocale chrome/locale/
+
+

XULで地域化した属性値を与えるためには、その値を「.ent」ファイル（または「.dtd」ファイル）に記述します。これは「locale」ディレクトリに、こんな感じで書いておきます。

+
<!ENTITY  button.label     "Click Me!">
+<!ENTITY  button.accesskey "C">
+
+

そうしたら、今度はあなたが書いた XUL ドキュメントの先頭（但し "<?xml version"1.0"?>" よりは下）に下記のように書きます。

+
<!DOCTYPE window SYSTEM "chrome://packagename/locale/filename.ent">
+
+

ここで window というのは地域名 であり、XUL文書のルート要素となります。SYSTEM プロパティは、エンティティファイルへの chrome URI です。例えばサンプルの拡張機能で言うと、ルート要素はoverlayです。

+

エンティティを使うために、XUL を下記のように修正して下さい。

+
<button label="&button.label;" accesskey="&button.accesskey;"/>
+
+

Chrome レジストリは確かに指定された地域名に対応するローカリゼーションバンドルからエンティティをロードしている事が確認できましたね。

+

スクリプトの中で文字列を使う時には、「.properties」ファイルを作成して、下記の書式で１つ１行で指定します。

+
key=value
+
+

スクリプト中で値を取得するには、nsIStringBundleService/nsIStringBundleや、<stringbundle> タグを使用します。

+

ブラウザを理解する

+

ブラウザウィンドウや他のXULウィンドウの検査をするのには、DOMインスペクタを使用します。 (これはFirefoxの「標準」インストールには含まれませんので、「カスタムインストール」で再インストールして「開発者ツール」を選択すれば、ブラウザのツールメニューに「DOM Inspector」が表示されます）

+

DOMインスペクタのツールバーの左上の「ノードファインダボタン」を押してから、検査したいウィンドウのオブジェクトをクリックすると、視覚的に選択したものの情報が表示されます。この時、DOMインスペクタのDOMツリービューは、あなたがクリックしたものの所にジャンプルするでしょう。

+

DOMインスペクタの右側のパネルでマージポイントとあなたがオーバーレイから追加した要素を見つけるのにも使います。もしあなたがマージした要素が見つけられないのであれば、マスターのXULウィンドウが呼び出された(loadイベントが発行された)タイミングで、あなたのオーバーレイでスクリプト割り付けて要素を追加する必要があるかもしれません。

+

拡張機能のデバッグ

+

デバッグ用の分析ツール

+ +

printf デバッグ

+ +

さらに上のデバッグ

+ +

クイック・スタート

+

機能する簡単な拡張機能を作るために Extension Wizard オンラインツールを使えます。

+

Extension Wizard を使って作ったのと同じような Hello World 拡張機能 の一行一行の説明が another tutorial from MozillaZine Knowledge Base にあります。

diff --git a/files/ja/conflicting/mozilla/developer_guide/how_to_submit_a_patch/index.html b/files/ja/conflicting/mozilla/developer_guide/how_to_submit_a_patch/index.html new file mode 100644 index 0000000000..c4163517cb --- /dev/null +++ b/files/ja/conflicting/mozilla/developer_guide/how_to_submit_a_patch/index.html @@ -0,0 +1,55 @@ +--- +title: Hacking Mozilla +slug: Hacking_Mozilla +tags: + - Developing Mozilla +--- +

このページは、Mozilla の CVS リポジトリにプログラムコードをチェックインする方法を知りたい方のために設けられました。もしあなたが、今まで一度も Mozilla をビルドしたことがなければ、ソースコード のページを参照して、ビルドすることから始めた方がよいでしょう。そして Mozilla のハックを始めるためのガイド を調べてみてください。 +

+

パッチのライフサイクル

+

もし、パッチ作成に関心があれば、以下のガイドラインが役に立つでしょう +

+ +

もし、あなたがパッチを持っていたら、それを Bugzilla へのバグ報告に添付してください。私たちはコードレビューに大きな信頼を置いています。なので、CVS リポジトリにコードをチェックインする前に、適切な モジュールオーナー か、その同僚によるレビューを受ける必要があります。モジュールは完全には直接 Bugzilla コンポーネントに対応しません。しかし、強い相関があります。レビューを受けるには： +

+ +

いくつかのケースで、次の数日以内に返答を受け取ることが出来るでしょう。不幸にして、忙しすぎるので彼らのバグ情報すべてに追いつけていない人々もいます。なので、あなたが 1 週間以内に返事を受け取れなくて、あなたがそのパッチに (言うならば、1 年やそこらでなく) すぐに対応する価値があると考えるなら、このようなことが出来ます。 +

+ +

レビューワはあなたが取り組んでほしいあなたのパッチに対してコメントするでしょう。彼らが満足したとき、かれらはパッチをレビュー済みと印付けし、バグ (訳注：Bugzilla) で "r=<user>"と言うでしょう。 +

たいていの場合、"スーパーレビュー"として知られる追加のレベルのレビューが必要です。スーパーレビュー ドキュメントはスーパーレビューを受けるために何をすべきかについて詳しく述べています。また、スーパーレビューはパッチに変更を求めるかもしれません。彼らが満足すると、バグ (Bugzilla) の中でそう言うでしょう。 +

レビューとスーパーレビューを受けて、パッチが十分な水準に達していたら、ツリーにチェックインできます。あなたが CVS アカウントを持っていない場合、代わりにチェックインしてくれる人を探さなければなりません。これは実に簡単です。checkin-needed キーワードをバグに追加するだけです。数少ないコミッターがこのキーワードの検索を設定しており、ちょくちょく調べてはコミットされていないパッチをコミットします。通常はキーワードが追加されてから 1 ～ 2 週間のうちにはコミットされるでしょう。2 週間以上たってもコミットされない場合、IRC に行って誰かにあなたのパッチをコミットするように (そして checkin-needed が付いたバグを調べるように、それらのバグにパッチを提供した人たちも同じように待たされているでしょうから) 言ってみる価値はあるでしょう。 +

時折、ツリーはリリースを試みるために少しより厳重にロックされ、"approval" (承認) と呼ばれる第三段階がチェックインのために必要になります。それらの時期には、Tinderbox は approval が必要であると先頭でうたって注意を促します。approval を依頼するには、パッチ添付ファイルを変更して approval フラグに ? をセットしてください。もし、approval が断られた場合、リリースが行われるか、リリースへ向けての開発がブランチとなるまで、1 週間程度パッチのチェックインを待たなければなりません。 +

これらのプロセスの中で、他に問題を抱えているか、ガイドが必要なら、Gerv にメールすることです。 +

+

CVS Commit Access ルール

+

あなたがパッチでの貢献を頻繁に行って、品質の良いコードについて定評のある業績を残したとき、CVS コミット権限を得る のプロセスを始めることが出来ます。CVS コミット権限は、以下のルールが伴います。 +

もっとも重要なルールは、ビルドのプロセスに関してです。それを無視することは、多くの人々の時間を浪費することになります。図々しい違反者は、ルールに従う事に悩まされるでしょう。抵抗は無駄です。 +

+ +

Happy hacking! +

+
+

原文書の情報

+ +
+
+
+{{ languages( { "en": "en/Hacking_Mozilla" } ) }} diff --git a/files/ja/conflicting/mozilla/developer_guide/index.html b/files/ja/conflicting/mozilla/developer_guide/index.html new file mode 100644 index 0000000000..80eb0d79bc --- /dev/null +++ b/files/ja/conflicting/mozilla/developer_guide/index.html @@ -0,0 +1,143 @@ +--- +title: Mozilla Hacker's Getting Started Guide +slug: Mozilla_Hacker's_Getting_Started_Guide +tags: + - Developing Mozilla +--- +

もし、このドキュメントについて、誤りを見つけたとか、更新に貢献したいとか、セクションを追加したいとか、そういうときには Kai Engert までコンタクトを。

+

Mozilla とは？

+

Mozillaは オープンソースプロジェクトであり、クロスプラットフォームのインターネットクライアントソフトウェアを開発する組織です。ソースコードごとに定められた (MPL、NPL、GPL、LGPLが混在している) ライセンス に従う必要があるとはいえ、Mozilla がオープンソースであるために、ソースコードは誰にでも利用可能です。

+

Mozilla.org は、このプロジェクトの開発者を助けるための基盤を提供する組織の名前です。mozilla.org は Mozilla プロジェクトのための中心となる Web サイトのアドレスでもあります。

+

動機

+

Mozilla は最大規模のオープンソースプロジェクトの一つです。Mozilla は 何百万行のコードで作られています。そのため、この巨大プロジェクトに参加するのは簡単ではありません。このドキュメントの意図は、Mozilla をハックするために何に気を付けなくてはならないかについての概要を示すことにあります。このドキュメントで Mozilla プロジェクトで使われている多くの異なったテクノロジーの間の橋渡しをしようとしています。

+

私が Mozilla の内部に目を向け始めたとき、私はこのようなドキュメントがあればと願いました (^^)

+

対象者

+

このドキュメントは第一に Mozilla のどの部分かで作業できることを望む開発者のために書かれました。参加希望者は、オブジェクト指向プログラミングについて十分な理解が求められます。そして、特に、このプロジェクトで主にプログラム言語で用いられている C言語と C++ についての経験が求められます。

+

しかし、もしあなたが、例えば JavaScript と XUL UI (XUL ユーザインタフェース) だけのように、コードの一部でだけ作業することを望んでいるとしても、この文書は参考になるでしょう。

+

このドキュメントの範囲

+

このドキュメントは以下の疑問に答えようとしています。

+ +

Netscape 社はこのプロジェクトに何をすべきなのか？

+

Mozilla が創造された時、それは Netscape のものでした。ある時期に、会社としての Netscape は、会社が所有していて、他者の著作権に抵触しないソースコードの部分を公開することにしました。

+

Mozilla は完成された製品ではありませんでした。なので、Mozilla プロジェクトはたくさんのコードを新たに書かなくてはなりませんでした。それに加えて、多くの部分を書き直しました。他のコンポーネントのいくつかは維持され、拡張されました。これが、このドキュメントや、Mozilla プロジェクトについて議論するときに Netscape という単語を目にする、耳にする機会があるの理由の一つです。

+

C++ と JavaScript

+

Mozilla では幅広く使われているため、Mozilla のソースコードで JavaScript と C++ が互いにどう関係しているかを説明するのは意味のあることです。C++ はコンパイル型の言語で、JacaScript はインタプリタ型の言語です。JavaScript は Web サイトをインプリメントするのに使われるテクノロジーとして最も共通のものとして知られています。しかし、Mozilla 開発者は、Mozilla ソースコード自身を両方の言語の混合で成り立たせることを選びました。

+

Mozilla ブラウザを起動したとき、C言語 と C++ のコンポーネントがまず開始します。しかし、起動処理の速い時点で XPConnect と呼ばれるテクノロジーが実行時にインタプリタ解釈された JavaScript を使用可能に初期化します。実際、Mozilla ブラウザは、コンパイルされた C++ と、コンパイルされない JavaScriptの両方で構成されています。

+

JavaScript は、OS によって直接に実行できるようにコンパイルすることが出来ないことに注意してください。そのために、われわれは C言語と C++ をプログラムのバックエンドで使用し、JavaScript は Mozilla の内部で動作します。

+

そして、JavaScript を使用した Web ページをネットサーフするとき、その JavaScript はサンドボックス (隔離された安全地帯) の範囲内で動作し、Mozilla の内部オブジェクトにアクセスすることは出来ないことも覚えておいてください。DOM (ドキュメント・オブジェクト・モデル Document Object Model) によって露出したオブジェクトだけが アクセス可能です。

+

このドキュメントで JavaScript に言及がある時はいつでも、Mozilla 内部の機能性に寄与するテクノロジーを意味します。JavaScript は、ユーザインタフェースイベント (ユーザの操作によるブラウザの動作) の処理を行うソースコードの部分に最もよく使われています。以下のドキュメントのほとんどは、アプリケーションの C++ 部分の概観について説明します。

+

NSPR - Netscape ポータブル・ランタイム

+

Mozilla プロジェクトでのソフトウェア開発のために第一に必要なのは、例えば、特定の OS に制限されてはいけないなどのように、クロスプラットフォームであることです。

+

C++ がポータブルな言語を意図している一方、そのポータブル性の概観は、一般的なプログラミングロジックとデータ構造に限られます。もし、特定の OS のためのソフトウェアを書きたいならば、その OS の特有の機能を使う必要があります。しばしば、すべての OS 上で同じ機能を使いたくなりますが、それをするためにはプラットフォーム毎に特有のコードを書かなくてはなりません。

+

NSPR の意図するところは、OS と Mozilla ソースコードの間に、Mozilla ソースコードの他のエリアのコードをシンプルにしやすくするためのレイヤー (層) を提供することです。C言語のライブラリ関数を利用しようとするとき、まずはクロスプラットフォームなインプリメントのものが NSPR により提供されていないかチェックすることが必要です。

+

スレッド

+

Mozilla はマルチスレッドアプリケーションです。Mozilla のコードにトライするまえに、それが何を意味するかを知る必要があります。

+

NSPR はマルチスレッドプログラムのための OS 非依存の機能を提供しています。例えば、すべてのネットワークデータ転送はデータ転送をしている間にも、ユーザインタフェースが応答可能なままとするために、スレッドごとに行われます。

+

C++ コードのために必要なことの一つは、マルチスレッド対応 (スレッドセーフ) であることです。

+

オブジェクト指向プログラミング & モジュール化

+

Mozilla の C++ ソースコードは、OOP (オブジェクト指向プログラミング) のルールに従うことを意図しています。そのルールには、モジュール化コンポーネント設計も含まれており、そこでは、あなたのクラスの public なインターフェースを使用した場合のみ、内部データ (変数) に対するアクセスが許可される、あるいは可能になります。

+

たいていのシンプルな C++ プロジェクトにおいて、これはそれだけの意味です。クラスを適切に public/protected/private を使い分けるのには注意深くデザインするというだけの意味です。しかし、すべてのソースコードはどこでも利用可能な状態のままです。例えば、いつでも、クラスのコンポーネントを private から public へ変更することが出来ます。そうすると、それはプロジェクトの中の他の箇所から利用可能となります。これは、Mozilla には当てはまりません。Mozilla では、よりモジュール化することが望まれます。

+

Mozilla のソースコードは分離されたコンポーネントで組織されています。一つのコンポーネントの中に限れば、前段落に記した単純なプロジェクトのように、すべてが自由ですが、複数のコンポーネント間においては、同じレベルの柔軟性はありません。

+

コンポーネント同士が通信するとき、コンポーネント・オブジェクト・モデル (COM component object model) を使ったうまく定義されたインタフェースだけを使って行います。

+

インタフェース

+

インタフェースのコンセプトは、CORBA テクノロジーで使われているもののようなものです。例えば、CORBA も Mozilla もインタフェースを記述するのに XPIDL (IDL とはインタフェース定義言語を意味します Interface Definition Language) という同様の言語を用いています。

+

CORBA 環境を使用する事は、制限が多く難しいものです。なぜならば、Mozilla では頻繁には用いないようなプロセス間、ネットワーク間通信を伴うためです。正式に流通している CORBA 環境ではインタフェースのコンポーネントを変更するのは同時にしばしば実行しているシステムすべてを入れ替えることが出来ないために困難です。何か変更を加えたいとき、新しいバージョンのインタフェースを定義しなくてはなりません。しかし、前のバージョンのサポートも続けることが求められます。

+

Mozilla は本稿執筆時点において正式に流通しているアプリケーションではないので、現在のところ多くのインタフェースは開発プロセスの必要に応じて変更することが可能です。しかし、Mozilla ブラウザはいくつかの環境に埋め込まれて実行されるので、それらの環境は確定したインタフェースを信頼できなくてはなりません。したがって、インタフェースは凍結されることができます。この状況は、しばしば、インターフェースが定義されている状態で表されます。時間の経過とともに Mozilla が安定化する、または、魔法のパージョン番号 1.0 に近づくにつれ、凍結されていないインタフェースに対する凍結されているものの割合は増えるでしょう。

+

Mozilla ビルドする一つのステップは、インタフェース定義ファイルを自動的に C言語 /C++ ヘッダファイルに翻訳することです。これは Mozilla の持つ IDL コンパイラである xipdl の仕事です。

+

メソッドとメンバデータに加えて、インタフェースは追加の属性を持っています。インタフェースは UUID というインタフェースごとに唯一に識別可能な番号を持っています。インタフェースはスクリプト記述可能な属性を持つことが出来ます。これは、インタフェースに JavaScript のコードからもアクセス可能であるということです。スクリプト記述可能なインタフェースは JavaScript ランタイムの範囲内で有効なパラメータのためのデータタイプを使うためだけに限定されています。

+

XPCOM / nsISupports / nsCOMPtr

+

XPCOM は Mozilla 自身の COM (コンポーネント・オブジェクト・モデル component object model) のインプリメンテーションです。名前の頭につく XP は、それがクロスプラットフォームであることを意味します (この XP がつくということを、特定の OS 製品のためのように見えるので、XP のつくこの名前で混乱しないこと)。実際のところ、クロスプラットフォームであるので、XPCOM は、他の形の COM より、用途は広いです。

+

最終的には、mozilla.org にある紹介ドキュメント XPCOM を読むべきでしょう。ハックを始めるためには、XPCOM は COM のコンセプトを働かすエンジンだということができます。これは、オブジェクト仲介人の役割を演じることも含まれています。

+

一般に、インタフェースはジョブを行うために使われることのできるオブジェクトを記述します。もし、しなければならないジョブがあるなら、インタフェースで提供される インプリメントをリクエストする必要があります。そのインプリメントは他のコンポーネントの範囲内に属することが出来ます。あなたの望む特定のインプリメントに決定するために、テキストベースの識別子である規約 ID を利用しています。規約 ID は、細部まで定義されたインターフェースを使用することで利用しやすくなる、インプリメントの動作上の契約です。XPCOM ランタイムシステムは、どのクラスが規約 ID でインプリメントされているか、どのコンポーネントがそれを提供しているかを知っています。

+

たとえ、あなたのコードが単独のコンポーネント内だけのものであり、COM の使用が必要条件ではないとしても、COM はいずれにせよとてもしばしば使われます。一つの理由は柔軟さにあります。他の理由として、JavaScript を利用してインプリメントされた Mozilla のロジックのある部分と機能を共有することを許すためです。Mozilla は実行時にインタプリタ言語の JavaScript と コンパイル言語の C++ の間でコミュニケーション可能とする XPConnect と呼ばれる技術を提供しています。

+

実行時に COM オブジェクトのインスタンスが必要なときにはいつでも、クラスオブジェクトは作成され、インタフェースのポインタが与えられます。いくつかの理由でこれらのインスタンスが参照をカウントされることが決められました。一つの理由は効率です。そのために、オブジェクトの不要なコピーは省かれるべきです。他の理由は、データオブジェクトはスレッド間で渡されるべきですが、すべてがメモリ上の同じデータオブジェクトに対するポインタを維持するためです。だからです。最後に、同じデータオブジェクトは多数のコンポーネントに参照されたり、多数のリストに貯えられたりすべきだからです。

+

参照の生存期間は異なるため、どのくらいしばしば現在何かに参照されているという状態であるか覚えておくためには、それぞれのオブジェクトが参照のカウントを保持するのが最も簡単な方法です。オブジェクトから参照されたとき (XPCOM エンジンによる直接参照もしくは、関数呼び出しによって)、リファレンスのカウントのケアを確実にする必要があります。オブジェクトへの参照を維持するかどうかや、参照を終えられるかどうかを教え、参照を削除しなくてはなりません。そのように、オブジェクトはそれがまだ必要とされているかどうかを自分自身で判断することが出来ます。オブジェクトがもう不要なら、自分自身でメモリから削除します。

+

この一般的な機能を満たすために、インタフェースをインプリメントする Mozilla のすべてのクラスは参照カウント機能と自動破棄機能を備えた nsISupports という共通基礎クラスを共有しています。このような共通基礎クラスは、どんな COM のインプリメントにも存在します。

+

あなたが割り当てたものは、あなたが掃除 (削除) しなければならない、という一般的なルールがあります。例えば、参照を追加したいとき、もう不要となったときすぐさま参照を解放することを強く促します。そうしなければメモリリークといった問題を引き起こすことになるでしょう。

+

C++ では、nsISupports 基本クラスのメソッドの明白なメソッド呼び出しによって行われます。しかし、それらのメソッド呼び出しは、忘れやすいだけでなく、コードの可読性も低下させます。特に多くの関数やメソッドは複数の出口を持っているからです (例：return 文など)。

+

関数やメソッドの出口毎にすべてのオブジェクトへの参照を解放することを確実にしなければなりません。これを楽にするために、解放の呼び出しを繰り返さなくて良いために、一般的な補助クラスは nsCOMPtr という名前の COM オブジェクトへのポインタを扱うために提供されています。これは XPCOM の特徴の一つで、COM コーディングをより楽にします。これは、特定のオペレータのオーバーライドを通してポインタをシミュレートします。いくつかの例外的ケースがありうるにも関わらず、このような一般的なルールはほとんどすべてのコードで守られています。：ポインタ変数 "interface*" をインタフェースをインプリメントしたオブジェクトとして使うつもりがあるときにはいつでもローカル "nsCOMPtr<interface>" 変数をかわりに使う。このポインタが "スコープ範囲外" となったらすぐに、可能ならデストラクタが自動的に参照カウントを減らします。

+

インタプリタ言語の JavaScript では、これはコード上で簡単に行えます。それは、ガベージコレクションのためです。可能なときに参照を自動的に減少させる魔法があるのです。しかし、この魔法は循環参照しないことを必要とします。例えば、もし、二つのオブジェクトがあり、お互いへの参照を含んでいても、他のオブジェクトがそれらを参照していないとき、それらのオブジェクトは検出されません。それらのオブジェクトはプログラム実行の残りの間メモリに存在しつづけます。

+

例外 / nsresult

+

コード実行が実行時に失敗することもあります。失敗を扱うプログラミングメカニズムが例外 (エクセプション) を用いることです。Mozilla では JavaScript 部分で例外を使っており、C++ 部分では使っていません。以前やったことがスタックの中にあるため、例外はいつでもポータブルというわけではないというのが、そのいくつかの理由のうちの一つです。Mozilla の C++ のコードは戻り値で例外を真似ています。つまり、JavaScript の中では、tyr-catch のブロックを使うことが出来、C++ の中では、インタフェースのメソッドを使う場合はいつでも戻り値を見なくてはなりません。その戻り値は nsresult 型です。このため、IDL ファイルで定義されている論理的な戻り値型は、C++ コードの中の追加のメソッドのパラメータにマッピングされています。

+

nsresult 型は、失敗理由の付加情報も運ぶことを意図しています。成功か失敗かという単純なレポートの代わりに、整数型を使い、多くの異なったエラーコードを定義することを許しています。

+

いくつかの戻り値があります。例えば、NS_OK は、何事もうまくいっていて、そのままプログラムを続けることが出来るという場合に使われ、NS_ERROR_FAILURE は、何か異常が発生しているけれども、今のところそれ以上の詳細は必要ないといった場合に使われます。

+

それに加え、互いのコンポーネントはアプリケーションの他のエリアで使用していない失敗コードを上書きしないエラーコードの定義をするために、独自の範囲の整数をリクエストすることが出来ます。詳細な情報は mozilla/xpcom/base/nsError.h を参照のこと。

+

C++ における文字列

+

多くのアプリケーションやクラスライブラリでは、単なる簡単な string (文字列) クラスを使用することを決めている中で、Mozilla 開発者は、文字列により強力な機能を求めました。実行時の動的な振る舞いを異なったシチュエーションのために最適化することを許すために、いくつかの文字列クラス階層をインプリメントしました。時には文字列のサイズを変更するだけでしょうし、時には、自動的にサイズが大きくなる文字列が必要でしょう。そのため、たとえば、ただの平坦な文字列ではなく、断片化された文字列型も使用可能です。

+

さらなる要求としては、Mozilla は完全な多言語対応をしなくてはならないということです。ユーザにみせる情報を扱う文字列は、そのためにマルチバイトな Unicode 文字列を使っています。

+

文字列型はテンプレートに基づき、可変型のような文字列型を伴い、通常文字列と Unicode 文字列を使うのを同じロジックで扱えるようにしています。

+

多くの文字列クラスを持つというアプローチは多くの柔軟性を意味する一方、欠点としてMozilla の文字列クラスを学ぶのが易しい作業ではなくなる、ということがあります

+

GUI (グラフィカル・ユーザ・インタフェース) / XUL

+

たいていの OS では、GUI を開発するための独自の方法を定義していて、それぞれたいてい異なっています。

+

Mozilla のようなクロスプラットフォームアプリケーションにとっては、アプリケーションのロジックから OS 依存のロジックを隠すテクノロジーをもつということは、重大なことです。

+

今までに、多くの C 言語と C++ のライブラリはクロスプラットフォームに書かれてきました。私の知るところによると、それらは Mozilla には使われていません。またしても、独自のグラフィックシステムを作りました。

+

GUI のレイアウトを定義するとき、二つの可能性のいずれかを共にするかを選ぶことが出来ます。まず、表示させたいそれぞれの UI (ユーザ・インタフェース： user interface) 要素の絶対位置を定義する方法があります。この方法は、実際に多くの GUI ライブラリで選ばれています。しかし、これには欠点があります。エレメントが加わってレイアウトが変わったとき、十分な柔軟性がないことです。それは、すべての要素を新しい位置に計算し直す必要があるからです。それは、どのエレメントが重なっているかなどのフィードバックをいちはやく得るために、よりグラフィカルにしなくてはなりません。しかし、いまだ、UI は異なるメトリクスをもつフォントが使われなくてはならないとき、意図したように見えないかもしれません。このことは、UI が使い物にならないと判断させます。

+

Mozilla の開発者は、より柔軟性のあるものを求めました。Mozilla はクロスプラットフォームなので、フォントにより注意を払う柔軟性を備えることが必要です。

+

Mozilla 開発者は、論理的なもので UI のコンテンツがデザインされたところというアプローチを使うことを選びました。現在は UI エディタを使っていません。UI がどうみえるべきかを指示するファイルを書きました。実行時にレイアウトエンジンはどのフォントが利用可能か決定し、UI 詳細に定義されたすべての要求を考慮し、実際の UI を動的に生成します。これは、Web ブラウザが Web ページをどのように表示するかと似ています。

+

Web は大部分がテキストベースのシステムから多くのプログラムのようなユーザインタフェースをもつとてもグラフィカルで裕福な環境へ移り変わってきました。そのため、Web ブラウザにとって、独自のユーザインタフェースを定義するために Web 言語を使うことはもっとも自然なことです。XUL(extensible user-interface language 拡張ユーザインタフェース言語) と呼ばれる UI 内容の記述のための XML ベースの文法を選びました (XUL についての良いリファレンスとして XULPlanet が利用できます)。

+

XUL ファイルは、どの要素が UI を構成しているか、どこに要素が現れているかを記述します。XUL 言語は制御に反応してどういう働きがあるかをプログラマが定義することを許す属性を定義します。動的なアプリケーションのふるまいを定義するために、ある場合には特定のユーザインタフェースイベントが発生したときに呼ばれる JavaScript 関数を定義することが出来ます。それらの JavaScript 関数の中では、直接アプリケーションのふるまいを記述するか C++ で定義されたロジックを含む COM オブジェクトの利用可能な他のアプリケーションロジックを呼び出すかすることが出来ます。

+

UI の論理的表現に加え、人々は UI のかわいらしい見た目を望んだりもします。UI の詳細な特徴を定義するために、例えば特定の UI 要素を表示するのに使われる画像を定義する CSS を使うこともあります。これは、"テーマ"や"スキン"を参照するアプリケーションのための追加の"ルックス"の定義を柔軟にします。Mozilla には、現在 Mozilla 開発者によって活発にメンテナンスされている「クラシック」と「モダン」という２つの「テーマ」が定義されています。Mozilla のための追加のテーマが存在するということは、それだけのバージョンの Mozilla が存在するということです。UI に毎日起こるすべての変化に同期をとりつづけることは、「テーマ」のデザイナにとって大きな仕事です。

+

ビルドシステムとツリー

+

現在、Mozilla は主に実行時に必要に応じて動的にロードされた多くの共有ライブラリの集まりのように使われています。COM システムによって、ソースコードの複数の場所を変更した場合でも、再コンパイルする必要があるのはアプリケーションの一部だけで良い場合が多い、という開発環境が可能となっています。これは、とても便利な開発環境です。しかし、これは実行の速度低下を意味します。一方、内部コンポーネントの大部分を静的にリンクした Mozilla バイナリを作ることも可能です。アプリケーションのサイズのため、このリンクステップには多くの時間がかかります。ディストリビューション向けのパッケージを準備するときに、この意味が良くわかるでしょう。

+

それぞれのコンポーネントはその独自のディレクトリを Mozilla のルートディレクトリの中に持ちます。それはまた、呼び出したモジュールの範囲内でサブのコンポーネントを持つということです。Mozilla をどのようにビルドするか教えるツリーの全体にわたるメイクファイル (Make File) があります。

+

プラットフォーム依存のコードのほとんどは、ツリーの少しの場所にだけ含まれます。OS と Mozilla の他のコードの間にあるレイヤーはこのコードによってインプリメントされたインタフェースです。ビルドが発生するものの中のプラットフォームを準備するプラットフォーム依存のコードだけがビルドされます。

+

OS からのメッセージはプラットフォーム依存のコードによって集められています。そして、同じ方法でプラットフォームに独立したコードへ送られます。

+

Mozilla プロジェクトに関する部品はプラットフォーム依存のレンダリング技術を使って書かれた OS 独立の部品です。

+

ツリーの範囲内で、public と名づけられたディレクトリはたいていインタフェースのヘッダを含み、src と名づけられたディレクトリはたいていインタフェースのインプリメントやインタフェースのヘッダでないものを含みます。

+

このプログラムのビルドはこのように大きなプロジェクトに慣れない人をひるませるかもしれません。ビルドには、パワフルなワークステーションで 20 分、古い PC なら 2 時間はかかるでしょう。まず、ソースを入手しなくてはなりません。そして、ビルド資料 に含まれるルールを使ってそれをビルドします。ビルドしている間、ヘッダファイルのディレクトリを特に指定する必要がないように、すべてのヘッダファイルは dist/include ディレクトリに移動するでしょう。(集合としては chrome と呼ばれる) XUL 、画像、JavaScript ファイルもすべて chrome ディレクトリ (Mozilla のバイナリを含むディレクトリの子ディレクトリ) にコピーされるでしょう。これらは jar.mn と呼ばれるファイルの中で定義される chrome:// という URL にマッピングされます。Mozilla のリリースバージョンでは、chrome ディレクトリは、.jar ファイルだけが含まれるでしょう。

+

Mozilla をビルドするというのは、プロセスの一部に過ぎません。もし、開発したければ、CVS と呼ばれるプログラムを使ったツリーのメンテナンスをしなくてはなりません。ビルドに失敗した時には、あなたのツリーの中のファイルとレポジトリの中のファイルとの結合が失敗した際に生じた競合を解消しなくてはなりません。また、ツリーをハックするとき、修正したツリーの部分をビルドしなくてはなりません。時折、depending と呼ばれるプロセスを使ってツリー全体を再ビルドしなくてはならないでしょう。ソースファイル間の依存を決定しなくてはならないからです。また、時折、ツリーを再ビルドするでしょう。たいていは、これをしている間、ツリーへの自身の行った変更をメンテナンスしていて、他人の変更と同期をとろうとしているでしょう。

+

アプリケーションの開始

+

Mozilla の COM システムは、タイプライブラリと、実行可能なコンポーネントの内部レジストリと、インタフェースに頼っています。アプリケーションを開始している間、レジストリが今も最新のものかのチェックが行われます。もし、変更されたライブラリを検知したとき、レジストリは更新されます。それぞれのコンポーネントはそのレジストレーションフェーズの間に初期化を行うことが許されます。もし、変更されたライブラリを検知したとき、それらはロードされ、初期化ロジックが実行されます。変更ライブラリに加え、それらのアプリケーションコンポーネントだけが必要とされたようにロードされます。

+

内部通知システム

+

このセクションでは Mozilla 内部で利用可能な機構について記述します。めったにこれは必要になりません。しかし、特定のイベントに対処する必要のある時には、このシステムを知ることが助けとなるでしょう。OOP (オブジェクト指向プログラミング) の考え方は、各々が各々自身の役割を果たすことというものです。しかし、それはしばしば他のコンポーネントがコンポーネント B で起きたあるアクションの引き金を引くとき、コンポーネント A がそれに対応しなくてはなりません。しかし、コードは部分で分離されているほうが好ましいため、B はそれを起こすのに何が必要かの詳細を知るべきではないのです。ここで必要なのは、次のような事です。もし、他のコンポーネントが B のアクションに反応する必要があるのであれば、B はそのアクションに対する引き金が引かれたら通知を送信するように拡張されるべきです。それに加え、B は誰が通知されるのを待っているか覚えているリストを実行時に動的に保持します。実行時に、A が初期化されたとき、A は B に通知リストの対象に加えてほしいと告知します。

+

これをより一般化するため、中央観察サービス (central observer service) を使うことを決めました。コンポーネント B がアクションの引き金を引いたとき、観察サービスにすぐに通知し、記述的にイベントの名前を明確にします。A のようなコンポーネントは観察サービスに観察したいイベントの名前をもらえるよう申請します。その原則を使用し、観察サービスだけがイベントを見るコンポーネントのリストを扱わなくてはなりません。観察サービスはイベントの通知を受けると、その通知を、そのイベントへのすべてのコンポーネントリストに引き渡します。詳細は nsIObserver を参照のこと。

+

ローカライゼーション

+

Mozilla は人間の言語からコードを分離するデザインがされています。ユーザに見せる必要があるためにテキスト文字列が必要なときはいつでも JavaScript や C++ ファイルの中に直接文字列を保存することは許されません。かわりに、C++ や JavaScript のコードで使われるテキストのために記述的識別子を定義します。その識別子をキーとして使い、実際のテキストを取り出すための文字列集合インタフェースのメンバーを呼び出します。テキスト自身はテキストだけ格納された分離されたファイルに格納されます。Mozilla はモジュールの集合であるため、多くのファイルがあり、分離されたモジュールにそれぞれ所属します。その分離にともなって、翻訳者がテキストファイルの言語別バージョンを作るのが簡単なのです。

+

UI を定義するとき、2 種類の文字列があります。ある文字列は、入力フィールドのテキストやヘルプの中にだけ出てくるテキストのようにアプリケーションがコンパイルされ、パッケージ化されたその時に知られるもので、またある文字列は、実行時に動的に組み立てられます。

+

実行時にアクセスされる必要のないテキストを定義するときはいつでも、DTD ファイルの中に定義してください。XUL ファイルの中でそのテキストを直接参照することが出来ます。

+

実行時にテキストを伴った動作が必要なとき、例えばテキストが実行時に入力される必要のあるユーザ名のための代替文字列を含むとき、properties ファイルにテキストを定義してください。

+

コーディングとレビューのルール

+

Mozilla ダウンロード、コードの変更、独自の変更を含むバージョンでの作業などがフリーで行えます。

+

しかし、Mozilla で使われているオープンソースの背後にある一つの考え方に次のようなものがあります。ソースをフリーで入手できるかわりに、ソースに変更を加えたら、コミュニティに何がしかの還元を考えるべきです。そうすることにより、貢献者となるのです。

+

しかし、Mozilla コミュニティは公開の中央 Mozilla コードに組み込まれるという変更をただ受け入れることは出来ないと決定しました。自分のコードをその中の一部にしたければ、次のようなルールに従わなければなりません。それは法律のようなものではありません。しかし、基本的に、あなたは、あなたの変更が良いものであると他の人々が認めるよう説得しなければなりません。

+

この考え方は、Mozilla のコードをより正しい状態にするために作られた多くの効果があります。Mozilla のコードはどのソフトウェアの一部と同様に、完璧からはほど遠く、人々は保守性を低下させるものは何でも取り除こうとし、正しいと思われるコードだけを受け入れます。

+

これを達成するために、Mozilla コミュニティはすべてのコードは他のすでによく知られた Mozilla ハッカーたちに受け入れられる必要があると決めました。ここに２つの段階のレビューがあります。まず、コード変更希望者は、変更したいコードの部分の所有者から最初のレビュー (r=) を受ける必要があります。要求された修正を行うことが期待されます。そうでなければここで終わりです。もし、最初のレビューが終われば、たいていの場合スーパーレビュー (sr=) と呼ばれるレビューを受ける必要があります。限られたメンバーである " Mozilla 導師 " という、どのコードがよく、どこを変更するべきかについての判断が優れていると認められている人々がいます。一度、両方のレビューを受ければ、ほとんどの場合、コードはチェックインされます。ある特定の事例では、他のレベルのレビューがあり、それは別の場所に記述されます。

+

多くの人々が Mozilla を変えています。みんなが Mozilla をよりよくしようとする一方、どの変更も思いがけない面への影響というリスクがあります。これは、変更の結果、アプリケーションの機能が動かなくなるといったものから、Mozilla ソースコードがコンパイルできなくなるといった単純な問題にまで及びます。後者は、"ツリーが壊れている、燃え上がっている、赤い"と表現され、ここでツリーとは CVS リポジトリの事です。

+

ある OS とコンパイラの組み合わせの上でだけ開発をしていて、移植性について (Mozilla.org のドキュメント参照のこと) 注意を払っていないとき、ツリーは簡単に壊れてしまいます。ツリーを壊さないためにベストを尽くす必要があり、レビューを受けることで、願わくば、変更点をチェックインするより早く潜在的な問題を発見したいのです。

+

ツリーが壊れてしまったとき、Mozilla コミュニティは、ツリーが壊れている間ほかのチェックインを許さないというルールを決定します。これは、この問題を修正する人を助けます。ほかの変更を許すことは、新しいチェックインがあたらしい問題を含んでいるかもしれないために、問題のほんとうの原因を見つけることを難しくします。

+

マイルストーン

+

数週間ごとに、Mozilla.org はソースレポジトリの新しいスナップショットを出します。この考え方は、世界の人々が現在のスナップショットを試してみて、彼らの見つけた問題 (バグ) を報告すべきだというものです。しかし、Mozilla.org はそれらのマイルストーンはテスト目的だけのために出されたということを強調したいのです。

+

より安定したマイルストーンを準備するために、ソースコードレポジトリを変更するためのルールは、新しいマイルストーンを準備する前にはより厳格なものになります。Mozilla.org は、スケジュールを引き、マイルストーン目標日の前の２日間、Mozilla.org の"ドライバ"と呼ばれる人たちに認可されたチェックインだけが許されます。ドライバは、Mozilla レポジトリに関して、最高の権限をもっている人の集団です。ドライバはまた、マイルストーンが準備できているのか、よりマイルストーンを安定させるためにマイルストーンを出すためより多くの修正を許すために日程を遅らせるかどうかも決定します。

+

Bugzilla

+

Bugzilla は Mozilla.org の Web ベースのバグ追跡システムです。問題に遭遇したときはいつでも、ユーザは新しいバグ (時には問題に切符を切ることとして知られてもいます) を、よく詳細に何が起こったかとともに申し立てるよう依頼されます。バグが公表されるなり、番号を発給するなりします。この番号は問題について話されるときに使われます。開発者は"バグ"について署名し、コメントします。そして、修正方法を知っていればどのように問題の修正方法を提案するかを見せるために、パッチを添付するでしょう。レビューも、このシステムの内部で進みます。

+

バグという単語はしばしばソフトウェアのエラーという意味にみなされます。しかし、Bugzilla の内部では、バグは追跡されるべきものとなります。これはソフトウェアのエラーから、機能拡張のリクエストに及びます。例えば、このドキュメントの発展は {{ Bug(123230) }} で追跡されています。

+

もし、C++ の開発者でないなら、Bugzilla で貢献できます。これは、簡単なバグ報告ツールとして出発し、ほかのプロジェクト (例えば Redhat のような) まで多くのユーザに使われる機能的な複雑なシステムにすっかり変わりました。

+

Webtools / LXR / Bonsai

+

Webtools は情報を貯えるツールをベースとしたサーバで、その情報を表示されることやときに操作することまで許します。そのシステムには Mozilla のように Web ブラウザを使ってアクセスできます。

+

Mozilla 開発者は開発を容易にするためにいくつかのツールを作りました。すでにお話した Bugzilla もそうです。

+

LXR は Mozilla のソースコードのためのハイパーテキスト検索エンジンです。識別子やテキストを調べることが出来、Mozilla の中のどこでそれが使われているかを見られるでしょう。検索結果項目をクリックすることで、直接現在のソースコードが得られます。コードはページに表示され、識別子にはハイパーリンクがはられ、それはクリックすると、その識別子についての LXR 検索結果を得られます。LXR はソースコードを表示し、それを通してすぐにナビゲートするのに使うことが出来ます。これは、Linux プロジェクトの glimpse のエンジンに内部修正を加えたものをベースにしています。

+

Tinderbox はソースコードレポジトリの現在の状況を表示するツールです。Mozilla.org は、多くの異なった OS のために、繰り返し、絶え間なく中央レポジトリから新しいソースコードを手に入れ (チェックアウトし)、コンパイルを試みるマシンをホストしています。コンパイルが終わったとき、プログラムがまだ正しく動作するかをチェックするためのいくつかの自動テストが実行されます。コンパイルとテストの結果は中央の Tinderbox システムにレポートされます。Tinderbox ページにアクセスすると、ソースコードレポジトリが現在いい状態にあるかどうかこの数時間の間にどんな変化があったのかを見ることが出来ます。Tinderbox は縦軸が時間を示し、横軸が OS ごとの状態を示すグラフを表示します。それぞれのコンパイル・テストフェーズはビルドの要求された時間で定義されたバーで表されます。

+

バーは色付けられています。緑は Good を示します。黄色はコンパイル中であることを示します。オレンジはコンパイルとビルドが終わったけれども自動テストに失敗したことを示します。赤はソースコードのコンパイルが成功していないことを示します。もしツリーが赤になると、開発を停滞させます。

+

Tinderbox はとても有用なツールで、ソースコードレポジトリに変更を加える人は誰でも、例えば、自分の変更がなにか問題を起こしていないかのような"ツリーを見る" ことを期待できます。

+

より援助とするため、追加の情報が Tinderbox ページで利用できます。チェックインしたときに、その人の名前がページに現れます。行われた変更の一覧へのリンクがあります。もし、コンパイルかテストが失敗したとき、ボックスはコンパイル失敗理由を示すコンパイラからのアウトプットへのリンクも含みます。ページのいつかのテキストはパフォーマンス測定の結果も示します。

+

ほかの Web ツールとして、Bonsai があります。Bonsai はソースコードレポジトリのすべての変更を追跡します。誰かの行ったすべての変更の一覧を取り出すことが出来ます。Bonsai は変更一覧の問い合わせのための強力なインタフェースも提供します。

+

更なる情報を探す

+

一般的なプログラミング技術について述べられたものについてもっと知りたければ、Web でフリーのドキュメントを捜し求めることを勧めます。うまくいけば、そのドキュメントでの言及が導いてくれるでしょう。もし、本を読むことをより好むなら、一般的な説明を著者が試みている本であって、いくつかの特定の OS に集中していない本を選ぶことを勧めます。

+

Mozilla に関するたいていのドキュメントは www.mozilla.org の Web サイトに掲載されています。もし、探しているものがなければ、サーチエンジンを使うことを試してみてください。いくつかのポピュラーなサーチエンジンは、特定の Web サイトに限定して検索することのできる上級 (詳細) 検索オプションを提供しています。

+
+

原文書の情報

+ +
+
+  
diff --git a/files/ja/conflicting/mozilla/firefox/releases/index.html b/files/ja/conflicting/mozilla/firefox/releases/index.html new file mode 100644 index 0000000000..8067ad603e --- /dev/null +++ b/files/ja/conflicting/mozilla/firefox/releases/index.html @@ -0,0 +1,416 @@ +--- +title: リリースノート +slug: Tools/Release_notes +translation_of: Mozilla/Firefox/Releases +translation_of_original: Tools/Release_notes +--- +
{{ToolsSidebar}}

Firefox 52

+ + + +

Firefox 51 から Firefox 52 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 51

+ + + +

Firefox 50 から Firefox 51 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 50

+ + + +

Firefox 49 から Firefox 50 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 49

+ + + +

Firefox 48 から Firefox 49 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 48

+ +

ハイライト:

+ + + +

Firefox 47 から Firefox 48 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 47

+ +

ハイライト:

+ + + +

Firefox 46 から Firefox 47 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 46

+ +

ハイライト:

+ + + +

Firefox 45 から Firefox 46 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 45

+ +

ハイライト:

+ + + +

Firefox 44 から Firefox 45 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 44

+ +

ハイライト:

+ + + +

Firefox 43 から Firefox 44 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 43

+ +

ハイライト:

+ + + +

Firefox 42 から Firefox 43 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 42

+ +

ハイライト:

+ + + +

Firefox 41 から Firefox 42 の間に解決した開発ツール関連のバグ一覧。

+ +

Firefox 41

+ +

ハイライト:

+ + + +

Firefox 40 から Firefox 41 の間に解決した開発ツール関連のバグ一覧。特にパフォーマンスツールに関係する、これらのバグ修正の多くは Firefox 40 に反映されました。

+ +

Firefox 40

+ +

ハイライト:

+ + + +

さらに:

+ + + +

Firefox 39 から Firefox 40 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 39

+ +

ハイライト:

+ + + +

Firefox 38 から Firefox 39 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 38

+ +

ハイライト:

+ + + +

Firefox 37 から Firefox 38 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 37

+ +

ハイライト:

+ + + +

Firefox 36 から Firefox 37 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 36

+ +

ハイライト:

+ + + +

Firefox 35 から Firefox 36 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 35

+ +

ハイライト:

+ + + +

Firefox 34 から Firefox 35 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 34

+ +

ハイライト:

+ + + +

Firefox 33 から Firefox 34 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 33

+ +

ハイライト:

+ + + +

さらに:

+ + + +

Firefox 32 から Firefox 33 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 32

+ +

ハイライト:

+ + + +

さらに:

+ + + +

Firefox 31 から Firefox 32 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 31

+ +

ハイライト:

+ + + +

さらに:

+ + + +

Firefox 30 から Firefox 31 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 30

+ +

ハイライト:

+ + + +

さらに:

+ + + +

Firefox 29 から Firefox 30 の間に解決した開発ツール関連のバグ一覧

+ +

Firefox 29

+ +

Firefox 29 Hacks ブログの記事。ハイライト:

+ + + +

Firefox 28

+ +

Firefox 28 Hacks ブログ記事。ハイライト:

+ + + +

Firefox 27

+ +

Firefox 27 Hacks ブログ記事。ハイライト:

+ + -- cgit v1.2.3-54-g00ecf