api比較 ~ シンチラからの行取得
- ①QScintilla と ②QScintillaBase の api 速度比較
シンチラから特定の行の文字列をもらう関数について、①は使い方がよくわからなかったので従来は②でやってた
①は基本②のラッパだから速度は遅いはずだし
しかし②を非効率なコードで呼んでいれば①の方が速い可能性もある
- 2M以上の比較的大きめのファイルで実験した結果だが
①0.25秒②0.45秒
①の方が早い!!(゚Д゚)(゚Д゚)(゚Д゚)(゚Д゚)
俺のコードが非効率だったんだな・・・
- ②はc++ベースでわかりやすいけどpythonからは使いづらい
文字列を取得する際もまず行の長さを取得してその分のバッファを確保してからもらいに行く
バッファ確保のために ctypes を使っていた
①だと一つの関数で取得した文字列のポインタが簡単に帰ってきて、凄く簡単でpythonライク
こんな簡単な①の方がしかも速いとは・・
②で書いた私のコードがダメダメだったんだなあ・・・・
きちんと動いてはいたんだけど
がっかりでしたが、まあ、改善されたって事で
tabChanged
- try でエラー回避して落ちないようにしている部分のエラーメッセを全て表示しようと思い箇所をチェックしていて見つけた
- タブを閉じて無くなったときの動作をtryでエラー回避してたが、タブカウントがゼロなら何もせずに戻るように書き換えた
- try を覚えて何でもここに逃げてた時期があった。解決は簡単だったのに。コードを後で見直すとこういう発見が随所にあるのかもしれないなあ
QtreeWidget に model をセットする実験
- できませんでした ┐('д')┌
- アウトラインのビューはいろいろ使い勝手が良いのでモデルを差し替えて使いたかった、View のように
もともとWidgetはviewの派生だから可能だと思ったが、modelは持ってるもののWidgetに固有のようで、差し替えはできないようです。
残念、やはりwidgetをviewに変更しなくてはいけませんな
アウトライン解析ルーチンの移動
- ずっと課題にしていて手をつけられずにいたけどやっとできた
長いこと構想を練っていたためか日中codingして家で実装したらほぼ予定通り動いてくれた (・∀・)ノ
- TreeWidget を designer で TreeView に差し替え
これは簡単にできる。多分もとのクラスが同じだと良いんだと思う
レイアウトを変える必要も無いので楽
- 解析ルーチンをシンチラの派生クラスに移してmodelをクラスで保存
タブ切替時に都度再解析してたけどmodelを差し替えるだけにして高速化
- 行単位検索もTreeWidget を使ってたので書き換え
- その他細かい書き換えと、ついでにpy ファイルの解析ルーチンも実装
- TreeWidget のクリック処理を直し忘れてたんだがそのままでいけた、ラッキー
- 解析アルゴリズムの実験
アウトライン行の判定とかmodelへの子供の追加方法とか、少し変えて実験してみたけど高速化はナカナカ難しい
でももっとエレガントなやり方があるはずだって気はする
こういう作業を最適化って言うんだろうか?
考えるのは楽しい ( ´∀`)
解析ルーチン書換
- もっと効率的に書きたくていろいろ考えた
最初にアウトライン文字の個数をカウントして階層を決めて、不正なアウトライン記述はエラーではじくような仕様にしたら、再帰させなくても無限な階層に対応できた
- 時間も短くなったような気がする
プログラミングはやっぱり面白い、最適化を考え出すと終わりはないな
現在行をアウトライン項目で選択
- これはリロード時の状態復元としても使う
treeのアイテムをスキャンして該当のアウトライン行を取得して選択状態にする
- 解析ルーチンの階層を無限にしたので結構難しかったがすごく良いです
- 再帰、Recursionで実装
解析の方は再帰させなくても無制限に階層対応できたが読む方は方法が思いつかず再帰に逃げた
一応できたけど再帰させない方法も引き続き考えたい
お気に入りをTreeViewにしてフォルダに対応
- すっきりしたわ~(・∀・)ノ
- sql にしたかったけど編集が大変なのでテキストのままで良いことにするか
検索窓のリターンで検索、逆、行検索
- すごく使いやすい ( ´∀`)
keyPressEvent 以外でキーの状態を取得する
qsci からタブを切り替えれるようにした
- タブモノは普通に実装してるよな
PageUp だとわかりづらいので普通に alt + → に割り当てた
直感的でわかりやすい( ´∀`)