ympdのスタイル変更について

---

@パパリウス さま
取り急ぎ、５）optionで選択可能なテキストボックスへの消去ボタン対応についてご連絡します。
ちなみにネタ元はこちらです。

追加CSS

.searchclear {
    position: absolute;
    right: 5px;
    top: 0;
    bottom: 0;
    height: 14px;
    margin: auto;
    font-size: 14px;
    cursor: pointer;
    color: #ccc;
}

追加Javascript

    $('.searchclear').click(function(){
        $(this).parent().find('input').val('');
    });

クリアボタンを追加するinputタグはこのように記載
（今回のサンプルはsearchへのカテゴリ用です）

  <div class="btn-group">
  <input type="text" id="stype" class="run" list="genre-list" autocomplete="on" value="ANY"/>
  <span class="searchclear glyphicon glyphicon-remove-circle"></span>
  </div>

追加のCSS Javascriptはclassに対する指定のため、一括定義すれば全てのプラグインで使用可能でしょう。

先程の同一ページ内でのtableでの行移動についてちょっとサンプル見つけましたので
手元で実験出来る方はお試しいただけると幸いです。
（ページ内のテキストをエディタに貼付けして、PC内に保存してブラウザで開く必要があります。）

先の説明でも書きましたが、まずは当該アーティストまでのページを生成し、その後はこの方法で当該行まで飛ぶ形でイケそうですね。

@パパリウス さま
「ローカルの楽曲を一時的にRasPiに複写して再生」については、
NASに入れるまではないけどPCに入っている楽曲をsmpdで聴きたいというニーズに対応するためのものです（専用クライアントのCantataが対応していたため、結構便利でした）
クライアント側にHTTPサーバの機能があればsmpdにストリームとして流すことが出来ますが、
WebUIでその面倒を見るのは難しいため、
ympdのmongooseでファイルアップロードし、まずはRAM上に一時的に置くことを考えてみようかと。
↑
頑張ればSDカードに保存も出来るようになるかもしれませんね。

@sunatomo さん

おおー。これはいいですね。

inputの中に<span class="searchclear glyphicon glyphicon-remove-circle"></span>を書くだけで消去ボタン付きのテキストボックスにできるのは素晴らしいです。

この消去ボタン付テキストボックスを標準機能に加えたいのですが、例えばinputにsearchclearクラスを指定するだけで同様の機能を与えることはできますでしょうか。

form.htmlをできるだけシンプルに記述できるように工夫したいなと思っています。

ローカル楽曲の複写機能についても解説ありがとうございます。
プラグインとしてパッケージングし、appコマンドでインストールできるよう整備してみたいですね。

Terra-Berry DACプラグインは大掛かりなプラグインなので、SDイメージには同梱せず、appコマンドでインストールしてもらう形にまとめようと思っています。

@パパリウス さま

例えばinputにsearchclearクラスを指定するだけで同様の機能を与えることはできますでしょうか。

javascriptの記述は「searchclearクラスのあるタグをクリックした際、その親タグ内のinputの内容を消去する」という記述のため、inputでも大丈夫でしょう。
ただし、inputにsearchclearクラスの場合、cssは見直しが必要ですね。
（元々spanのglyphiconの×をクリックした前提のため）

jqueryの元定義のどこか（mpd.js?)に追加すればこれでWebUIのどこでも同じ動作をするでしょう。
ちなみに10-mpdのform.htmlを試しにテストで書き換えて見ましたが、Javascriptの方は各inputタグに対してspanを用意すればそれぞれのinputタグで初期化出来ました。
CSSについては親のdivタグのclassがcol-sm-8の場合は×アイコンがinputタグの後ろにはみ出したので調整が必要ですね(こちらはmpd.cssに追加でしょうか）。

あ、あと追加ですがCSSに以下のものを入れて頂けるとWebKit系のブラウザの場合にinputタグのオプション選択時に表示される▼を消すことが出来て見やすいですね。
（▼が消えてもoptionの候補は表示されます）

input::-webkit-calendar-picker-indicator {
      display: none;
}

画面幅を広げる試作中のものをご紹介します。

実際に行った事項は以下の通り
・最上部のボリウム・プラグイン操作のメニュー部はスタイル変更していません。
（この場合、私のPCのフルHDの画面ですと最大幅が１１４０ピクセルに強制的にされます）

・カバーアート以降の部分は「画面サイズ最大幅の5/6」です。（マージンなどは除く）
　実際にはスタイルを規定するBootstrapの仕様により最大幅の（10/12)になるようになっており、左から1/12分ずらす（中央寄せ）という指定がされています（ここの記述は以前と変更していません）。ざっくりの計算ですが1920*5/6 = 1600ピクセルですね。

　これまでは先のメニュー部と同じ幅ですから１１４０×5/6 = ９５０ピクセルまで縮小されてしまっていました。マージンを考えない場合、６５０ピクセルも稼げたということになります。

　なお、左右の画面切り替え領域幅は全画面の1/12（8.3%)で計算させています。

あとは左右の切替領域を画面解像度に合わせてさらに詰めるか、上部のメニューを下部と合わせるべきなのか考えてみたいと思います。

@パパリウス さま
業務連絡です。プラグインのinputタグへのクリアボタンについてですが、
css1本でWebKit系のブラウザ全般対応するようですのでこっちで行きたいと思います。
（対応しないブラウザをお使いの方は従来通り消して頂く方向で...）

bootstrap.cssの160行付近を以下の通り修正します。

}
/*input[type="search"]::-webkit-search-cancel-button,
input[type="search"]::-webkit-search-decoration {
  -webkit-appearance: none;
}*/
input[type="search"] {
  -webkit-appearance: searchfield;
}
input[type="search"]::-webkit-search-cancel-button {
  -webkit-appearance: searchfield-cancel-button;
}

プラグインのinputタグはtype="seach"に変更するだけです。

@sunatomo さん

アイデアをいただきありがとうございます。
試してみたいと思います。

もう一つ、使い勝手を検証中の案があります。
フォーカスしたタイミングで自動で消すという案になります。

diff --git a/src/js/mpd.js b/src/js/mpd.js
index 5577bd8..b5bd7e7 100644
--- a/src/js/mpd.js
+++ b/src/js/mpd.js
@@ -246,6 +246,16 @@ function activatePlugin(menu, icon, path) {
         $.get('/w' + $(this).attr('uri'), query,
           function(data) {$(target).val(data);}, "html");
       });
+      var input_text_list_val = "";
+      $("#plugin-form input[type='text'][list]").focus(function(e) {
+        input_text_list_val = $(this).val();
+        $(this).val('');
+      }).blur(function(e) {
+        if ($(this).val().length == 0) {
+          $(this).val(input_text_list_val);
+        }
+      });
+
       $("#plugin-form debug").append("<pre onclick='this.innerText=get_run_param();'></pre>");
       $("#plugin-form").modal();
     }

@sunatomo さん、お世話になっております。
私もCressonさんの案が実現されたら、より使いやすくなると思います。

@hiroget9 さま
書込は見ていましたが裏側で作業やっていてレス遅れました。
ご提案の件は実現するコンセプトは固まったので次の段階で実装までやってみたいと思います。
ただ"戻るボタン"何処に設置したら良いかなぁと
まだ結論出てませんが

@sunatomo さん、ご検討ありがとうございます、
人によって利便性が異なると思うのですが、私の場合、音源選択のボタンで、標準で元の位置に戻るのが良いかと。
使い勝手が人のよって異なるようでしたら、元の位置に戻るか、今の仕様にするかのオプションを設けることは無理なお話でしょうか？

WebUI改善の進捗について（2020−04−06現在）
１）キューモード時の楽曲情報表示修正について　済
　完了しております。

２）楽曲一覧の各カラム幅が揃わない点について　（ほぼ完了）
　上のテーブルヘッダーとその下の各楽曲表示行にはほんの少しズレがありますが、
　cssの記述統一で解消予定です。

３）各モード切り替えボタン領域の幅について　（個人的には完了）
　ボタン幅をウィンドウ幅の8.3%に修正済みです。
　 （これに伴い、通常表示ではウィンドウ幅の85.3%まで楽曲名のテーブルが広がっています）

４）キュー・プレイリストのNext/Prevボタン色修正　（個人的には完了）
　ダークモードの場合、他のボタン色に併せてあります。
　（本当は他のボタンはシェーディングありの２色構成なのですが、Next/Prevボタンは高さが狭いので現状の単色でも良いかと勝手に考えています）

５）テキストボックス消去の対応　（個人的には完了）
　パパリウス さまの方でも対応頂き実装いたしました
　（これでプラグインでのテキストボックスでオプション選択が非常に容易になりましたね）

６）楽曲情報のスクロール対応　（未完了）
　これ、少し時間を頂きたい。
　巷にあるmarquee対応プラグインをいろいろ試しましたが、
　以下のような機能を満足するものが無いです（自作するしか無いかなぁ）。
　
　・文字列数が表示領域を超えない場合はスクロールしない
　・スクロールは左に流れればよいが、文字列最後が見えたら少しだけ遅れて
　　文字列の先頭が右端から見える。
　　（さらに文字列の先頭が初期位置に到着したら、一度スクロール停止があればモアベター）
　・カバーアートモードでスクロールさせる場合は中心位置から、キューモードの場合は左寄り

７）楽曲ファイル埋め込みカバーアート対応　（今週より着手予定）
　本日libmpdclientのテストアプリ使ってみました。
　mpd ver 0.22以降ではreadpictureコマンドで埋込みカバーアートを標準出力に出すことが出来、リダイレクトでファイル書き出ししたら正常に見えることまでは確認出来ました。
　この機能を使って/run辺りに一時的にカバーアートを配置することは出来そうです。
　（多分私の実力では１週間レベルでコーディングが必要そうです）

８）ローカルファイルをRaspberryPiに複写
　mongoose（組込Webサーバ）の最新版をgithubからダウンロードしましたが、
ympd内蔵のものと比較しかなり変わっているようです。
　恐らく単純入替えでは済まなそう。

９）ブラウズ（フォルダ選択）時に上の階層に戻った場合、その楽曲名まで戻りたい　（一次対応完了）
　@Cresson さまほかご提案の件。パパリウス さまに対応いただきました。
　Next/Prevボタンを操作した場合の対応も仮で行いました。
　（現状はJavaScript内部変数のため、HTML書出し対応が望ましいかな）

という訳で、今後の個人的な優先順位としては
7） ＞ ９）の改良 ＞ ８） ＞ ６） というところになりますか。
（その他、不具合が認められれば修正対応は最優先で行います）。

WebUI改善の進捗について(2020-04-12 現在）
ステータスの変わったところのみ掲載します。
2)楽曲一覧の各カラム幅揃え　済

3)各モード切替ボタン領域幅　済
　パパリウス さまご指摘があり、最上部メニュー領域のみ従来と同じ表示方法に戻しました。
　（スマホなどのモバイル環境で幅が狭くなるため）

7)楽曲ファイル埋め込みカバーアート対応　（個人的には完了）
　libmpdclientのサンプルで画像ファイルを書き出しするテスト実行ファイルがありましたので、
　これの要領で楽曲切替時に当該楽曲から画像ファイルを抽出します（/var/lib/mpd/music/RAM上に書き出しします）。
　また、WebUIでは埋め込みカバーアートを最優先で表示させるようにしています。
　埋め込みカバーアートがない場合は従来の順次読込となります。
　（本機能はVer.1系で採用されたmpdのv0.22以降で対応する機能ですので、
　既存のv0.9にはフィードバック出来ません）

8)ローカルファイルのRaspberryPiへの転送
　WebUIで使用している組込Webサーバライブラリのmongooseの当該バージョン（v5.6）のリリースzipイメージがGitHubにありましたので、
　これをダウンロードしたところ、ファイルアップロードのサンプルがありました。
　このサンプルファルの記述を元にサーバ側にhttp POSTストリームを伝送し、保存が出来たところまでは到達しています。
　ただし、ファイルの後端部が重複していたり、「------WebKitFormBoundary」なるPOSTメッセージの先頭・後端メッセージがそのまま保存されているため、これを除去して保存する方法や、
届いたファイルが元のものと変わらないかの検証が必要です（もう少し時間がかかりそう）。

9)ブラウズ（フォルダ選択）時に上の階層に戻った場合、その楽曲名まで戻りたい　済
　私の方で実施していたフォルダービュー時のNext/Prevボタンの位置を
　記憶させる部分についてはHTML内部に属性値として書出ししましたので、
　WebUIの再読込を行わない限りはなくなることはないはずです。

ステータスを見てお分かりの通り、 8)が終わり次第 「6)楽曲情報のスクロール対応」実装方法検討でしょうねぇ。
（何らかの不具合を見つけましたら、そちらのfixは優先します）。

追伸：ver0.9向けのパッチについて
Next/Prevボタンが表示されない件、0.9系でキューのアルバム表示に対応した際にデータ量が増えたのが原因でした。
正式版ではないにせよWebUIの実行ファイルのみでも近日中にアップしますので必要な方は入れ替え頂けると幸いです。

WebUI改善の進捗について(2020-04-19 現在）
前回に引き続き、ステータスの変わったところのみ掲載します。
２）楽曲一覧の各カラム幅揃え　「再調整」
　先週末時点で「済」とご報告しましたが改めて確認したところ、
　「楽曲全消去のアイコン」と「それ以外の楽曲消去のアイコン」の縦位置が揃わない場合が
ありましたのでこれを修正しました。
　（具体的には全消去はボタン、各曲消去はリンクだったのですが、全てリンクに統一）

８）ローカルファイルのRaspberryPiへの転送　「一次対応完了」
　以下の４点対応＋確認済み
　・テキスト・バイナリファイルともに転送し、/var/lib/mpd/music/RAM上に保存
　・転送済みファイルと元ファイルのサイズが同一
　・転送したファイルのバイナリエディタの出力がざっと同一
　・ファイル転送完了後、内部で"mpc update RAM"コマンドを実行し、
　　楽曲が転送された場合はライブラリに追加
　　その後キューに追加して再生出来たことまで確認済
　・ファイルアップロード用のプラグインフォーム開発

　なお、１ファイルサイズの転送上限をとりあえず50MBとしています。
　（RaspberryPi４の場合、通常入手可能な最小メモリは2GBもあるんだから、
　もっと大容量のファイル転送可能でも良いだろうって話もあるかもしれません。
　その時は再調整します。）

　残件は以下の２点
　・ファイル転送完了後にサーバから返事を返し、通知を表示
　・皆さんに試用して頂き、安定性を確認頂く
　（従来組込WebサーバではHTTP POST関連の処理は無視もしくは接続を閉じるように
　記載されていたが、今回ファイル転送のために追加したため。
　サンプルソースコード通り実装しただけではWebUIのリロード時にフリーズが発生していた。）

６）楽曲情報のスクロール対応　「一部対応」
　以下の対応済
　・スクロール対象の情報は以下の３種類（キューモード・カバーアートモード共）
　　 楽曲名称、　アルバム名称、　アーティスト（楽曲）
　・既定状態では「スクロールしない」仕様で制作
　・文字列長が表示部の幅を超える場合のみスクロールさせるように実装
　　（スクロールの有無で表示位置が変わらないように調整済み）

　残件は以下の２点
　・スクロール開始位置と終了位置の制御方法
　・ブラウザ毎のGPU制御コマンド（CSSのベンダプレフィックス）の導入

皆さんに楽曲情報などのスクロールについて質問があります。
私個人的には以下のようなものが望ましいと考えていますが皆さんは実用上、どれが良いですか？
ご意見、お待ちしております。

１）スクロールしない場合（領域内に文字列が収まる場合）
　→従来の表示方法で表示させる。
　　例えば、キューモードの楽曲名・アルバム名は左寄せ、アーティスト名のみ右寄せ
　　カバーアートモードは全情報中央寄せ
２）スクロールする場合（領域内から文字列がはみ出る場合）
　→オーディオ機器のLED文字列表示のような形で表示させる
　　スクロール開始時は左寄せ
　　左に文字列がスクロールし、文字列のお尻が右端から見えた時点で
　　少し空白を開けて文字列先頭が右からスクロール。
　　右からの文字列先頭が左端に着いたら、数秒待ち時間がありまたスクロール開始
　　↑
　　実はこのような表示が可能な物はまだ見つけていませんが、なんとかしてみたいと思います。

速報です。スクロールについてはあっさり対応出来てしまいました。

cssのアニメーション指定では%単位で時間割を決めるのですが、
工程中の時間割のスタイルを同一にするだけで指定時間割合静止状態にできました。
具体的に書くとこのような感じ

@keyframes marquee {
  0% { transform: translate(0%); }
 10% { transform: translate(0%); }
100% { transform: translate(-50%); }
}

translate(0%)で領域の左端、translate(-50%)で領域の左端からさらに50%左に寄った形になります。
（実は「同じ文字列＋空白」を2回記述して半分だけスクロールさせるという方法です。
1回だけ記述し−100%にすると文字列が領域外に消えて全く見えなくなります。
左にスクロールさせて、右からまた先頭部を再表示するにはこの方法が最適だと判断しました。）

最初の0%と10%のポジション指定を合わせることで、全時間工程のうち0〜10%は移動させない状態になるということになります。
今回のスクロールは1回のアニメーションが２０秒のシーケンスですので、
最初の２秒間は静止状態となります。

まずは自分がこちらに書いた方法でのスクロールサポートでソースコードはお返ししました。
あとは実際に動いた状態で皆さんがどういう反応が来るかを見てみます。

アルバムのカバーアート表示（試作版）
今回はかなり好みが別れる形になるかと思いますがカバーアート表示に関するちょっとした試作版が出来ましたので画面イメージ公開します。
(もし、「ちょっと使用感を見てみたい」ということでしたら、テスト用ビルド用意します。)

ympdのフォルダ表示の際に、アルバム名の上にマウスカーソルがある場合は裏側でそのアルバムのカバーアートをダウンロードして表示するという機能です（ファイルがなければ例のお姉さんの画像）。
(とりあえず試作ではアルバム行全体で有効になっています。)
アルバムサイズは150×150ピクセルとしています。
カバーアートはマウスの動きに追従して移動します。マウスで他のアルバムを選択するとカバーアートは切り替ります。

問題点は幾つかあります。
１）行全体でカバーアートが追従して移動表示され続けるため、ウザい
　(これはアルバムタイトル行選択時のみ表示には変えられるかと思います)

２）カバーアートのダウンロードのためにHTTPアクセスが増加する。
　(従来は楽曲切替時のみ読込でしたが、この変更のためにアルバム行にマウスカーソルを合わせる度にダウンロード操作が入ります。ブラウザのキャッシュは聴くと思いますが)

３）ディレクトリでは初期画面のお姉さんの画像になってしまう
　(クラシック専門な方以外はアルバムアーティスト→アルバム→楽曲という形でNAS側の
　ディレクトリ構成を行っていると思いますが、
　NASのトップページでアルバムアーティストを選択した際はデフォルトでは画像が見つかリません。
　これについてはアルバムアーティストのフォルダにアーティストの画像を置いておけば幸せになるかもしれません。)

４）これが最大の問題ですが、タッチ系のデバイスでは動作が変
　(マウスが領域に入った場合のみ表示し、領域外に出たら消すという操作系のため、
　タッチデバイスでは上手く動かない)

@sunatomo さん

私の意見は、正直、ポップアップはウザいと思います。
カバーアートを表示させるなら、テキスト表示とサムネイル表示を切り替えて選択出来る方式の方がいいです。

@Cresson さま
グリッドビューのための習作でちょろっと出来たものですのでどうしようかなくらいのつもりでしたが、
やっぱりカバーアートみたいならそっち専用モードのほうが良いですよね。

画面を公開した次の日くらいまでちょっとだけいじってみたのですが、
「やはりタッチ系のデバイスの制御が上手く行かなそう」なのと
「マウスカーソルの挙動によりカバーアートが残る」現象に悩まされたので採用は無しになりそうですかね。

という訳で、今日の習作、グリッド表示画面です。

一応、カバーアートのグリッド表示、習作レベルで動くよう調整してみました。
トップレベルからカバーアートをクリックすると絞り込みを行うことが出来、
ディレクトリ・アルバム・楽曲単位でキューに追加できるようには仕上げてあります。

問題点はざっとこのくらいあります（山積のため、本提供はまだまだ先とお考え下さい）。
　１）従来のリスト表示とグリッド表示の切替がスムーズに出来ない。
　　（現状の仕様ではMPDサーバからリスト・グリッド生成用にデータを貰いにいくのですが、
　　その際にWebブラウザ内部の参照URLが同一であるために遷移が働かない）

　2）グリッド表示の際に画像参照のため大量のアクセスがRaspberryPiに行く
　　現状、カバーアートはcssのbackground-imageに複数のurlを指定して総当りで対応しています。
　　ここを順次サーチ（候補がない場合は次の候補に問い合わせ）するようにすればアクセスは減らせそうですが
　　↑
　　ちなみに楽曲再生中のカバーアートもこの方法

　3）グリッド表示の場合、同時表示数を減らす仕組みが必要？
　　従来のリスト表示では同一ページ内に500件が最大ですが、その1/10程度が妥当でしょうか？
　　RaspberryPi側に同時表示数をコマンドで渡して調節する仕組みが必要ですね。

　4）画面サイズ変更時にグリッドの列数を自動調節出来ない
　　(リサイズ処理の関数にそのための処理を追加する必要あり）

　5）グリッド内の各要素（画像 アルバム名）の表示位置調整未完了

　5）アルバム内楽曲一覧の見せ方について

　　これはグリッドビューでアルバムを選択した際にリストが表示されるように仮調整したものですが、
　　従来のリストビューに比べると再生時間など必要な情報が不足していますし、
　　レイアウトも劣化しています。
　　（アルバム選択時にはリスト表示に切り替わるようにしたほうが良いかも。）

　6）Title横の「search」での簡易検索が一時的に動作不能
　　後述のグリッド表示切り替えボタンをここに置いたため、
　　この試作環境では一時的にリスト表示でも動作不能になっています。
　　また、現状ではグリッド表示の際はここに値を入れても検索出来ません。
　　（ここの検索→抽出はtable要素内でヒットしない行を一時的に非表示にする方法で
　　実現しているため、グリッドの場合は新たにやり方を考えなければならない。）
　
　7）リスト表示とグリッド表示の切替ボタンが暫定位置（「Title」文字列の左横）
　　場所についてはこのグリッド表示をそのまま開発を継続するならば、
　　@パパリウス さまに要相談ですね。
　　私の想定案としては（＋）ボタンのところでしょうか?
　　（現状、リスト表示←→キュー表示の2挙動ですが、これにグリッド表示を追加して3挙動化する）

@sunatomo さん

問題点は多いようですが、短時間でここまで仕上げるとは、感服します。
smpdを使われてるみなさんは、再生音に拘りのある方が多いでしょうから
負荷が増えて再生に影響を与えるなら困りますが、影響がないなら、使ってみたいです。

@sunatomo さん
お世話になっています。
グリッドビュー良いですね。
こんな機能が加わると聴きたいアルバムの選択が便利になりそうですね。
気長にお待ちしています。