「動く」から「使える」へ
第2回では、
最小限のコードを動かしながら、
tkinterが「呼ばれて動く」イベント駆動の仕組みであることを体感しました。
ボタンを押すと処理が呼ばれる。
時間が来ると処理が動く。
その一つひとつは小さな出来事ですが、
そこにはすでに「アプリの原型」があります。
そして第3回では、
その原型に状態を持たせてみます。
画面に表示されている情報を覚え、
操作によってそれが変化する。
この瞬間、tkinterは
「部品を並べたGUI」から、
振る舞いを持つアプリへと変わります。
第1章：状態を持つ、ということ
tkinterでボタンを押して、何かが起きるのは、第2回で体感しました。
しかし、その処理が
前と同じ結果しか返さない うちは、
それはまだ「反応」であって、
アプリケーションとは少し違います。
アプリらしさが生まれるのは、
前の出来事を覚えているときです。
「状態」は、記憶のこと
プログラムにおける「状態」とは、
難しい概念ではありません。
- いま何回クリックされたか
- 表示はONかOFFか
- 前回はどちらを選んだか
こうした 記憶そのもの が状態です。
tkinterは、
イベント駆動という世界の中で、
この状態を静かに持ち続けることができます。
状態を1つだけ持ってみる
まずは、
とても小さな状態を1つだけ持ってみましょう。
import tkinter as tk
count = 0
def on_click():
global count
count += 1
label.config(text=f"count: {count}")
root = tk.Tk()
button = tk.Button(root, text="click", command=on_click)
button.pack()
label = tk.Label(root, text="count: 0")
label.pack()
root.mainloop()
ボタンを押すたびに、
表示される数字が変わります。
ここで起きているのは、
- ボタンが押された
- 関数が呼ばれた
- 前の値を覚えたまま更新された
という流れです。
ここで何が変わったのか
第2回までとの違いは、
状態が残っていることです。
- クリックのたびに世界が少し変わる
- その変化が、次の反応に影響する
この瞬間、
tkinterは「ただのGUI」から、
振る舞いを持つアプリへと変わります。
第2章：表示は、状態の写像にすぎない
状態を持つと、
もう1つ大事な視点が見えてきます。
それは、
表示は状態の結果でしかない
という考え方です。
表示を直接いじらない
初心者の頃は、
- ボタンを押したら
- その場でラベルを書き換える
という発想になりがちです。
それ自体は間違いではありません。
ただ、アプリとして考えるなら、
視点を1つだけずらします。
状態 → 表示、という流れ
考え方はこうです。
- 状態を更新する
- 状態をもとに表示を決める
つまり、
表示は、状態を映しているだけ
先ほどのコードも、実はそうなっています。
count += 1
label.config(text=f"count: {count}")
表示は、count という状態を
文字列にして見せているだけです。
なぜこの考え方が大事なのか
この構造を意識すると、
- 表示を増やしても混乱しない
- ロジックと見た目が分離できる
- 「何が起きているか」が追いやすい
というメリットが生まれます。
これは、
規模が大きくなったときに
効いてくる設計です。
tkinterが「アプリ」に見えてくる瞬間
状態を中心に置いて眺めると、
tkinterの世界はこう見えてきます。
- イベントは、状態を変えるきっかけ
- 表示は、状態の結果
- mainloopは、世界を保つ土台
ここまで来ると、
tkinterは単なるGUIツールではなく、
小さなアプリケーション基盤として
自然に理解できるはずです。
第3章：状態が変わると、画面も変わる
ここまでで、
tkinterが「呼ばれて動く」プログラムであること、
そしてイベントによって処理が実行されることを体感してきました。
次に見ていきたいのは、
そのイベントが「何を変えているのか」 です。
状態とは「いま、どうなっているか」
アプリケーションにおける「状態」とは、
難しいものではありません。
- カウントがいくつか
- ONかOFFか
- 表示中か、非表示か
こうした
「いま、どうなっているか」
を表す情報のことです。
tkinterでは、
この状態をPythonの変数として持ち、
イベントが起きたときにそれを書き換えます。
状態を書き換えると、画面が変わる
たとえば、
ボタンを押すたびに数が増える場合。
- 数字（状態）を1つ持つ
- ボタンが押されたら、その数を更新する
- 更新された数を、画面に反映する
この流れだけで、
プログラムは一気にアプリらしくなります。
重要なのは、
画面を直接「動かしている」のではなく、
状態を変えた結果として、画面が変わっている
という点です。
イベントは「状態を更新するきっかけ」
ここで、
イベントの役割がよりはっきりしてきます。
- ボタンが押された
→ 状態を書き換える
→ 表示を更新する
イベントは、
画面を直接制御するものではありません。
状態を更新するための合図です。
この考え方に立つと、
- 処理の見通しが良くなる
- コードの役割が分かれ始める
- 振る舞いを追いやすくなる
といった変化が起きます。
「状態を持つ」だけで、設計が変わる
状態を意識し始めると、
tkinterのコードの書き方も自然に変わってきます。
- 何を表示するか
- いつ表示が変わるか
- どのイベントが関係するか
これらを
「処理の流れ」ではなく、
状態の変化として捉えられるようになります。
この瞬間、
tkinterは単なるGUIライブラリではなく、
小さなアプリケーションの器になります。
次に見えてくるもの
ここまでで、
- イベントは「呼ばれる」
- 処理は「反応として書く」
- 画面は「状態の結果として変わる」
という構造が揃いました。
次に見えてくるのは、
- 状態が増えたらどう整理するか
- 表示と処理をどう分けるか
- アプリとして育てるための考え方
です。
第3回の最後では、
これまでの3回を通して見えてきた
tkinterの全体像を、一度整理してみましょう。
まとめ ― 状態を持つと、アプリになる
第3回では、
tkinterに「状態」を持たせることで、
単なるGUIの集まりが、ひとつのアプリとして振る舞い始めることを見てきました。
ここで扱った状態は、
難しいものではありません。
数値や文字列、真偽値といった、
ごく普通のPythonの変数です。
それでも、
その状態を基準に表示を変え、
イベントによって更新するようになると、
tkinterのプログラムは
「その場その場で反応する」だけの存在から、
文脈を持って振る舞う存在へと変わります。
第1回から第3回までを振り返ると
- 第1回：
tkinterは「待つ」世界で動いている - 第2回：
イベントは「呼ばれて」実行される - 第3回：
状態を持つことで、流れが生まれる
という一貫した流れがありました。
どれも新しい文法ではなく、
新しいライブラリでもありません。
考え方の置き場所が少し変わっただけです。
ここまで来たら、もう「怖くない」
状態を持ち、
イベントで更新し、
その結果を表示に反映する。
この基本形が見えていれば、
tkinterはもう「分からないGUI」ではありません。
あとは、
どんな状態を持たせるか、
どんなイベントで更新するか、
その組み合わせを考えていくだけです。
次に進むなら
この先は、いくつかの方向に広がっていきます。
- 状態が増えたときの整理の仕方
- 表示とロジックの分け方
- 少しだけ大きなアプリ構成
どれも、
今回までの内容の延長線上にあります。
tkinterは、
小さく始めて、
少しずつ育てていくのが一番合う道具です。
焦らず、
「今わかっている形」を大切にしながら、
次の一歩を踏み出していきましょう。
