プログラムの「詰め」というのは、とにかく手間と時間が掛かる。大体、中心となる部分を作るのの10倍以上の時間が掛かるのではないだろうか。プログラムを使い物にするにはどうしても必要な作業のだが、退屈だし疲れるので、余り好きではない。それでも、なかなかうまく行かなかったことを打開するような、ちょっとしたアイデアがひらめくことがあって、それが本当にうまく行った時は楽しい。だから、いじりだすとなかなか止められない。仕事と違って、納期も予算もないのが困るw

一方、世の中には、すごいアイデアを思い付いたら、素早く目を引くデモ的な物(ポップ音楽だったら、サビとかデモ版)を作って、有名になったりお金をせしめたりしたら手放して(どこかに売って)、トンズラする(あるいは、別の物を作り出す)、スマートな人が結構居るようだが、無責任で嫌いだ。確かに、いいアイデアを出せるのはすごいと思うが、「最初にちょろっと書くのは誰だって楽しいんだよ!」とか「もう少し面倒見ろよ」と言いたくなる。

という訳で、日々続けているGPMDP (Google Play Music Desktop Player)の改良(もはや改造と言った方がいいだろう)は大分いい感じになってきた。まだ詰め切れていない点や不具合や抜本的な改良案もあるのだが、おおよそ7.5割くらいの出来になって、普通に(これには「変わったことはしてはいけない」という意味もあるw)音楽を聴けるレベルになった。具体的には、GMBだけで聴いている時と使い勝手での違和感がほとんどなくなった。例えば、GMBのリモコンで操作できるので本当に便利だ。実際に、昨夜からは、(実装・修正するだけじゃなくて)GPMの曲を聴くのに使っている。

問題だったユースケース(GPMDPをどういうふうにGMBと統合・機能分担して使うか)も、作業しているうちに大分詰められた。基本的には、GPMDPは曲の検索に使い、GPMDPの再生ボタンを押したら、実際の再生や再生の操作はGMBで行おうと思っている。まだ完全にシームレスになったとは言えないが、なかなかうまく統合できたと思う。

今週はさまざまな改良や修正をしたのだが、主にGPMDPとGMB (gmusicbrowser)との連携動作(例: 曲の追加や変更の同期)に関するものなので、見た目では、先週と比べて目立った違いは余りない。大きな違いは、(実際に曲を再生している)GMBで次の曲に移ったことがGPMDPにも伝わって、曲情報やジャケット画像が更新されることだ。以下にデモ動画を置くので、興味のある方はご覧頂きたい。

画面左半分はGMBの、右半分はGPMDPのウインドウである。GMBで再生中の曲が次に変わると、少ししてから(その次の曲の取得と処理の時間: これは如何ともし難い)GMBにその次の曲が追加され(画面左下、5曲目)、GPMDPの曲情報やジャケット画像(画面右中央)が更新される。

下の動画は、力技でやっているうえに、まだバグがあって、(いつ何が起こるか分からず、)ドキドキする機能なのだが、GMB(画面左下)でリスト中の前の曲をダブルクリックして移動した場合でも、GPMDP(画面右中央)も戻るようになっている(戻るのが遅いのは愛嬌w)。もちろん、取得されている範囲で、先の曲に進むこともできる。

リストの最後(7曲目)に2曲目の曲が追加されるのはバグである。難しい。。。

冷静に考えれば、再生中の曲のGPMDPへの同期なんて、音楽を聴くには不要な機能で、本当に飾りなのだが、「おもしろそうで、不可能でないならやってみたい」という、技術者の無駄なこだわりがあって実装したw

(10/1 6:38 わずかに修正)

 

PS. プレーヤーにGMBを使ったのは正解だった。最初は単純な再生だけを考えていたので、alsaplayerなどの軽いものにしようかと思っていたのだが、機能的に不十分な点があったので、最初からGMBで試した。また、GMBはコマンドラインにPerlのプログラムを指定して実行できるという、夢(麻薬)のような機能があり、それでGMBの内部データにアクセスできるので、かなり役に立っている。もう開発は停まっているようだが、セキュリティホールになるので、公開版に入れ続けるのは難しいかも知れない。

PS2. かなりハードルが高いのだが、将来的には、GPMDPじゃなくて、ブラウザのGPMのページから直接GMBと連携できないかと思っている。GPMDPが必要なのではなく、GPMのページ内の要素にアクセスするために使っているだけなので、ブラウザのアドオンか何かでできるのではないだろうか。

同時に、可能な限り機能を外部に出して、JavaScriptの部分を減らして開発効率を向上させ、GPMのページ構成になるべく依存しないようにもしたい。

とは言え、本当にやりたいのは音楽を聴くことなので、苦労してそこまでやることもないかとも思っている。

(10/1 17:44追記) と書きつつも、(だるくてドライブを止めたため、)暇だったので、ちょっとだけ試してみた。一番最初に気になった、GPMのページ中の再生ボタンを押したらGMBに曲を送れるようにする時に必要な、ボタンのイベントハンドラを変更できるかを試した。

最初は、安直に、ローカルのHTMLでiframeでGPMのトップページを読み込んで、JavaScriptで書き換えればできるだろうと思ったのだが、駄目だった。それから、いくつかのライブラリやAJAXやjQueryまで試したが、駄目だった。

どうも、セキュリティ上の制限のようで、ローカルのファイルからGPMのサイトを呼び出すのが駄目なようだ(おそらく、元がローカルファイルじゃなくても、サイトをまたがるようなことが駄目なのだろう)。それを回避したかったのだが、できなかった。この制限は「同一生成元ポリシー」というものらしく、かなり昔からあるようだ。

それで、一旦、ローカルのHTMLを使うのは諦めて、(GPMDPを改造して使う前提で、)GPMのページ中の再生ボタンのイベントハンドラを変更できるかを試した。JavaScriptには疎いので、それすらも苦労したが、できた。getElementById()で再生ボタンの要素を探して、onclickメンバにハンドラを設定すれば良い。以下のようにすると、GPMの再生ボタンを押すと関数click_func()が呼ばれる。

var elem= document.getElementById("buttonContent");
elem.onclick= click_func;

function click_func() {...}

onclick(onClick)は属性ではないとのことで、setAttribute()で設定しても呼ばれないことに気付かず、苦労した。あと、ボタンの本来のハンドラが依然として有効(どうやっているのか不明)なのがちょっと気に入らないが、まあ、細かいことだ。

(10/2 7:08追記) その後、GPMの再生につながるボタンは山ほどあるので、それらを全部書き換えるのは現実的でないことに気付いた。それらの呼び先を修正するのも困難なので、やっぱり、低レベルなところはGPMDP(実際には、その下位のライブラリ)に依存するのがよさそうだ・・・

  •   0
  •   1

コメントを書く

名前    

メール 

URL