• 著者: Patrick K. O'Brien
• 著者: Robin Dunn
• 所属: Orbtech
• 日付: 2004-03-26
• 版: 1.3
• ライセンス条件: wxWindows Free Documentation Licence, Version 3
• このページの翻訳:Noboru Yamamoto, KEK, JAPAN. 2007.Aug.

目次 †

はじめに †

この文書はひとりのPythonプログラマによって其の善き友であるPythonプログラマのために書かれたwxPython GUIツールキットのガイドです。最初は(C++プログラマ向けに書かれた)wxWidgetの文書の簡単な翻訳でしたが、そこから次第に発展してきまし た。 そしてC++には何も悪いところはないのですが、。。。

やれやれ、あなたはどうしても言わせたいのですね。そう私はC++が嫌いです。それで私はPythonを使うのです。もしあなたはC++を大好きな ら、別のところでwxWidgetの文書をお読みなさい。もしあなたが、むしろPythonプログラマを念頭に書かれたガイドを望んでいるならこのガイド を読み進んでください。もしこれがお気に召したら、新鮮なロースト仕立てのコーヒ豆、ダークチョコレート、幾ばくかのお金を私にお送りくださるのにご遠慮 は不要です。もっと良いのは、大量に私が書いたwxPythonについての本(Robin Dunnとの共著です）を購入して、あなたのお友達、親戚、同僚にお送りくださることです。

wxPythonとは? †

wxPythonはPython プログラム言語のためのGUIツールキットの一つです。このツールキットはPythonプログラマが信頼性のある、高度な機能性をもったグラフィカル・ ユーザ・インタフェースを単純かつ簡単に作成することを可能にします。このツールキットはPythonの(ネイティブコードの）拡張モジュールとして実装 されています。この拡張モジュールはクロス・プラットフォームなGUIライブラリであるwxWidget, それはC++で実装されいますが、をラップしています。

PythonやwxWidgetsとおなじくwxPythonはOpen sourceです。つまりこのソフトウェアは誰にでも無料で提供されまた内部やその変更に興味のある誰にたいしてもソースコードが提供されています。そし て誰もが訂正やプロジェクトへの協力を寄与することができます。

wxPythonはクロス・プラットフォームなツールキットです。つまり同じプログラムを複数の異なるプラットフォーム状で変更なく実行可能です。 現在サポートされているプラットフォームは32ビットのMicrosoft Windows,　殆どのUnixあるいはUnix互換のシステム、そしてMacintosh OS X です。

言語がPythonですので、wxPythonのプログラムは簡潔で、直ぐに書け、容易に理解できます。

wxPython の利用環境 †

wxPythonを使い始めるために、以下の環境を準備しなければなりません。

MS-Windows †

1. MS Windowsの動作する 486 あるいはそれ以上のCPUをもつPC
2. 最低 ?? MBのディスク空き容量

Linux or Unix †

1. 殆どすべてのUnix ワークステーション。GTK+ 1.2, GTK+ 2,0 Motif1.2あるいはそれ以上、Lesstifのいずれか。
2. C++コンパイラ：GNU C++ (EGCS 1.1.1 or above)を含むほとんどすべてのC++コンパイラ
3. 最低 ?? MBのディスク空き容量

Mac OS X †

1. Mac OSX 10.xが動作するPower PC Mac.*1
2. 最低 ?? MBのディスク空き容量

wxWidgetsとは？ †

wxWidgets は複数のプラットフォームで利用可能なGUI(グラフィカル　ユーザ　インタフェース)とその他の機能をもった C++フレームワークです。現在のバージョン２はすべてのデスクトップ板のMS Windows, GTK＋/Unix, Motif/Unix, そして MacOSXで利用可能です。OS/2への移植が進行中です*2。

wxWidgetsはEdinburgh大学、人工知能応用研究所で内部的な利用のために開発が始められました。1992に初めて一般へ公開されま した。　 バージョン２は大きく改良された版で、Juilan Smar, Robert Roebling, Vadim Zeitlin Vaclav Slavik等をはじめとする多くの方々が開発に参加しました。

用語に関する注意：この文書では、別に注記が無い限り、"MS Windows"はしばしばマイクロソフトWindowsに関連するすべてのプラットフォームに対して使われます。これには16ビット版や32bit版などの派生物を含みます。すべての商標は尊重されます。

なぜまた別のクロスプラットフォーム開発ツールなのか？ †

wxWidgetsはGUIアプリケーション開発に対する投資を最大限とする安価で柔軟性に富む方法を提供する ために開発されました。クロスプラットフォーム開発には既にいくつもの商用クラスライブラリが提供されていますが、 どれ一つとして以下の条件を満たすものはありません：

• 低価格
• ソースコードが入手可能
• プログラミングの簡潔さ
• 多種のコンパイラーをサポート

wxWidgetsの開発が始まったあとで、いくつかのフリーなあるいは殆どフリーなGUIフレームワークが興勢してきました。 しかし、それらにはwxWidgetsが持つような豊富な機能、柔軟性、解説文書そして確立した開発チームを備えたものは ありません。

オープンソース　ソフトウェアとしてwxWidgetは、ユーザからの意見、アイデア、バグ　フィックス、機能強化 そして熱狂的な支持から多くのものを得ています。これはwxWidgetsに商用の競合ライブラリ、そして独立した開発 チームを持たないフリーなライブラリに対する大きな優位点となっています。また、個人や企業の変化に対するロバストネス を与えています。この様なオープン性とソースコードの利用可能性は数千行からなるアプリケーションコードの将来が 基礎となっているクラスライブラリの寿命に依存している場合には特に重要です。

バージョン２は一般性と機能の両面において以前のバージョンに比較して大きく進歩しています。其の結果 作成されるアプリケーションは一つのプラットフォームに依存したツールキット、Motif, GTK+ そしてMFC,を 用いて開発されたそれと殆どの場合区別がつきません。

プラットフォーム非依存のクラスライブラリを使うことの重要性は言い過ぎになることはありません。 GUIアプリケーションの開発には時間がかかるものであり、特定のGUIの寿命は全く保証されているわけではないの ですから。

プログラムが適切でないプラットフォームや利用者に向けて書かれていると、瞬く間に其のコードは時代遅れ のものになってしまいます。wxWidgetsはプログラマをそれらの変化の大風から守るのを助けてくれます。 wxWidgetsは、たとえばOLEに強く依存した プログラム等の様に、すべてのアプリケーションに対して適切と言う訳ではありませんが、GUIプログラムが通常 必要とする殆どの機能を提供しますし、付け加えてネットワークプログラムのサポート、ポストスクリプト出力 機能、HTML整形表示などの追加機能も提供してくれます。どうしても必要となればwxWidgetsを拡張することも 可能となっています。さらにwxWidgetはネイティブのAPIに比べて非常に明確で使い易いプログラム　インタフェースを 提供します。プログラマは一つのプラットフォームについてのアプリケーションを作成する場合でも、wxWidgetsを 使う価値があることを知るでしょう。

wxWidgetsの機能を2,3のパラグラフにまとめることは不可能ですが、其の利点のいくつかを 以下に挙げてみます：

• 低費用(実際のところ無料です。)
• ソースコードを入手できます。
• よく使われるプラットーフォームの大半で利用可能です。
• 一般的なC++コンパイラとPythonで動作します。
• 50以上の見本のプログラムが提供されます。
• 1000ページ以上の印刷可能な文書が付属します。これらはオンラインドキュメントの形式でも利用可能です。
• Includes Tex2RTF, to allow you to produce your own documentation in Windows Help, HTML and Word RTF formats.
• 簡単に使えるオブジェク指向のAPIを持ちます
• 自由度の高いAPI.
• 柔軟なエベントシステム.
• 線分、丸みのある四角形、スプライン曲線、ポリラインなどの図形要素呼び出し
• 拘束条件を基本とした配置とSizerを基本とした配置法.
• 印刷／印刷確認および文書／描画アーキテクチャ.
• ツールバー、ノートブック、ツリー　コントロル、リストコントロルなどのクラス
• UnixでのPostScript? 生成、およびPCでのMS Windows標準の印刷.
• MDI (Multiple Document Interface) のサポート.
• WindowsではDLL, Unixでは動的ライブラリを作成するために使用できる。
• ファイルの閲覧、印刷、色選択などの共通ダイアログ
• MS Windowsではメタファいるの生成とメタファイルのクリップボードへのコピーをサポート
• アプリケーションからヘルプを起動するためのAPI.
• すぐに使えるHTMLウィンドウ(HTMLのサブセットをサポート）
• ダイアログを構築するためのダイアログエディタ.
• ソケットおよびプロトコルクラスの一族を使ったネットワークサポート
• プラットフォーム費依存のイメージ処理.
• 多彩なファイル形式(BMP, PNG, JPEG, GIF, XPM, PNM, PCX)を組み込みでサポート.

wxPythonによるアプリケーションの概要 †

wxPythonアプリケーションが進行するようにするには、App classを継承するクラスを定義し、　App.OnInit?メソッドを 上書きする必要があります。

アプリケーションはトップレベルのフレーム(wx.Frame)あるいはダイアログウィンドウ(wx.Dialog)をもたねばならない。それぞれのフレームは一つあるいはそれ以上のwx.Panel, wx.SplitterWindow? あるいはその他のウィンドウやコントロール部品のクラスのインスタンスを含んでいてよい。

フレームはメニューバー(wx.MenuBar)、ツールバー(wx.ToolBar?)、状態表示行、そしてフレームがアイコン化された時のアイコン(wx.Icon)を持つことができます。

パネル(wx.Panel)はwx.Controlクラスから導出されたクラスであるコントロール部品を配置するために使われる。コントロール部品はユーザとの やり取りのために使われる。ボタン(wx.Button)、チェックボックス(wx.CheckBox?)、選択(wx.Choice)、リストボックス(wx.ListBox?)、ラジオボタン(wx.RadioBox?)、スライダー(wx.Slider)などはコントロール部品 の一例である。

ダイアログ(wx.Dialog)のインスタンスもまたコントロール部品のために使われる。そして独立したフレームを要求しないという利点がある。

ダイアログボックスを作成し、様々なアイテムを作り出す代わりに、メッセージダイアログ(wx.MessageDialog?)やファイルダイアログ(wx.FileDialog?)のような 共通のよく使われるダイアログのクラスを使うこともできる。

直接にウィンドウに描画することは決して無い。そのかわりにデバイス・コンテキスト(wx.DC)を使うのだ。DCはwx.ClientDC, wx.PaintDC, wx.MemoryDC, wx.PostScriptDC, wx.MemoryDC, wx.MetafileDC そしてwx.PrinterDCの基礎クラスとなる。もしDCをパラメータとして持つ描画関数 があれば、これらのDCのどれでもをその関数に引き渡すことができ、其の結果おなじコードを使って異なるデバイスに描画を 行える。DC.DrawLine? やDC.DrawTex?などのDCのメンバ関数を使って描画を行える。ブラシ（Brush)やペン(Pen)とともにウィンドウ上の色(Colour)をコントロールする。

最新のアプリケーションスタイルではオンラインのハイパーテキスト　ヘルプシステムをもっているだろう。このために、Help とそれをコントロールするためのwx.HelpController? クラスを必要とするだろう。

GUIアプリケーションはすべてがグラフィカルな魔法の世界ではない。リストやハッシュ表といったデータ構造も必要となる。 我々はPythonを使っているのだから、wxWidgetが提供するデータ構造ではなく、 Pythonが提供するデータ構造(list, tuple, dict)を使うべきだ。同じことがデータベースに関連するクラスについても言える。 守るべき規則はこうだ：もし必要なことがPythonのデータ構造で直接に行えるなら、Pythonのデータ構造を使うべきだ。もし Pythonのそれを使うべきでない明確な理由があるなら、wxPythonはwxWidgetのクラスのラッパーを提供する。

同じプラットフォーム独立なファイル操作関数を必要とするだろうことは疑いようがない。ファイルパスのリストをwx.PathList? を 使って管理し、検索するのは非常に楽であることを知るだろう。

その他のクラスのリストは"Classess by Category"のセクションを見て欲しい。

wxPythonが提供するユーティリティとライブラリ †

コアとなるwxWidgetsライブラリのほかにも、更なるライブラリやユーティリティがそれぞれの配付パッケージに付属している。

これらのいくつかのものはcontrib階層の下におさめられている。"contrib"階層はメインのwxWidgets階層の構造を映し持っている。 'utils'階層も見て欲しい。これらのツールやライブラリについての解説文書を探す最初の場所はwxWidgetsの'docs'階層の下である。 たとえば、docs/htmlhelp/fl.chmなどである。

その他のユーザの寄付によるパッケージについてはwxWidgetsウェブページのContributionsページを見て欲しい。

Helpview

Helpview はwxWidgets HTML ヘルプファイルを表示するためのプログラムです。多くの場合、アプリケーション中でwxWidgets HTMLヘルプクラスを使うことが望まれるでしょう。しかしこのツールは単独で動作するビューアです。詳細はwxHTML Notesをご覧下さい。sample/html/helpviewにHelpviewはあります。

Tex2RTF

LaTex?マ ニュアルをHTML,MS HTML ヘルプ、wxHTML ヘルプ、RTF、そしてWinodws ヘルプ　RTF形式に変換するTex2RTFと呼ばれるツールがwxWidgetとともに配付されています。Tex2RTFはwxWidgetsのマニュ アルに利用され居ますし、同じLaTex?ソースからオンラインマニュアルと印刷物のマニュアルの双方を生成しようと望む方にも利用していただけます。Tex2RTFについてのべつ文書をご覧下さい。それらはutils/tex2rtfにおさめられています。

Helpgen

HelpgenはC++ヘッダファイルを読み込んで、Tex2RTFと互換性のある文書ファイルを、ヘッダファイルのなかで見つけ出したクラス毎 にコメントをもとに作成します。 これは一群のクラスについてのリファレンスを作成する初めの枠組として悪くありません。Helpgenは　utils/Hepgenにあります。

Emulator

Xnestを基本としたX11ベースのPDAアプリケーションのためのディスプレイエミュレータです。いくつかのシステムではXnestウィンド ウは"表皮"のウィンドウと同期していないことがあります。このプログラムはulits/emulatorにおさめられています。

XRC リソースシステム

これはsizerに配慮したリソースシステムです。 wxDesignerなどのツールで生成することのできるXMLに基づくリソースの記述を採用しています。src/xrc, include/wx/xrc, samples/xrcに関係したファイルがおさめれています。詳細な情報 はXML-に基づくリソースシステムの概要をご覧下さい。

オブジェクト　グラフィクス　ライブラリ(OGL)

OGLは線分でつながれたオブジェクトを画面に表示する必要のあるアプリケーションのためのAPIを定義しています。contrib/src/ogl, contrib/include/wx/oglおよびcontrib/samples/oglをご覧下さい。

フレーム　レイアウト(FL)ライブラリ

FLは洗練されたペーンのマウスドラッグによるサイズ変更や結合のファシリティを提供します。contrib/src/fl, contrib/include/wx/fl, そして contrib/samples/fl　をご覧下さい。

Gizmos ライブラリ

Gizmos は有用なウィジェットやその他のクラスを集めたものです。含まれるクラスは、 wxLEDNumberCtrl?, wxEditableListBox?, wxMultiCellCanvas?などです。contrib/src/gizmos, contrib/include/wx/gizmos, および contrib/samples/gizmos　に納められています。

Net ライブラリ

Net　はとても簡単なメールとウェブに関連したクラスの集合体です。現在はwxEmailだけが利用可能です。このクラスはWidows上では MAPI、Unixではsendmailを使ってメールを送ることをとても簡単にしてくれます。 contrib/src/net と contrib/include/wx/netをご覧下さい。

Animate ライブラリ

Animate を使うことで、アニメートGIFファイルをロードして、画面上でそれを表示できる様になります。 ライブラリはその他のアニメーション形式に拡張することもできます。contrib/src/animate, contrib/include/wx/animate, および contrib/samples/animateがこのライブラリの場所です。

MMedia ライブラリ

Mmedia は様々なマルチメディア機能をサポートします。このライブラリの状態は現在の所はっきりしていません。contrib/src/mmedia, contrib/include/wx/mmedia, そして contrib/samples/mmediaをチェックしてください。

スタイル付き文字列操作部品(STC)　ライブラリ

STCは文法強調機能付きエディタであるScintillaのラッパーです。contrib/src/stc, contrib/include/wx/stc, および contrib/samples/stc　に納められています。

Plot

Plot は簡単なグラフ作成ライブラリです。contrib/src/plot、contrib/include/wx/plot, and contrib/samples/plot.で見つけることができます。　wxPythonでは、

import wx.lib.plot as plot
import wx
app=wx.PySimpleApp()
frm=plot.TestFrame(None,-1,"Plot sample")
frm.Show()
app.MainLoop()

でサンプルプログラムを起動することができます。Plotメニューでplotの機能を選択します。

wxPythonオブジェクトの生成と廃棄 †

[Thissection needs to be reviewed.]

App 概要 †

Classes: wx.App

アプリケーションの初期化 †

wx.Appを継承したクラスで定義されるOnInit?メソッドが通常最小限のこととしてトップウィンドウを作成する。

OnInit?メソッドは処理を継続(True)すべきかあるいは終了(False)すべきかを示すブール値を戻り値として返す。 wxPythonにトップウィンドウを通知するためにはApp.SetTopWindow?を呼びます。

アプリケーションはすべてのウィンドウを閉じて終了する。アプリケーションが終了するためにはすべてのフレームが 廃棄されなければならない方、新しいフレームを作る際に可能ならば親フレームを使うことが推奨される。それによって トップレベルのフレームを廃棄するとその子供のフレームは自動的に廃棄されるからである。 別の方法としては、トップレベルのフレームのCloseEvent?ハンドラーの那珂で子供のフレームを明示的に破棄することもできる。

緊急寺にはwx.Exit()をアプリケーション終了の為に呼ぶことができる。しかし、通常はアプリケーションは自動的に終了する。 以下を参照のこと。

アプリケーションの破棄の例：

import wx

from frame import Frame 

class App(wx.App):
    """Application class.""" 

    def OnInit(self):
        self.frame = Frame()
        self.frame.Show()
        self.SetTopWindow(self.frame)
        return True

def main():
    app = App()
    app.MainLoop()

if __name__ == '__main__':
    main()

アプリケーションの終了 †

通常アプリケーションは最後のトップレベルウィンドウが閉じられたときに終了する。これは通常予期された振る舞いであるし、 アプリケーションが単一のトップレベル　ウィンドウをもつなら、Expt メニューコマンドに対する応答としてClose()を呼べばよい ということになる。この振る舞いを望まないなら、その振る舞いを変更するためにApp.SetExitOnFrameDelete?()メソッドを実行 してよい。このようなロジックはプログラムがメインループに入るまでは有効では無いことに注意してください。言い換えれば、 App.OnInit?のなかでダイアログを表示して、恐れること無くこのダイアログが閉じられた時、このときにはこのダイアログが最後のトップレベルウィンドウとなっていますが、アプリケーションを終了できます。

アプリケーションの終了に関する別の留意点はOnExit?メソッドです。OnExit?メソッドはアプリケーションの終了時にwxPythonがその内部データ構造を消去する前に呼び出されます。OnExit?を終了する前に自分自身が作り出したwxPythonのオブジェクトを廃棄しておくべきです。

たとえば次のコードはクラッシュするかも知れません：

[Need examples of objects needing cleanup to keep app from crashing.]

Sizer 概要 †

Classes: wx.Sizer, wx.GridSizer?, wx.FlexGridSizer?, wx.BoxSizer?, wx.StaticBoxSizer?, wx.NotebookSizer?, wx.CreateButtonSizer?

wxPythonのクラス階層ではwx.Sizerクラスとその子孫として表現されるサイザー(Sizer)の一群はwxPythonにおいてダイ アログ中の コントロール部品の配置を指定する際に選択される方法となっている。それはSizerを使うことで視覚的に説得力のあるダイアログを プラットフォームに依存することなく, 其のコントロール部品のサイズやスタイルの際を考慮した上で、指定できるという能力に依っている。wxDesigner, wxcredit, XRCed , wxWorkshpといったエディターはSizerに強く頼ったダイアログを生成します、実際上 それによってユーザがプラットフォームに依存しないダイアログを妥協すること無くデザイするようにしむけています。

Sizerの基本的な考え方 †

wxPythonのSizerが採用している配置アルゴリズムはJava's AWT, GTKツールキット、Qt ツールキットといったその他のGUIツールキットの配置システムと密接に関係しています。 このアルゴリズムではウィンドウ中に含まれる子ウィンドウはその必要とする最小の大きさと、親ウィンドウが変更されたときにそのサイズを変えることができるかをそれぞれ上位ウィンドウに報告すると言うアイデアに基づいています。 これは通常プログラマーがダイアログの初期の大きさを指定するのではなく、ダイアログ（ウィンドウ）にはSizerを割当て、 このSizerが推奨される大きさを答申すると言うことになります。Sizerはその子、それは通常のウィンドウであったり、空白であったり、別のSizerで会ったりしますが、に推奨される大きさを問い合わせます。それによってSizerの階層が作り上げられます。 wx.Sizerクラスはwx.Windowクラスから派生したものでは無いことに注意してください。このことで、Sizerはtab順序との相互作用がなく、スクリーン上の実際のウィンドウに比べて非常に少ない資源しか要求しません。

wxPythonとSizerの相性がよいのは、すべての構成要素はその最小サイズを報告し、アルゴリズムがプラットフォーム毎のフォントサイズの違いやウィンドウ（ダイアログ部品）のサイズの違いを問題なく取り扱えるということに依っています。 たとえば、もしLinux/GTKウィウジェットの標準フォントが全体のデザインとおなじくWindowsのそれより大きければ、ダイアログの初期サイズは自動的にLinux/GTKではWindowsにくらべ大きくなります。

現在のバージョンでは五つの異なった種類のSizerがwxPythonでは利用可能となっています。 それぞれは、ダイアログのなかにダイアログ部品を配置するある方法を表現するか、ダイアログ部品(あるいは別のSizer)の周りを 静的な箱で包む等の特別なタスクをみたすために用意されています。 それらのSizerは以下のテキストで一つ一つ説明されます。 以下のテキストで、それらのSizerを一つ一つ説明します。

共通の機能 †

すべてのSizerはコンテナです。つまりこれらはダイアログ部品（あるいは複数のダイアログ部品）を配置するために使われ、Sizerは これらの部品を含んでいます。これらの部品はSizerの子供と呼ばれることがあります。 Sizerがどのようにこれらの子供を配置するかとは独立にこれらの子供はある共通の特徴を持っています:

最小サイズ †

この最小サイズは通常コントロール部品の初期サイズと同じです。初期サイズは明示的にコントロール部品の生成子の sizeフィールドでしていすることもありますし、heightやwidthを-1と指定することでwxPythonに計算させることもできます。 一部のコントロール部品(たとえばチェックボックス）ではそのサイズを計算できますが、その他の部品（リストボックスなど）では自然なサイズが存在せず明 示的にサイズを指定する必要があることに注意しておきます。コントロール部品にはその高さを計算することはできますが幅を計算することはできないもの(た とえば一行のテキストコントロール部品）もあります。

[Need graphics]

境界 †

境界は何も無いスペースです、ダイアログのなかのダイアログ部品を分けておくために使われます。 境界は周りすべてにあるかあるいは側面と任意の組み合わせ、たとえば部品の上下のみ、におくことができます。 境界の太さは明示的に指定しなければなりません、通常は5ポイントです。以下のサンプルは一つだけのダイアログ部品（ボタン）を 持つダイアログを表示します。ダイアログの周りには0, 5 , 10 ピクセルの境界があります:

[Need graphics]

整列 †

ダイアログ部品にはその最小サイズと境界の和より大きなスペースが割りあてられることがあります。 それぞれのダイアログ部品に対するどのフラグが使われたかによってダイアログ備品が利用可能な空間全体を使ってしまうか、この場合には最小サイズよりも大きなサイズに部品が広がることになる、また利用可能なスペースの中央に配置されるのか、 あるいは空間のいずれかの側に寄って配置されるのかが決められます。以下の例では水平ボックスSizer中に一つのリストボックスと 三つのボタンが配置されています。一つのボタンは中央に配置され、別のボタンは上部に整列され、最後の一つは最下部に整列されています：

[Need graphics]

拡張因子 †

Sizerが複数の子供を持ち、子供達が必要とする最小サイズと境界の和よりも大きな空間を割り与えられたとき、余分な空間を これらの子供達にどのように配分するかという問題が引き起こされます。これを解決するために、拡張因子をそれぞれの子供に 割与えることができます。拡張因子の規定値０は必要最小サイズより大きくなることは無いとの意味になります。 非負の拡張因子はすべての子供達の拡張因子の和に対する相対的な意味を持ちます。つまり、二つの子供がそれぞれ拡張因子１を 持てば、それぞれの子供部品は余分な空間の半分ずつを受け取ります。これは一方の部品の最小サイズが他方のそれに比べて大きいとか小さいとかに関係なく分 け与えられます。以下の例は三つのボタンを持ったダイアログを表示しています。最初のボタンは拡張因子１をもつので広がっています。その他の二つのボタン は拡張因子０を持つので、初期値の大きさのままです。

wxDesignerでは、この拡張因子はOptionメニュから選択して設定できます。

BoxSizer? †

BoxSizer?は其の子供部品を水平あるいは鉛直方向に一列に配置することができます。整列の方向はBoxSizer?のインスタンスを生成 する際のフラグによって指定されます。鉛直Sizerを使う場合には、それぞれの子供は、中央寄せ、左寄せ、右寄せのいずれかに 整列させられます。同様に、水平Sizerでは、それぞれの子供は中央寄せ、天井寄せ、底寄せのいずれかを選択できます。 前節で説明した拡張因子はメインとなる方向について適用されます。つまり水平Sizerを使っているときには、拡張因子は それぞれの子供がどれだけ水平方向に拡張可能かを決めています。次の例は前節の例と同じですが、box sizerが鉛直box sizer となっていることだけが違います：

静的BoxSizer? †

静的BoxSizer?はBoxSizer?と同じですが、静的Boxで囲まれている点だけが異なります。 例をご覧下さい。：

GridSizer? †

GridSizer?は２次元のSizerです。すべての子供部品は同じ大きさを割与えられます。この大きさは最大の子供が必要とされる大きさ となります。この例では左下部にあるテキストコントロール部品がこの最大の子供となります。行の数あるいは列の数は固定となります。Grid Sizerは新しい子供部品が追加された際には、それとは異なる方向に伸びて行きます。

柔軟なGridSizer? FlexGridSizer? †

別の２次元サイザがGridSizer?から導出されています。　それぞれの列の幅と行の高さは独立に最大の子供の最小限のサイズの要求量 から決められます。さらに、列と行は、もしSizerが要求したものとは異なる大きさを割り当てられた時、伸縮可能と宣言されることができます。以下の例は上記の例とおなじですが、FlexGridSize?を使っていることが異なります。

GridBagSizer? †

GridBagSizer?はGridSizer?の仲間のなかで最も柔軟なSizerです。

ノートブック：NotebookSizer? †

NotebookSizer? はノートブックと一緒に使われます。NotebookSizer?はノートブックのそれぞれのページのサイズを計算し、 ノートブックのサイズを最大のページのサイズに設定するとともにノートブックタブと周囲の飾りの追加のスペースも 追加します。

[Needs Graphics]

BoxSizer?を使ったプログラミング †

BoxSizer?の基本的考え方は、ウィンドウは大体において単純な基本的な形にそって並べられると言うものです。 典型的には水平あるいは鉛直の箱とそれらの階層的な組み合わせになっています。

れいとして、テキストフィールドを上部にもち二つのボタンを底部に持つダイアログを作ってみます。 これは上部階層のテキストフィールドを上部にボタンを底部に持つ列構造と、OKボタンを左にCancelボタンを右にもつ低位の階層の 行構造とみることができます。多くの場合（とくにUnixのダイアログと通常のフレームにおいてはそうですが）メインウィンドウはユーザによるサイズの変更が可能です。このサイズ変更はその子供部品にも伝えられなければなりません。 この例題ではテキストフィールドはダイアログとともに伸び縮みして、ボタンは同じ大きさにとどまるでしょう。 さらに、すべてのコントロールの回りに薄い枠領域が見栄えを良くするために付け加えられ、事態を悪くするために、 ボタンはダイアログの幅が変更されても、中央にとどまります。

|  Add(*args, **kwargs)
|      Add(self, item, int proportion=0, int flag=0, int border=0,
|          PyObject userData=None)

box sizerではboxは水平および鉛直のどちらの方向にも伸縮可能ですが、子供部品に不均等にその変更を配分することはお主な方向 (行boxでは水平方向）のみであるというのは、boxSizerの特徴のひとつです。 この例では、鉛直方向Sizerは高さの変更分のすべてをテキスト　エリアだけに配分し、ボタンエリアには配分しないと想定されます。これはSizerに ウィンドウあるいは別なSizerを追加する際のproportionパラメータの設定によって決められます。proportion パラメータは０、このときウィンドウはサイズ変更不能、あるいは正の値をとります。いくつかのウィンドウがゼロでない値をもてば、値は、すべての重みの和 に対する相対値と理解されます。つまい二つのportionパラメータが１のウィンドウを付け加えるとこれらのウィンドウは等しく伸縮され、それらを持つ sizerのちょうど半分の伸縮量となります。

それでは、列Sizerが幅を変えたとき何をすべきでしょう。振る舞いは,Add()関数の第三の引数であるフラグで制御されます。 ０あるいはフラグの指定が無い場合にはBoxsierは元々の幅を保持します。wx.GROW(あるいはwx.EXPAND)が指定されるとSizerと ともに伸縮します。wx.SHAPEDフラグはウィンドウはアスペクト比を保持したまま比例してサイズを変えます。wx.GROWフラグが セットされていないとき、部品は利用可能な領域で整列されます。wx.ALIGN_LEFT, wx.ALIGN_TOP,wx.ALIGN_RIGHT, wx.ALIGN_BOTTOM, wx.ALIGN_CENTER_HORIZONTAL そして wx.ALIGN_CENTER_VERTICAL　は名前が示す様に整列します。wx.ALIGN_CENTRE (wx.ALIGN_CENTERとしても同じ)は (wx.ALIGN_CENTER_HORIZONTAL | wx.ALIGN_CENTER_VERTICAL)と定義されています。既定の整列フラグはwx.ALIGN_LEFT | wx.ALIGN_TOPです。

既に触れた様に、sizerに属するどのウィンドウも境界（枠）を持つことができます。そして四つの辺のいずれが境界を持つかを、wx.TOP, wx.LEFT, wx.RIGHT および wx.BOTTOM の４つの定数 あるいは　すべての方向を示す　wx.ALL を用いて指定できます。 wx.NORTH, wx.WESTなども同様に利用可能です。これらのフラグは上記の整列フラグと二進数のorオペレータ(|)で組み合わせてAdd()メソッドの第三引数 に与えます。境界のサイズも知らせる必要があり、これはAdd()メソッドの第四引数となります。つまり、 sizerとその子供部品の振る舞いはAdd()メソッドの三つのパラメータでその振る舞いが完全に規定されるということになります。

[Show code and graphic here.]

GridSizer?　のプログラミング †

GridSizer?ではすべての子供部品は二次元のテーブルに配置され、テーブルのすべてのフィールドは同じサイズに なります。つまり、フィールドの幅は最大の幅を持つ子供部品の幅で高さは一番高い子供部品の高さになります。 [Show code and graphic here.]

FlexGridSizer?のプログラミング †

FlexGridSizer?は子供部品を二次元のテーブルに配置します。一つの行に属するフィールドは同じ高さを持ち、一つの列に属する フィールドは同じ幅を持ちますが、GridSizer?とは異なり、すべての行あるいはすべての列が同じ高さあるいは同じ幅を持つ必要はありません。

[Show code and graphic here.]

NotebookSizer?のプログラム †

NotebookSizer?はNotebookクラスと連携して動作する特別なSizerです。 このSizerは子供部品を足すことが許されないというその他のsizerとはまったく異なったSizerです。 子供部品を足す代わりに、notebookSizerはNotebookにたずねます。 このSizerのなすべきことは、Notebookの最大のページのサイズを決定し、その調整された最小のサイズを上位のSizerに 伝えることです。

ノートブックページのサイズを調べるために、このページはそれ自身のSizerを持っている必要があります、さもなければNotebookSizer?はこのページを無視します。ノートブックのページはSetSizer?()メソッドを使ってそれ自身のSizerを割り当てます。 またSetAutoLayout?()メソッドの引数をTrueとすることで、自動レイアウトオプションを設定します。以下に NotebookSizer?の管理下におかれたノートブックページを追加する方法を示します。：

[Show code and graphic here.]

StaticBoxSizer? 　のプログラム †

StaticBoxSizer?はBoxSizer?を継承して作られたSizerで、Sizerの周りに静的な箱を持っている。この静的な箱は別途生成 されなければならないことに注意しておいて欲しい。

[Show code and graphic here.]

Dialog.CreateButtonSizer? †

使い易さの為に、DialogクラスはCreateButtonSizer?(flags)メソッドを持っています。このメソッドは標準的なボタンが表示される標準ボタンSizerを生成します。以下のフラグをこのメソッドの引数に与えることができます。:

wx.YES_NO

add Yes/No subpanel

wx.YES

return wx.ID_YES

wx.NO

return wx.ID_NO

wx.NO_DEFAULT

make the wx.NO button the default, otherwise wx.YES or wx.OK button will be default

wx.OK

return wx.ID_OK

wx.CANCEL

return wx.ID_CANCEL

wx.HELP

return wx.ID_HELP

wx.FORWARD

return wx.ID_FORWARD

wx.BACKWARD

return wx.ID_BACKWARD

wx.SETUP

return wx.ID_SETUP

wx.MORE

return wx.ID_MORE

日付と時刻に関するクラスの概要 †

wxPythonは日付や時刻を取り扱うのに強力なクラスの組み合わせを提供します。 DateTime?クラスがサポートする機能の一部を列挙すると：

広い範囲

日付としてサポートされるのはおおよそ 4714 B.C.　から四億八千万年の未来までの広い範囲です。

精度

浮動小数点による計算を避けることによって、丸めエラーの影響を受けません

多くの機能

通常の必要となる計算はサポートされています。日付計算で必要となる通常の計算だけでなく、もっと特殊な週と年の計算、勤労日のテスト、標準的な天文関係の関数、固定あるいは自由形式の文字列との間の相互変換などもサポートされています。

効率

DateTime?オブジェクトは小さく(わずか８バイト）で高速に動作します。

すべての日付／時間クラスの一覧 †

絶対的な時刻を表現するDateTime?オブジェクトの他に三つの主要なクラスがあります。そのほかにも二つの時間を表現するクラス、 TimeSpan?とDateSpan?が用意されています。

DateTime?クラスとともに使われるヘルパークラスもあります。指定された日が休日であるかどうかを決定するDateTimeHolidayAuthority?クラス、このクラスから導出され土曜と日曜だけが休日であるDateTimeWorkDays?クラスなど。これらの クラスの詳細については休日に関する議論を参照してください。

DateTime? クラスの特徴 †

DateTime?クラスは時間をEpoch,それは1970年１月１日に通常は固定されています、からのミリ秒単位の符号付き数値で表します。 このEpochはクラスのユーザが気づくことはありません、とくにEpochより以前の日付はEpoch以後の日付と同じ様にうまく(あるいはまずく）処理されます。しかし、最善の時間の分解能は１ミリ秒に制限されることになります。

DateTime?オ ブジェクトのサイズは8バイトで、64bitsの整数として表現されます。ですからサポートされる時間範囲はおおよそ５億８千万年となります。しかしグレ ゴリオ暦のサポートの制限から紀元前4714年１１月２４日以降がサポートされています。（充分な興味があれば、これは変更される可能性があります。）

現在のところグレゴリオ暦だけがサポートされています。グレゴリオ暦の歴史的な導入、それは1582年10月15日ですが、以前に対しても、グレゴリオ暦を適用します。一般的に言って、歴史的なグレゴリオ暦の導入は国、あるは地域によって異なっています。将来の バージョンではユリウス暦がサポートされるでしょうし、やその他の暦(マヤ、イスラエル、中国など）のサポートも完全に排除されたわけではありません。

DateSpan? と TimeSpan?　の差異 †

絶対的な瞬間を表現するには唯一の論理的な方法しか無い、従ってDateTime?クラスだけが唯一サポートされている、が時間を 表現するのには少なくとも二つの方法がある。

まず、TimeSpan?に実装されている直接で、自ら意味のあきらかな方法である。TimeSpan?は二つの時刻の時間をミリ秒単位で表現 します。その様な時間をDateTime?に加えるあるいは引き去ることは意味がはっきりしたしかも高速な操作である。

しかし日常の生活に立ち戻るとカレンダーにいぞんした時間間隔の指定が使われます。たとえば、『ひと月後に」は当たり前に使われます。しかし、これはTimeSpan?の60*60*24*30 秒後でなないことは明らかです。たとえば2月15日の「ひと月後」は３月１６日でも3月17日でもありません（閏年かそうでないかによって）

これがまた別の時間を表現するためのクラスDateSpan?が導入された理由です。このクラスは例のような操作を最も自然と思われる方法で取り扱います。しかしこのような種類の操作がいつもはっきりした意味を持っているわけでは無いことに注意が必要です。 例えば、1月31日のに「ひと月」を加えることを考えてみます。これは２月28日（あるいは２月２９日）を与えるでしょう。つまり、２月の最後の日と言うことで、存在しない２月３１日ではありません。もちろんこれが通常期待される結果ですが、２月２８日から おなじ「ひと月」を引き去ると結果は１月２８日であって、出発点の１月３１日では無いことに気がついて驚かれるかもしれません。

ですから、プログラムに自然言語を理解する機能を実装することを考えているので無い限り、DateSpan?ではなくTimeSpan?を使うべきでしょう。しかもこちらはより効率的です。しかし、「ひと月」後を理解することが必要な状況ではDateSpan?が有用でしょう。 「ひと月」後は単にDateTime?.Now() + DateSpan?.Month()となります。

日付計算 †

日付について様々な操作を行うことができますが、すべてに意味がある訳ではありません。たとえば、日付に数を掛け合わせることには意味がありません。どちらかの時間間隔クラスに数をかけることは全く正当なことではあるのですが。

以下にできることを示します：

加算

a TimeSpan? や DateSpan? はDateTime? に加えることができます。結果は新しいDateTime?オブジェクトになります。また二つの同じSpanクラスのオブジェクトを加えあうことができます。結果はそれらのオブジェクトと同じクラスの新しいオブジェクトです。

減算

加算と同様のタイプの操作が許されています。さらに、二つのDateTime?オブジェクトの嵳がとれて、その結果はTimSpan?オブジェクトとなります。

乗算

a TimeSpan? と DateSpan? オブジェクトはいずれも整数をかけることができ、同じタイプのオブジェクトが結果となります。

符号

マイナス符号を付加することで、TimeSpan?やDateSpan?オブジェクトは同じ大きさで方向が逆のオブジェクトとなります。

時間帯についての考察 †

内部的には時刻はGMT(UTC)で保存されているが、おそらくそれぞれの人はその場所での時間帯で仕事をしているはずだ。この為に、 すべての DateTime?生成子と日付を分解する役割を担う設定子はそれらの値が其の場所毎の時間帯で表現された時刻であると仮定している。従って、DateTime?(1,DateTime?.Jan, 1970)はたまたま英国に居るのでなければ、DateTime? Epochに一致しない。

すべての日付成分（年，月、日、時、分、秒,...)を値として返すメソッドはデフォールトでは其の場所の時間帯での正しい時刻を 返す。従って、、一般的にいって自然な流れに従えば、自然で正しい結果が得られる。

これがあなたの望むすべてであれば、このセクションの残りの部分は飛ばしてよい。しかし、異なる時間帯で仕事をするなら、 このセクションを最後まで読む必要がある。

この(稀な)場合にも、DateTime? オブジェクトを生成するには其の場所の時間帯を使う必要がある。すなわち、DateTime?オブジェクトを生成／初期化する場合に使う時間帯、例えば太平洋標準時刻、を指定する方法は存在しない。　そうするためには、ToTimeZone?あるいはMakeTimezone?メソッドを呼び出して目的の時間帯に調整する必要がある。これらの関数の特別なばあいとして、ToGMTとMakeGMT が用意されている。これらは最も良く使われるであろうGMTでの日付を構築するために用意されている。

ある時間帯の値をオブジェクトに変換することなく引き出すこともできる。これは、時間帯が影響するすべてのメソッドの呼び出し時にTimeZone?引数を与えることで、達成される。日付要素を取り出すすべてのメソッドや日付の整形を行うようなメソッドがそのようなメソッドの例である。とくにFormat()に関連する一群のメソッドはTimeZone?パラメータを受け付けます。また、このメソッドはどのような時間帯での時間も簡単に印刷できます。

具体的な方法を示すのに残ったことはこれらのメソッドにパラメータとしてTimeZone?オブジェクトをどのように構築するかと言うことです。　明白な方法は、　時間帯のGMTからのオフセットの秒数を指定して構築することです。しかし通常は事前に定義された時間帯の名前を使います。あとは変換生成子が面倒を見てくれます。つまり、単に：

　wxDateTime? dt(...whatever...); printf("The time is %s in local time zone", dt.FormatTime?().c_str()); printf("The time is %s in GMT", dt.FormatTime?(wxDateTime?::GMT).c_str());

の様に書くだけです。

　夏時間(DST) の取り扱い †

DST (a.k.a. 'summer time')　はいつも微妙な問題を含んでおり、管理者が適切に設定してあるはずのオペレーティング・システム に任せるのが最良です。残念なことに、標準ライブラリでサポートされていない範囲の日付を取り扱おうとすると、自分自身で 問題を解決するしかありません。

指定された年のDSTの開始と終了の日付を計算するための関数が用意されています。また、ある時刻でDSTの期間であるか否かを判定 するための関数も用意されています。しかしこれらの関数が絶対的に正しいと仮定することはできません、結局のところこれらの関数は片手で数えられるくらい の国々でしか意味を持ちません（DSTを採用している国についての情報を歓迎します）し、それらの国々についても規則はいつでも変更となる可能性がありま す。

時間帯を取り扱う関数もこれらの関数を使っています、ですから時間帯を取り扱う関数も同じ制限を持っています。

DateTime? と休日 †

[TODO]

クラス †

Not done yet.

ID 定数 †

wxPythonは以下に示す定義済みのID定数を持っている：

コントリビュータ †

この文書に協力いただいた方々のお名前(姓のアルファベット順）

Individuals who contributed to this documentation (in order by last name):

   * Robin Dunn
   * Patrick K. O'Brien
   * Robert Roebling
   * Julian Smart
   * Vadim Zeitlin

ライセンス †

このドキュメントはwxWidgetsのドキュメントからの翻案として始められた。従って、wxWidgetsと同じライセンスが適用される。 以下にそのライセンスを示す。

This document began as a translation of the wxWidgets documentation. As such, it adheres to the same license, which is provided here:

               wxWindows Free Documentation Licence, Version 3
               ===============================================

 Copyright (c) 1998 Julian Smart, Robert Roebling et al

 Everyone is permitted to copy and distribute verbatim copies
 of this licence document, but changing it is not allowed.
   
                  WXWINDOWS FREE DOCUMENTATION LICENCE
    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

 1. Permission is granted to make and distribute verbatim copies of this
 manual or piece of documentation provided any copyright notice and this
 permission notice are preserved on all copies.

 2. Permission is granted to process this file or document through a
 document processing system and, at your option and the option of any third
 party, print the results, provided a printed document carries a copying
 permission notice identical to this one.

 3. Permission is granted to copy and distribute modified versions of this
 manual or piece of documentation under the conditions for verbatim
 copying, provided also that any sections describing licensing conditions
 for this manual, such as, in particular, the GNU General Public Licence,
 the GNU Library General Public Licence, and any wxWindows Licence are
 included exactly as in the original, and provided that the entire
 resulting derived work is distributed under the terms of a permission
 notice identical to this one.
 
 4. Permission is granted to copy and distribute translations of this
 manual or piece of documentation into another language, under the above
 conditions for modified versions, except that sections related to
 licensing, including this paragraph, may also be included in translations
 approved by the copyright holders of the respective licence documents in
 addition to the original English.

                           WARRANTY DISCLAIMER

 5. BECAUSE THIS MANUAL OR PIECE OF DOCUMENTATION IS LICENSED FREE OF CHARGE,
 THERE IS NO WARRANTY FOR IT, TO THE EXTENT PERMITTED BY APPLICABLE LAW. 
 EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
 PARTIES PROVIDE THIS MANUAL OR PIECE OF DOCUMENTATION "AS IS" WITHOUT
 WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
 PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF
 THE MANUAL OR PIECE OF DOCUMENTATION IS WITH YOU.  SHOULD THE MANUAL OR
 PIECE OF DOCUMENTATION PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
 NECESSARY SERVICING, REPAIR OR CORRECTION.

 6. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL
 ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
 REDISTRIBUTE THE MANUAL OR PIECE OF DOCUMENTATION AS PERMITTED ABOVE, BE
 LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
 MANUAL OR PIECE OF DOCUMENTATION (INCLUDING BUT NOT LIMITED TO LOSS OF
 DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
 PARTIES OR A FAILURE OF A PROGRAM BASED ON THE MANUAL OR PIECE OF
 DOCUMENTATION TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR
 OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.