＊＊＊今後の課題

＊＊ GUI関連

- (一部完了)TreeViewにおけるPaste機能の実装
　既にDnDの実装があるので、同じことなんだが面倒くさ。DnDの場合と同様に、
　同ツリーからのPasteだけを取り敢えず実装した。というか、DnDも中途半端
　に実装したままだったことに今頃気付いても、やる気が起きないので、残り
　は0.6リリース後ということで……。

- 板一覧やブックマークのTreeViewでのDnDにおけるuri-listドロップの受取り
　→実装されてなかった件について……。

- DAT落ちスレへの対応
　→バージョン0.5以前のおちゅ〜しゃにはhtml化済の過去スレを読む機能が
　　実装されていたが、その時は●対応のついでっぽい気分で実装したので●
　　に対応していない現在では使用頻度が低すぎることも相まって、優先順位
　　が最低に近い。
　→●による読み込みにも対応すべきか？
　　旧バージョンでは対応していたが、事実上実装実験のために契約した●の
　　期限が切れた後、やはり必要性を感じていない●を再び買うのは憚られる。
　　――のべ１時間も使っていない希ガス。

- 掲示板外リンククリック時の挙動のカスタマイズ
　コマンドラインテンプレートの加工をScheme手続きに外注すべきかもしれな
　い。

- スレ一覧の一括表示モード
　構築が終わるまでGtkTreeModelをGtkTreeView(OchushaTreeSelectorView)か
　ら外しておくモードを設定可能にすべきか？
　→アクティブフォルダや既得スレ一覧のようなパターンでは長時間掛かる可
　　能性があるのでそこは選択可能にするのか？
　　↑選択可能なら何でもおkというのは思考停止という希ガス

- 履歴表示関連
　現状の貯めるだけ貯めて放置というのはどうか。

- 板一覧ツールバーとブックマークツールバー
　OchushaTreeMenuHelperのツールバー版のようなものを実装すればおk。

- 板一覧やブックマークの編集
　作りかけのまま放置されている件……。

- １ペインモード
　完全に１ペイン＋サイドバーというウェブブラウザ風GUIも有りだろう。

　スレ一覧もしくはスレのいずれかについて、キーボードフォーカスを持って
　いる、もしくは、最後にキーボードフォーカスを持っていた方を優先的に表
　示する（他方はタブラベル部分を残す位に縮めて表示する）偽１ペインモー
　ドというのも考え中。
　→こっちの方が使い勝手は良いかもしれず。

- ヘッドライン系のナイスな表示
　１ペインもしくは偽１ペインモードを実装したら、ヘッドライン系の表示を
　改良したい。ヘッドライン系の板は通常の板と同じようにスレ一覧が開けて
　もそれぞれのスレには>>1の分しかレスがない。こんなものにアクセスする
　のは余程の変わり者だけ。
　→スレっぽく表示する場合、見た目がスレっぽくても内容的にはスレ一覧相
　　当なのでスレペインには表示したくないが、１ペイン的なモードが無いま
　　まにスレ一覧ペインに表示しても使い物にならない可能性が高い。

- 書き込み関連
　SETTING.TXTを読んで、チェックできるエラーは自前でチェックすべき。

- Schemeでキーバインディング
　GTK+的手法で個別のWidgetにキーバインディングを設定するのでは、実現可
　能な機能が限定され過ぎる。おちゅ〜しゃ的にインテリジェントな機能を設
　定するためには、やはりschemeの出番だろう。key_press_eventのハンドラ
　からscheme関数を呼び出し、その関数で何かをさせるという流れになるが、
　scheme関数の定義用にGLib/GDK/GTK+関連関数のschemeバインディングが必
　要になるし、その他諸々を考えると面倒くさ。

- デバッグコンソールの表示内容の選別
　メッセージの種別により表示・非表示を調整できるようにしたい。
　→メッセージの出力側も調整が必要。

- (完了)ネットワークアクセスの状況をもう少し真面目にアイコンに反映させる
　アイコン表示が目立つようになったおかげで、面倒だから適当に処理してい
　るアクセス初期段階の状態をアイコンに反映させたくなってきた。
　ネットワークアクセスは全て専用のスレッドで行っているが、例えばスレ一
　覧の更新などは「板を開く」、「アクティブフォルダを開く」などにより同
　じ板の更新を複数の視点から同時に行い得るため、排他処理目的と同時に無
　駄なアクセスを削減するために同じ板へのアクセスは最初にアクセスし始め
　たスレッドに一任し、後続のスレッドは先行スレッドが解析した結果を貰う
　仕組みになっている。

　GUI経由で例えばある板を開いた時に、その「板を開く」というアクション
　の結果、ネットワークアクセスが始まるのか既に別スレッドでアクセスして
　いる最中なのかを追い掛けるのは面倒だし、手間が掛かる割に貰いが少ない
　ので、現在は何の検討もしていないが、「板を開きスレ一覧のデータを読み
　込むスレッド」が「スレ一覧の表示の準備をするスレッドがアクセス状況を
　知るためのコールバックを仕込む」前にDNSを引き終え、connect(2)システ
　ムコールを発行してしまうと、メインスレッドではconnect(2)成功後、デー
　タの読み込みが始まるまで状況の変化を知ることができない。結果として、
　connect(2)まで進んでいることを知らないが故に、アイコンが何時まで待っ
　ても本来アクセス開始前状態を表す「時計」表示だったり、何のアクセスも
　していないように見えたのに、突然エラーの「×」印になったりする。

　コールバック設定時（直後）に、現状を知るためのAPIをそこかしこに用意
　しておくべきか……。

- (完了？)メニューバー右端のネットワークアクセス状況アイコンの挙動の修正
　現在はおちゅ〜しゃ全体でネットワークアクセスがあるかどうかを示してい
　る。これはステータスバーを見れば判るので、現在の（キーボードフォーカ
　スを持つ）Viewのタブラベルに付いているアイコンと同じ情報を表示する方
　が便利かもしれず。
　→ペインに表示されているページが１ページの場合には、デフォルトではタ
　　ブブックマークが表示されないため、エラーが起こっていても気付き難い
　　という状況を解決するのには便利か？
　↑MainWindowで現在の（キーボードフォーカスを持つ）ViewがTabLabelなタ
　　ブラベルを持っている場合に、label->get_widget()で得られる
　　OchushaIconLabelオブジェクトの"notify::pixbuf",
　　"notify::pixbuf-animation","notify::stock"辺りを監視して、メニュー
　　バー右端に表示すべきモノを決めるという方針で実装できそう。
　　→実装するだけなら可能だが、スレ一覧にキーボードフォーカスを与えた
　　　ままスレを順に読む……という比較的ありがちな使用方法を考慮すると、
　　　この方針ではスレ更新の失敗を知ることができない。もっと良い在り方
　　　が無いものか……。
　　　→ThreadlistTabsやThreadTabsなGtkActionのためのGtkComboBoxに現在
　　　　選択されているタブのアイコンと同じものが表示できたら良くね？
　　　　↑この方針による実装を評価中。

- (評価中)スレタイの短縮表示
　板名は短縮名をプロパティで設定……というので十分だし、適当な規則で自
　動的に短縮というのには向いていないだろうことが想定できた。が、スレタ
　イの短縮名をユーザに一々設定させるというのは有り得ない設計だろう。そ
　れなら、単純に先頭からn文字で打切りとかになっている方がマシだ。
　→これはやはり、scheme関数任せにするのが良さそう。scheme関数の実装用
　　便利関数として、特定の文字列が「いわゆる半角文字」換算で何文字分に
　　なるのかを判定する関数辺りは用意しておくべきだろう。
　↑0.6リリース前に実装しようと思っていたが、前項目の「GtkComboBox」に
　　アイコン表示関係でThreadlistTabsやThreadTabs関連のGtkComboBox周辺
　　に手を入れる予定なので、それまで先送り。

　本当は、タブラベルのように表示できる分だけ目一杯表示させて、残りは勝
　手に切れるというのを標準状態にしたいのだが、GtkComboBoxかGtkToolItem
　もしくはGtkToolbarの仕様上無理っぽい――「完全に表示できる余地がない」
　場合「完全に非表示」になってしまう。

　GTK+のウィジェットをちょろっといじるくらいでは簡単には済まなそうなの
　で、表示される文字列の方の短縮を実装する。プロポーショナルフォントが
　使われている場合には結果がイマイチになる可能性もあるが、基本的には
　「（いわゆる）半角文字相当でn文字分を表示する」という方式になるだろ
　う。この「n文字分」をどうスレタイから抜き出すかについても、いくつか
　の方針が考えられる。例えばn文字抜き出す前に、無駄な部分を削除したり
　適当に加工することも考えられる。

  (1) 【】や[]などサブタイトル的に使われる部分を削除してからn文字抜き
　　　出す。続き物スレの場合、PartN的な部分が後ろのサブタイトル後に付
　　　いているパターンも良く見掛ける。
　(2) ●○▼▽▲△■□◇◆☆★のような記号類を削除してからn文字抜き出
　　　す。スレ一覧で目立つように……とかの理由だろうが、少ない文字数に
　　　情報を残す目的なら、この手の飾りは真っ先に削除して良いだろう。
　(3) 「　」（いわゆる全角スペース）を「 」（いわゆる半角スペース）に
　　　置き換えてからn文字抜き出す。また、連続する空白文字は1文字に変換
　　　しておく。スレ一覧でセンタリング的なことをしているスレタイも時々
　　　ある。
　(4) 「いわゆる全角英数字」を「いわゆる半角英数字」に置き換えてからn
　　　文字抜き出す。

  n文字の抜き出し方にもいくつかある。
　(1) 先頭からn文字抜き出す。
　(2) 先頭から(n - 3)/2文字と末尾から(n - 3)/2文字抜き出し"..."で連結。
　　　→もちろん、前と後ろを同じ比率にする必要はない。前半はスレの種類
　　　　を識別するのに有効だし、後半は続き物のスレだったりするとPartN
　　　　的な文字が入っているのでそれぞれ何かしらの意味はあるだろう。後
　　　　半部分を短めに――という選択肢もありうる。フォントの種類によっ
　　　　ては"..."を３文字相当と計算するのは多すぎる気はするが、そこはn
　　　　文字の方を調整する方が無難だろう。
　(3) 末尾からn文字抜き出す。
　(4) サブタイトルや飾り記号抜きを適用するなら、タイトルの中間部分をn
　　　文字抜き出すってのは使い道無しって気がするな。

　n文字という部分はGUIで簡単に変更できるようにしておき、それに加えて、
　上に述べたようなアルゴリズムをSchemeで実装しておき、それも選択できる
　ようにする……というのが、最近のおちゅ〜しゃ的なUIの仕様だろう。

　とりあえず、スレタイの加工をScheme手続き任せにしてみる実験。
  GtkComboBoxに表示するスレタイは
  (abbreviate-thread-title thread-title)
　で得られた文字列とする。

　→やってみたところ、予想してはいたが「n文字」みたいな設定はイマイチ
　　だなぁ。ツールバーから全部消えるよりはましだが、隙間があるのに表示
　　されないってのも残念な感じ。とはいえ、これ以上手間を掛けるのも何な
　　ので、暫くはこれで放置。

　　多分、アルゴリズムの工夫だけでももう少しやりようはある。例えば、い
　　わゆる半角文字でもMのように幅広になりがちのヤツを特別扱いにすれば、
　　少しはましになるはず。



＊ その他

- (大体完了)サーバ移転時の対策
　→板一覧の更新、もしくは、スレ一覧を開いた時に判明する場合に関しては
　　対応した。ブックマークなどからスレを直接開いた時に初めて移転を検知
　　する場合というのもあり得るが、その場合、移転先の追尾が面倒なので暫
　　く放置する予定。

- (完了？)キャッシュの管理
　ため込む一方なのは通常まずい。
　→画像キャッシュに関してはバージョン0.5の頃から自動化されている。
　→DATファイル関係も手動で消すことは可能になっているが、容量制限とか
　　は面倒なのでやっていない。実装的には画像キャッシュと同じ実装を「一
　　時キャッシュ無し」という設定で使っているので、容量もしくはファイル
　　数による管理にすることは可能だが、これはきっと使いにくいし、「残し
　　ておきたいスレを残すためにユーザのアクションが必要」という仕様は２
　　ちゃんねるブラウザの在り方としては正しくない。

- DATファイルのインポート機能
　GUI/CLI共に必要……かも？

- DATファイルを開くCLI
　→インポート機能も必要だが、既におちゅ〜しゃの管理下にあるDATファイ
　　ルのパス名から対象のスレを開くCLIが有った方が良さげ。

　　例えば全文検索エンジンのような外部ツールが~/.ochusha以下を漁り、
　　~/.ochusha/cache/以下に収まっているDATファイルがユーザの目的にマッ
　　チする何かを含んでいると判断した時に、そのパス名を引数としておちゅ〜
　　しゃを起動するだけでスレが読めれば便利だろう。

　　外部ツールが~/.ochusha/cache/以下の*.DATファイルがおちゅ〜しゃの持
　　つキャッシュであることを知っていれば、そのパス名から掲示板のURLを
　　合成することは可能だし、その場合、例えばそれが文字列検索の結果であ
　　るなら「マッチした行番号がレス番号に相当する」などといった知識を元
　　に更に便利なUIを作れるし、パス名からスレのURLに変換することにより、
　　現状のおちゅ〜しゃのままで対応できるが、その事実は「DATファイルを
　　開くCLI」の必要性を否定するものではない。

- ブックマークにStartupフォルダを追加
　起動時に登録しておいたページが自動的に開かれる――というUIは、似たよ
　うなことを目的として、セッション復帰時でもないのに、「前回終了時のタ
　ブを復元する」よりもより自然な振る舞いという気がするので実装したい。
　→ユーザ的にはわざわざ登録する方が面倒なのは明らかだが、アプリの振る
　　舞いとして「新しく起動した」アプリが前回終了時の状態になるのは美し
　　くない。

- ネットワークプロファイル的なもの
　低速回線用と高速回線用で「画像ダウンロード」の有無を変更したり、プロ
　キシを切り替えたりできた方が良いかもしれず。

- 画像キャッシュの取り扱い再考
　→保存したやつ、もしくは、無制限を設定して溜め込んだものを一時キャッ
　　シュに戻すことも考えたい。