![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
・JuK on KDE
KDE な環境だと，MP3 ファイルのプレイヤーがうまく動かないので， 少し調べてみた．
結論的には，MP3 ファイルのファイル名が日本語だと正しく処理できないらしい． UTF-8 だと何とかなるのだろうかと試してみたけど，ファイルを正しく認識してくれなかった。 でもこれは kdelibs にあてたローカルパッチの影響の可能性もありそう．
試しにいくつかのファイルのファイル名を英数字だけにしてみたら，ID3 タグは 日本語(UTF-8)でも問題なく再生できるようになった．
JuK の場合，ファイル名というのはあまり重視してなく，曲の管理はID3タグの レベルでやっている感じなので(ファイル名からタグファイルを推測するような機能もある)， ファイル名は track01.mp3 とかにして，タグファイルで曲名や演奏者の情報を 記録しておくような使い方を想定しているのかも知れない．
面白いな，と思ったのは，上図で JuK の下の方にある黒いボックスの「今聞いているもの」という Plasmoid(デスクトップアプレット)に現在再生中の曲名等が表示できること．
GNOME の rhythmbox では，アプリである rhythmbox 自体でファイルを読んで再生するみたいだけど， KDE の JuK だと，ファイルを開いたり，そこからデータを読み込んだりするのは よりシステムに近いところにある Phonon という機能に委ねていて，Phonon に接続することで， 他のアプリからもリアルタイムで現在再生中のデータの情報が取れるようになっているらしい．
GNOME だと，それぞれの機能は各アプリが持って，共通部分は最小限に留めている感じがするけど， KDE だと，共通のライブラリやフレームワークに必要な機能を統合して， 各アプリの処理はコンパクトにまとめるような設計になっているように感じる．
このあたりは設計思想の違いだろうけど，GNOME の方がより疎な結合で KDE はずいぶん密な結合な印象． KDE が(機能の継承とかが容易な) C++ で開発されているのも理由の一つだろうけど， 開発者が世界中に散らばっている GNOME と，ヨーロッパが中心の KDE という違いもありそうな気がする．
システム全体としては密結合の KDE の方が進んでいる印象だけど，その分， 日本語ファイル名が正しく処理できない問題も， どこでトラぶっているのかがよく分からないという問題はあるなぁ． 日本語ファイル名が正しく処理できない問題も，JuK のレベルではなく Phonon 以下のレベルで調べないとダメみたいで，簡単には追えそうにない．．
JuK.jpg