pythonでfoobarのalternativeを作る 35 version 11
:追加された部分
:削除された部分
(差分が大きい場合、文字単位では表示しません)
pythonでfoobarのalternativeを作る 35
190918
# UI 改善
- ウィジェットの配置にスプリッタを使った
DB表示のアウトラインビューだが、文字数が足りなくて横幅を広げようと思ったら動かなかった(・∀・)ノ
ここの幅は固定にしてたんだなあ・・・
で、スプリッタに直した
- 最近ようやくdesignerの使い方が少しわかってきた
**特に後から直す方法が重要ですよね**
レイアウトの使い方、特に破棄のしかたが難しいんだけど少し慣れてきた
- スプリッタを使うってことはその設定を保存することにもなる、それはこれからだが scieditor で実装してるので簡単だと思う
こういう部分は Qt は凄く使いやすく考えられてると思う
190921
# 設定の保存
- はまった (¯―¯٥) (¯―¯٥)(¯―¯٥)
設定系いじるのは難しいわ、保存と読み込みが、完全新規のほうがまだ良い
一部だけ新しくすると鬼のように難しい
- 配布されてるソフトってこういうところも考えて作られてるんだろうな
- Linuxで起動させれるか自信ない ┐('д')┌
190927
# 起動高速化実験
メインのDBロードに時間を要していると思われる
pythonのstringのドキュメントを読んでたらcasefoldなるメソッドを見つけた
普通のCaseSensitiveとはやや概念が異なるようだ
コードをいじって時間を計測してみた
①現状 if item[0] .lower() != l[0].lower()
②sqliteの関数で小文字に揃える select lower( artist )
③str.casefold を使う
二回計測したデータだがいずれもそれほどの時間短縮にはならなかった
それよりも、②だとモデルにセットするデータそのものが全て小文字になってしまい格好が悪かった
①だと比較の時に小文字に合わせてるだけでセットする文字自体は大文字混じりのまま
肝心の③だがうまくいかなかった、全て別の文字列として読んでしまう
ツリーには同じ文字列が違うアーティストとして列挙されてしまった
原因不明 ┐('д')┌
実験は失敗、結局今のコードのままにした
まあ仕方ないよな
起動が遅いのは何とかしたいよなあ
treeで1秒くらいはかかってるから別スレッドにすれば起動は速くなるかな??
考えたらdef のルーチンにしてあるから
self.reload() を
```
import threading
th = threading.Thread( target = self.reload , args=(self) )
th.start()
```
とするだけか??
-----
---->[pythonでfoobarのalternativeを作る](https://mimemo.io/m/3kyw8o3neWG6Lrg)
190918
UI 改善
- ウィジェットの配置にスプリッタを使った
DB表示のアウトラインビューだが、文字数が足りなくて横幅を広げようと思ったら動かなかった(・∀・)ノ
ここの幅は固定にしてたんだなあ・・・
で、スプリッタに直した - 最近ようやくdesignerの使い方が少しわかってきた
特に後から直す方法が重要ですよね
レイアウトの使い方、特に破棄のしかたが難しいんだけど少し慣れてきた - スプリッタを使うってことはその設定を保存することにもなる、それはこれからだが scieditor で実装してるので簡単だと思う
こういう部分は Qt は凄く使いやすく考えられてると思う
190921
設定の保存
- はまった (¯―¯٥) (¯―¯٥)(¯―¯٥)
設定系いじるのは難しいわ、保存と読み込みが、完全新規のほうがまだ良い
一部だけ新しくすると鬼のように難しい - 配布されてるソフトってこういうところも考えて作られてるんだろうな
- Linuxで起動させれるか自信ない ┐('д')┌
190927
起動高速化実験
メインのDBロードに時間を要していると思われる
pythonのstringのドキュメントを読んでたらcasefoldなるメソッドを見つけた
普通のCaseSensitiveとはやや概念が異なるようだ
コードをいじって時間を計測してみた
①現状 if item[0] .lower() != l[0].lower()
②sqliteの関数で小文字に揃える select lower( artist )
③str.casefold を使う
二回計測したデータだがいずれもそれほどの時間短縮にはならなかった
それよりも、②だとモデルにセットするデータそのものが全て小文字になってしまい格好が悪かった
①だと比較の時に小文字に合わせてるだけでセットする文字自体は大文字混じりのまま
肝心の③だがうまくいかなかった、全て別の文字列として読んでしまう
ツリーには同じ文字列が違うアーティストとして列挙されてしまった
原因不明 ┐('д')┌
実験は失敗、結局今のコードのままにした
まあ仕方ないよな
起動が遅いのは何とかしたいよなあ
treeで1秒くらいはかかってるから別スレッドにすれば起動は速くなるかな??
考えたらdef のルーチンにしてあるから
self.reload() を
import threading
th = threading.Thread( target = self.reload , args=(self) )
th.start()
とするだけか??