めぬーなぱんくずりすとなちぃけぃいんたぁ

考え始めの思いつきのまま書きなぐるの巻。

ゆえにあえて意味不明なタイトルにした。「パンくずリスト@tkinter な Menu」の話、であったりなかったりするようなしないような、そんな話。

「パンくずリスト」は説明必要? コンピューターという箱の世界ではなくリアルの世界で言うところの「道に迷子にならないために、引き返し時のために何かを数歩おきに落としながら歩いていく」行為の話で、んで PC とかんな話だと「画面遷移の記録」とかをユーザに「引き返しやすくさせる」ために用意する、てわけだね。

この、まぁ「風習」というか慣習は WEB アプリで主として「叫ばれた/ている」もので、そして今でさえ「意識がほんとに高いところが作ったところ以外ではあんましお目にかからない」つぅヤツで、まぁそれを作り込むためのインフラも、欠けてるちゃぁ欠けている。少なくとも「パンくずリスト」というコモンコントロールが整備されてる例をワタシは知らない。

で「WEB アプリで主として」といった通りで、デスクトップアプリケーションのメニューごときで、まぁまずこれにお目にかかることはないわけだが、当然それを作るための部品もない。ただ…。

tkinter の場合、ちょっともっと致命的にバカげた問題があってなぁ…。「パンくずリスト」の表現方法は色々考えられるけれど、一般的なデスクトップアプリケーションのメニューの場合は、おそらく一番素直なのは「直前に選ばれたアイテムの見栄えが変わる」であろう。そうなんだけれども…。

やってみて初めてわかったんだけど、tcl/tk の API のかなり多くが「write only」なのだわ。致命的にかなりの問い合わせメソッドが欠落している。たとえば「追加したメニューアイテム数は?」に答えてくれないし、entrycget が返す値はオカシイし、「separator」と「command」などアイテムの種類が違うと entrycget が答えを返せないのに add 時はフラットに追加されてしまうし、など、とにかく色々致命的にチグハグ。ゆえに、要は「メニューの基本的な部分の構築を終了後」に「追加で色とか変えちゃるぜ」と思ってもこれは絶望的に困難なプログラミングを要求される、ので、「全部を一気に」という作り方しか出来ない。けれども「コマンドが選択された」かどうかは、「選択された」からこそわかるので、メニューを構築するコードと、「選ばれたぜっ」を記録するコードは、ソースコードテキスト的な意味でもランタイムの動作の意味でも「離れ離れ」になるのはこれは当然のこと、そして「問い合わせ手段に欠ける」ので、その離れ離れになったコード片どうしが相互に「お互いを知り尽くしている」必要がある。

まぁなんというか、こうやって日本語で説明すんのは難しいわな、なので、苦しみながらも「ひとまずリーフノードについてくらいは、前回選択コマンドを赤くしちゃれ」た実物をご堪能たれ。