新規
編集
添付
一覧
最終更新
差分
バックアップ
凍結
複製
名前変更
ヘルプScintilla内部設計の概要 
トップレベル構造
Scintillaは3個の主要な層のC++コードから成る。
- ライブラリの移植性
- コアコード
- プラットフォームのイベントとAPI
この構造の主要な目的は、プラットホームに依存しないコアコードからプラットホームに依存するコードを切り離すことである。
これは、新しいプラットホームにScintillaを移植するのをより簡単にして、コードのほとんどの読者がプラットホームの詳細に対処する必要がないことを確実にする。移植性問題を最小にして、コードが増大することを避ける。C++のサブセットの保守は、例外処理のない、ランタイムタイプ情報または制限されたテンプレートの使用としてScintillaで使われる。
現在サポートされるプラットホームは、Windows、GTK+/Linux、および多くの似た方法のwxWindowsである。
それぞれにウインドウ、メニューおよびビットマップがある。
これらの特徴が一般に同様の方法で動作するので、ウインドウを動かすか、またはレッド・ラインを描画する方法がある。
時々、1個のプラットホームがただ一つの呼び出しよりむしろ呼び出しのシーケンスを必要とする。
ほかと違う場合、より深い知識が必要である。
Windowsクリップボードを読むのは同期して発生するが、GTK+クリップボードを読むのはクリップボードデータを含むメッセージを非同期に答えられる要求呼び出しを必要とする。
wxWindowsプラットフォームは、wxWindowsサイト
から利用可能である。
ライブラリの移植性
これはプラットフォームのネイティブな能力上の小さく薄いそうである。
移植性ライブラリはPlatform.hで定義され、各プラットホームに実装される。
PlatWin.cxxはメソッドのWindows異形とPlatGTK.cxxはGTK+異形を定義する。
ここのいくつかのクラスが、プラットホームの特定のオブジェクト識別子を保持して、プロキシとしてこれらのプラットホームオブジェクトに働く。
どれが現在のプラットホームであるかを気にかけずに、その結果、ほとんどのクライアントコードがプラットホームオブジェクトを操作できる。
時々、クライアントコードは基本的なオブジェクト識別子へのアクセスを必要としGetIDメソッドでこれを提供する。
プラットホームの特定の識別子の基底型は、それらがクライアントコードで必要であるところにほとんど移されるのを許容するために一般名に型定義される。
Point, PRectangle
これらは、一般的に使用された幾何プリミティブを保持するために提供された簡単なクラスである。
PRectangleはすべての側を含むことの代わりに、標準のGTK+の下と右側を含まないMac/Windowsコンベンションに続く。
Windowsのマクロの名前であるかもしれないので、それはRectangleと呼ばない。
Colour, ColourPair, Palette
色はプラットホームの特定の色の識別子を保持する。- WindowsのためのCOLORREFとGTK+のためにGdkColor。
色を作る赤、緑、青の成分は、Windowsで利用可能な精度の8ビットに制限される。
すべての可能な色がいつも利用可能であるというわけではないので、ColourPairsは使用される。
8ビット色モードを使用することは、WindowsとGTK+の両方のための共通設定、256色だけが表示のときに可能であるということである。
したがって、#400000はアプリケーションが無味乾燥な赤を求めるときだけ、#800000または#330000などの既に利用可能な色がそれに割り当てられるかもしれない。
16または2色モードがさらに少ない状態で、選択は利用可能である。そして、アプリケーションは限られたセットの既に利用可能な色を使用しなければならない。
Paletteオブジェクトは、1セットの色ペアを保持して、これらの色を割り当てて、許容されるプラットホームが決めたものを見るように頼むという適切な呼び出しができる。
Font
フォントは、プラットフォームに固有のフォント識別子を保持する。WindowsならHFONT、GTK+ならGdkFont*である。
それは自身の識別子ではなく、そのデストラクタではプラットフォームのフォントオブジェクトを削除しない。
クライアントコードは、適切な時期にDestroyを呼ぶべきである。
Surface
Surfaceは各プラットホームの操作をできるグラフィカル描画の概念上の抽象化である。
それは、ウインドウなどの既に作成された描画場所をラップするか、ビットマップを作成するのに使用されて、または後で別のSurfaceにコピーされるかもしれない。
Windowsでは、それはHDCとHBITMAPをラップする。
GTK+では、GdkDrawable*とGdkPixmap*をラップする。
動作を引き起こしながら働くのが必要であるときに、他のプラットホームの特定のオブジェクトは作成される(そして、正しく破壊される)。
描画は、多角形、線、長方形、楕円、およびテキストを描画および消去するのを含める操作を提供する。
他の詳細と同様にテキストの高さと幅を測定できる。
操作を長方形に切り取ることができる。
すべての引数が各呼び出しのときに通過されている状態で、呼び出しの大部分は状態がない。
これへの例外は、MoveToとLineToを呼ぶことによって実行される線画である。
Window
プラットフォームウインドウの中継として働くウインドウは、表示、移動、再描画および破壊のような操作を行う。
それはプラットフォーム固有のウインドウ識別子を含む。- WindowsのためのHWND、GTK+のためのGtkWidget*
ListBox
ListBoxはウインドウのサブクラスで、プラットフォームのリストボックスに中継として働くアイテムの登録、取得および選択操作のためのメソッドを追加する。
Menu
メニューはポップアップメニューを構成するための小さなヘルパークラスである。
それはプラットフォーム固有のメニュー識別子を含む。- WindowsのためのHMENU、GTK+のためのGtkItemFactory*
プラットフォームイベントへのアクセスを必要とするので、プラットフォームイベントとAPI層の中でメニューを構成する仕事の大部分を行う。
Platform
Platformクラスはプラットフォームの施設にアクセスするために使う。
ダブルクリック速度やクロム色のようなシステムパラメータは、Platformから取得できる。
DebugPrintfのようなユーティリティ関数は、Platformから利用可能である。
コアコード
Scintillaコードのバルクは、プラットフォーム独立である。
これは、CellBuffer、ContractionState、Document、Editor、Indicator、LineMarker、Style、ViewStyle、KeyMap、ScintillaBase、CallTip、およびAutoComplete主要クラスを作成する。
CellBuffer
CellBufferはテキスト、スタイル情報、アンドゥスタック、行への行マーカーのアサイン、および折りたたみ構造を持っている。
セルは文字バイトとその関連スタイルバイトを含む。
セルバッファの現在の状態は、セルのシーケンスである。テキストと、それぞれの行の開始位置とそれぞれの行の関連するマーカを含む行情報のシーケンスを作る。
アンドゥスタックはセルバッファへの動作のシーケンスを保持する。
各動作はテキスト挿入、テキスト削除またはアンドゥス開始動作の1つである。
開始動作は、それらを一緒に元に戻すことができるようにテキスト入力と削除のシーケンスを分類するのに使用される。
各取消操作、挿入または削除を実行するのは逆のシーケンスで元に戻される。
同様に、リドゥは連続して各動作をバッファに戻す。
文字がバッファにInsertStringなどの呼び出し、またはアンドゥまたはリドゥで直接挿入される。
クライアントコードは便利であるときはいつも、各文字をスタイルに合わせる原因となる。
スタイルの情報はアンドゥ動作で保存されない。
Document
ドキュメントはCellBufferを含んでいて、より高いいくつかとの取引は単語や、DBCS文字シーケンスや改行文字シーケンスなどの抽象化を行う。
ドキュメントが変化するとき、それはスタイルのプロセスを管理して、他のオブジェクトに通知するのに責任がある。
Editor
EditorオブジェクトはScintillaの中枢である。
それはコンテナからドキュメントを表示して、ユーザ動作と要求に応じるのに責任がある。
それはドキュメントの表示と押されたキーに機能をマップするKeyMapクラスのために、ContractionState、Indicator、LineMarker、Style、およびViewStyleオブジェクトを使う。
それぞれの見える行はまた、表示行からドキュメントまで行を写像するのに責任があるContractionStateに保持され、逆もまた同様である。
1個のDocumentオブジェクトに取り付けられた複数のEditorオブジェクトがあるかもしれない。
ドキュメントへの変化はDocWatcherメカニズムを通してエディタに送信される。
ScintillaBase
ScintillaBaseはEditorのサブクラスであり、コールチップの表示、自動補完リスト、およびコンテキストメニューを含むウィンドウ機能を加える。
これらの特徴はCallTipとAutoCompleteオブジェクトを使用する。
このクラスはオプションのScintillaの軽い実装である。要求されない場合は機能の追加をしない。
プラットフォームのイベントとAPI
それぞれのプラットフォームは、イベント受信のための異なったメカニズムを使う。
Windowsでは、メッセージとCOMを通してイベントを受信する。
GTK+では、コールバック関数が使われる。
それぞれのプラットフォームのために、クラスはScintillaBase(その結果Editor)から得る。
これはWindowsではScintillaWin、GTK+ではScintillaGTKである。
これらのクラスはプラットフォームのイベントメカニズムに接続し、Editorの仮想メソッドの実装と異なったプラットフォーム上でScintillaBaseを実装するための責任がある。
たとえば、この層は同期したWindowsクリップボードと非同期のGTK+クリップボードの間の違いをサポートする。
外部のAPIはこの層で各プラットホームには異なった都合のよいスタイルのAPIがあると定義される。- WindowsではメッセージでGTK+では関数呼び出し。
また、これは、複数のAPIがプラットホームで定義されるのを許容する。
GTK+上の現在利用可能なAPIは、Windows APIと同様であり、プラットホームコンベンションによく続かない。
ここでプラットホームコンベンションに続いた第2のAPIは実装することができる。
