OSDN -- オープンソース・ソフトウェアの開発とダウンロード
日本語の翻訳状況 translation status for ja
編集 | ページ一覧 |  最近の更新  | 

吹き出しエディタ

BalloonUI.gif
アドオンな吹き出しのための編集UI

http://sourceforge.jp/projects/pettanr/wiki/ClientBalloonEditor/attach/%E3%82%A2%E3%83%89%E3%82%AA%E3%83%B3%E3%81%AA%E5%90%B9%E3%81%8D%E5%87%BA%E3%81%97%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E7%B7%A8%E9%9B%86UI.pdf

  • 通常の吹き出しとサードパーティによって追加されたパラメータが多い吹き出し、これらについて矛盾無く UI を提供するには？
  • 画像は即興のメモ書きで、項目の内容や順番は必ずしもこの通りではない．

メモ

関連文書

規約案

  • パスの線がコンテンツボックスに重なってはいけない。
  • 与えられた引数( settings )に対しては常に同じ値（パス文字列、　system picture ID ）を返さなくてはいけない。ランダムとかはNG。

使いどころ

js による吹き出しを描画機能は、コミック閲覧時とパネル編集時に使われる。

  • コミック閲覧時。
    • サーバー画像( system picture )の読み込みを抑止する。どの程度の効果があるか？ 試算はこのページで ⇒ XbackendSpeachBalloon
  • パネルエディターの GUI コンソールから。完成状態を見たままに吹き出し用のパラメータを直感的に操作できる（ようにするのが理想）。

留意点

システム画像の読み込みを最小限にするために、Web 標準である SVG、Canvas( Android 2 以下では標準ブラウザが SVG を非サポートなので Canvas を使う ) を主軸にしつつ、非 Web 標準である VML, Flash, Silverlight ?? も状況に応じて活用する。これをクロスバックエンドなベクター機能と呼ぶ。

クロスバックエンドなベクター機能はラップされていて、吹き出しプログラマーはバックエンドの違いを意識する必要がない。基本的に SVG 用のパスを投げることができればよい。（ようにする、できるか俺、、、そのための検証をしているページ ⇒ XbackendSpeachBalloon )

いとっち制作のエディターにべったりな設計にせず、他のクライアント実装の登場を阻害しない妥当な API 設計とする。

今のところ パス しか考慮していない

SVG Tiny ( 最小のSVGセット・携帯端末用 )のうちでも パスしか考慮していない。

吹き出しのサイズと包含コンテンツサイズ

ユーザーは吹き出しのリサイズ UI を使って自由に吹き出しのサイズを変更できるが、その際にコンテンツがはみ出すくらいに小さくなるのはまずい。

そこで、リサイズの度にコンテンツのサイズを再計算し、時にはリサイズをキャンセルする仕組みが必要。これによって、コンテンツが吹き出しの中に適切な余白を持って表示されることになる。

ちなみに、これはあくまでパネルを編集をしているユーザーのデバイスにおいて、という条件付きになる。なぜならインストールされているフォントがユーザーのPC環境によって異なるからだ。この問題を根本的に解決する方法はない。

以上の点を留意して吹き出しのパスとコンテンツボックスの余白を十分に設定しておく。テキストが一行余分に増えても支障がないようにしておく。

サンドボックス実行（案）

受け取った関数を evel でグローバルに再定義して使用する。その際にグローバル変数にアクセスできないようにする。

バルーンプログラマーは、全ての処理を関数内で済ませて、事前計算などはできない。（ パフォーマンス大丈夫？ ）

これは不要かな、、、

パスの破綻

パラメータの組み合わせによってはパスがデザイン上破綻するかもしれない。極端に小さいサイズが指定されたときに起こると思われる。 これを防ぐために善後策としてminWidth と minHeight を設定する。（これは不要かな）

また width と height の比が 1 : 10 などとなるとデザインが破綻するケースもあるかもしれない、また比率のほかにもケースがあるかもしれない。 パスが null を返した場合には、リサイズをキャンセルする、というのはどうか？（こちらのほうが柔軟でスジがいい）

設計

ビルトインなパラメータ

  • 幅　minWidth を設定できる
  • 高さ minHeight を設定できる
  • 尻尾のための方向指定 hasTail : true で有効に。（ 楕円の周りをサムが回るような UI を持っている ）
  • 尻尾の使用、不使用をユーザーで切り替えることができる。 tailSwitchable : true で有効に。そもそも hasTail が false なら無視される。
    • 尻尾の角度の入力は、ポインティングデバイスの使えるクライアントではつまみをグイグイ動かして行いたい。そのためには、他のパラメータと区別して、それが尻尾の向きを表していることを明らかにする必要があります。仮に他にも整数型でレンジが0-359 な入力があった場合にも、一方が尻尾の向きであり、もう一方は異なることをはっきりさせる必要があります。
    • また、ぺったんR は 脚本を表現するために Html を拡張するもの とするなら、話者を示す尻尾はやはり別段の意味があるのかもしれません。この点はまだよく見えていません。<label> タグには for 属性があり、対応する input タグを指定しますが、ちょうどそんな関係を示す感じ。

自由に定義されるパラメータ

例えば、通常の吹き出しであれば、高さと幅の他に尻尾の方向を持つ。（ビルトインなパラメータの範囲）

仮に、爆発状の吹き出しであれば、ギザギザの山の高さや、山の数をパラメータで持つ。( + 山の高さ、 + 山のピッチ )

仮に尻尾の折れる吹き出しであれば、尻尾の方向のほかに折れ曲がり角度を持つ。( + 尻尾の曲がり )

吹き出しテンプレートに独自なパラメータとそれに相応しい ＵＩ をパネルエディタに指示するのも吹き出しテンプレートデータの役割。

  • ギザギザの山の高さ、山の数、折れ曲がり角度 スライダー式 数値入力式
  • 尻尾がインサイドになる、アウトサイドになる スイッチ式
  • トゲ マルっぽい、かどばってる、鋭角 等から選択式

html の form 部品のようにパラメータの値の方とレンジを指示して、実際の画面表示は各クライアントに委ねる。おもに画面と ＩＦ で最適な ＵＩ は代わる。各クライアント実装が独自に判断する。但し同じ値なら同じパスが結果として描かれること。それだけ。

yasの横槍

それほど大それたことを考えてはいなくてビルトアウトなオプションを入力するためのコンポーネントの設定をテンプレートから出してしまおうか、と考えているだけです。

「トゲトゲフキダシのトゲの深さを入力するための数値型のフィールドだ」と言われても、その数値を入力するために最もふさわしいインターフェイスがどれであるかを決定するのはなかなかに難しいことです。スライダーバー、レベルメーター、ダイヤル、そして直接入力など数値を入力するためのインターフェイスは状況によって全く変わってきます。その情報をテンプレートの中に入れてしまうと収拾がつかなくなりますので、これらの設定情報をバインディングファイル(テンプレートとエディタの関係を取り持ってくれるファイル)に分割したいということです。

テンプレート側で決定できるのは、文字列入力、数値入力、セレクトボックスの三種類程度にします。もしここでバインディングファイルがない場合、デフォルトの入力コンポーネントとして、これらが表示されます。バインディングファイルを用意してあれば、そこに「この項目はスライダーで入力してね」と定義してあるので、数値を入力するためのテキストボックスの代わりにスライダーが表示されます。このように設定ファイルを分離することで、環境やユーザーの好みの影響を受けにくくすることが可能です。もしユーザーがタブレット環境であればタブレット用のバインディングファイルの利用することで、画面の大きさや入力デバイスの性能に合わせた入力コンポーネントを表示できるはずです。

フキダシテンプレートが後から開発された場合、当然ながらパネルエディタに適合したバインディングファイルがありません。この場合、デフォルトの入力コンポーネント(早い話が直接入力)が使われますので、比較的使いづらいことになります。気の利いたフキダシクリエイターはメジャーなエディタのバインディングファイルを作成するでしょうが、必ずしも作成を義務づけられているわけではありませんので入手できない状況もあり得るでしょう。パネルエディタの開発陣は速やかに対応しなければならないでしょう。

itozyun

ビルトアウトなオプションを入力するためのコンポーネントの設定をテンプレートから出してしまおうか、と考えているだけです。

コンポーネントの設定（どんなGUIになるか？）をテンプレートに入れる発想はありませんでした。少し上でスライダー式って書いてあるのが惑わせてしまいました。スライダーになるのか？ダイヤルになるのか？等はデータの型やレンジ等の情報を元に、各クライアントに全く委ねる、と考えています。僕が担当しているクライアント実装でいえば、system.js は将来的にはデバイスを判定して、タブレット向け入力コンポーネント一式や携帯ゲーム向け入力コンポーネント一式 を読み込む、という風に構想しています。

もしユーザーがタブレット環境であればタブレット用のバインディングファイルの利用することで、画面の大きさや入力デバイスの性能に合わせた入力コンポーネントを表示できるはずです。 気の利いたフキダシクリエイターはメジャーなエディタのバインディングファイルを作成するでしょうが

バインディングファイルの件は、僕のアイデアより話が大きくなります。 整数数値入力、少数数値入力、セレクトボックス、ON/OFFスイッチ の組み合わせに収斂しませんかね？ 仮にとても入力がめんどくさいけど素晴らしい吹き出しテンプレートがある場合、それをガッツリサポートしたいと考えるエディタは、そのテンプレートを classname で判定してそのときだけ UI を切り替える、って感じじゃだめかな？

yas

スライダーになるのか？ダイヤルになるのか？等はデータの型やレンジ等の情報を元に、各クライアントに全く委ねる、と考えています。 それをガッツリサポートしたいと考えるエディタは、そのテンプレートを classname で判定してそのときだけ UI を切り替える

これでいいんですけど、この部分の処理をハードコーディングしてあると、第三者がなんとかしたいと思っても簡単には手が出せないので、設定ファイルにしてソースコードが読めなくても変更できるようにしたいな、という発想です。

整数数値入力、少数数値入力、セレクトボックス、ON/OFFスイッチ の組み合わせに収斂しませんかね？

多分します。ただし、数値入力と文字列入力は機能が違うので、文字列の入力ボックスは用意していただきたいところ。

当面は上記だけのシンプルな入力方式にしておいて物足りない部分が出てきた時は、あとからソースコードの変更なしに外観を変更できるように仕組みだけは用意しておきたいといったところです。 class nameを頼りに設定をゲットしてくる感じでいいのではないでしょうか?この辺は将来的にそうなって行けばいいので初期バージョンから対応する必要はありません。サードパーティがやってくれると信じて、我々は「最低限」の実装を目指しましょう。

将来的にはこれらのシンプルな入力コンポーネントだけでは足りません。例えばカラーコードを直接入力しろと言われたら大抵の人はうんざりしてしまいます。そこで、カラーコードの選択インターフェイスを開発する必要が出るのですが、この機能は背景色の選択にも共通するので同じ処理を使いたくなるでしょう。つまり、ふきだしの入力はこれだけで独立しておらず、パネルエディタ全体で連携することになります。そう考えればハードコーディングは賢明では無いと考えられます。

入力validation

パラメータを入力する際に、必ずvalidationが必要になります。 railsにはそのための機能が組み込まれていますが、 JavaScriptにはあったかな?これを再開発するのはちょっとしんどいというか当たり前の機能すぎて必ずどこかにライブラリがあるはずだと… 。ちょっと探してみましたが、 jqueryのプラグインにそのためのプラグインがありました。

http://bassistance.de/jquery-plugins/jquery-plugin-validation/

こちらのサンプルがありますが、rules としてjson形式で定義できるようなので、ここをテンプレートに組み込んでしまえばコーディングがかなり楽になるかと思います。

http://d.hatena.ne.jp/sugyan/20090312/1236815025 

  1.          rules : {
  2.              comment: {
  3.                  required: true,
  4.                  minlength: 5
  5.              }
  6.          }

こんな要領で、 「しっぽの向きは必須項目でゼロ以上三百六十未満で入力すること」といった具合に定義するということです。

必ずこれを使用しろというわけではありませんが、やりたい事は同じなので、利用しない手はありません。これ以外にもよく似たライブラリはあるはずなので、自分で組むことを考えるより使い回した方が良いかと思います。

itozyun

バリデーション仕様は各クライアントで統一される必要があります。ライブラリの使用については各クライアント作者の判断になると思います。 ちなみに jQuery について僕の考えは、現在は使っていますが、 Web ページに機能を追加するにはとても便利ですけど、規模の大き目な Web アプリの開発には向かないと思っています。

yas

バリデーション仕様は各クライアントで統一される必要があります。

クライアントで統一されているだけでは不足です。ぺったんR全体で統一されている必要があります。

トゲトゲの吹き出しが最大何個までのトゲに対応できるかは吹き出しテンプレートのレベルで厳格に定義されていなければ困ってしまいます。例えば、あるエディタが十個までに対応できていたとしてもう一つはエディタが五個までしか対応できないなら、前者のエディタで七個で入力されたトゲを、後者のエディタはどのように対応するのでしょう? また、画像で表示する吹き出しを用意するのはテンプレート作者ですが、ここで準備されたバリエーションを超える数値を入力されても困ります。バリデーションは吹き出しテンプレートで定義すべきです。

上記の例では、 jqueryのプラグインを出していますが、これはjqueryを使えと言っているわけではありません。あくまでjqueryの拡張プラグインにバリデーションを実装したものがある、と言う話です。このようにバリデーションの処理を切り分けてあれば、第二第三のパネルエディタを開発する際にバリデーション部分を使い回せるはずです。さらに詳しいバリデーションの設定をjsonで記述できれば容易に吹き出しテンプレートでの表現が可能になります。

採用したライブラリがメジャーなものであれば、わざわざ自分達でドキュメントを書く必要もなく、ぺったんRのこと知らない人でも比較的スムーズに設定ファイルを記述できるというメリットがあります。これが営利目的の開発であれば、第三者の力を当てにすることは不可能なので、嫌でも独自仕様にならざるを得ませんが、我々はオープンソースを採用しているので、なんでも自分達で実装しようとは考えないで、いつでも組み込みと切り離しが可能なようにシステムを作ることに力を注ぐべきでしょう。

itozyun

クライアントで統一されているだけでは不足です。ぺったんR全体で統一されている必要があります。

その通りです。クライアントが気になっていたのでそう書いてしまいましたが、ぺったんR 全体です。

トゲトゲの吹き出しが最大何個までのトゲに対応できるかは吹き出しテンプレートのレベルで厳格に定義されていなければ困ってしまいます。

このページの下のほうで、以下のようにざっと書き出してあります。定義しきれてない部分は追記のほうお願いします。

数値指定(　レンジ指定する ) 自然数 Int

あとですね、セレクトボックスの選択状況によっては、この数値パラメータは無効、みたいなケースはどうしましょう？ そういう機能は無いので吹き出しの種類を分けてね、とするか？頑張って テンプレートで定義してしまうか？パラメータの入り切りを決める js を設けるか？

yas

定義しきれてない部分は追記のほうお願いします。

例に挙げたバリデーションプラグインから引っ張ってきますね。後でまとめます。

セレクトボックスの選択状況によっては、この数値パラメータは無効、みたいなケースはどうしましょう？

「しっぽは使わない」を選択しておくと、しっぽの角度を指定する必要がないので、角度の数値はバリデーションの必要がないという事でしょうか? これはGUIアプリケーション特有の話ですね… 。 railsにはこんな概念はないので、ちょっと心当たりがないですね。 「いつ」 validationするかにもかかってきますね。 Visual Basicをやっていた頃はフォーカスを失った時にチェックしていましたが… 。そのタイミングでよければ無効なパラメータであっても何ら問題はないはずですが… 。

ビルトインパラメータ

尻尾の有無と向きは、実のところビルトインパラメーターではありません。すべてのフキダシに共通するパラメータではないのでビルトインからは除外しています。しかしながらフキダシの特性を考えると非常に重要度の高いパラメータであることは間違いありません。もういっそのことビルトインにしてしまおうかと思わないでもないのですが、どうしよっかな?

itozyun

ビルトインにしてテンプレート毎にフラグで、全く使用しない・使用を入り切りできる・絶対に使用する を埋め込んでおくことにしましょう。尻尾は特別で、キャラと言霊を結ぶぺったんR の根幹です、多分。

yas

よく見ると尻尾の有無をユーザーがチョイスできるようになっていますね。これはたぶんまずい…です… 。

一口に尻尾といっても、どんな尻尾がつくかはふきだしによって変わってきます。普通の三角尻尾以外にもカーブしたもの、モクモクと連想したもの、折れ曲がったものなどいろいろあります。楕円+カーブ、楕円+モクモク、どちらの「尻尾なし」も表示上は同じです。ここで「表示しない」から「表示する」に切り替えたとき、どんな尻尾が表示されるか、想像しづらいです。ユーザーから見たとき、これを切り替えることで得られるメリットは(今のところ)あまり見当たりません。

ふきだしテンプレートを記述する側も、それを解釈するエディタ(ベクター)側も少々話がややこしくなりますね。先日渡した楕円のテンプレートでは尻尾の角度で判別するように考えていましたが、ここに尻尾のないデータも混ざってくることになるので、新たな取り決めが必要になるでしょう。

この辺の手間を補えるだけのメリットがあるならばビルトインしても問題はないでしょう。

ということで尻尾を消すことで起きる画期的なアイディアを聞かせてください。

itozyun

画期的ではないですが、僕はこう考えます。

まず、ぺったんR は、仮に HTML が論文を配信する手段じゃなくて、脚本を配信する手段として設計されたとしたら、と発想するとスジよく設計できるんじゃないかと考えています。 この脚本html には、誰がいつ、どこで、動作や発言、心の声、そのときの気持ち、表情を示すタグが定義されていると想像します。この辺はあまり詰めれていません。（これは、あまり突飛な考えではないかもしれません。なぜなら多くの人は論文よりも物語をよく消費するからです。）

結論としては、話者を明示しない声、発声された場所が特定できない声をどのように脚本htmlでマークアップするか？をまず決めたい、ということになりました。

通常のセリフでは <speech> タグを使うとしてこのタグには発声の方向を示す 尻尾属性が付加されています。 では、発声場所の特定できない不思議な声はどうしましょう？セリフに変わらないという理由で <speech> タグを使うなら、吹き出しは尻尾の有無を切り替えるスイッチを備えます。 または、<storange_speech> タグを使うようにして <speech> と分離するなら、通常の吹き出しは尻尾があり、不思議な声用の尻尾の無い吹き出しを用意することになります。

以下は、脚本html を仮に想定してみて、考えてみた経過になります。速成なのでさっぱり練れてはいませんが。 

  1.  <scene name="シーン1・丘の上で">
  2.          <datetime>初夏のある日、陽は落ちかけている</datetime>
  3.          <place>街を見下ろす小高い丘</place>
  4.          <actors>
  5.                  <actor actor_id="penjiro">ペン次郎</actor>
  6.                  <actor actor_id="kinichi">キンイチ</actor>
  7.          </actors>
  8.          <script>
  9.                  <action for="penjiro">丘を登るペン次郎</action>
  10.                  <action for="kinichi">丘を下るキンイチ</action>
  11.                  <speech speaker="penjiro">こんにちわ</speech>
  12.                  <speech speaker="kinichi">おう、久しぶりだな</speech>
  13.          </script>
  14.  </scene>

テキストブラウザでは、こんな感じに表示されます。 

■ シーン1・丘の上で
 ・とき
  * 初夏のある日、陽は落ちかけている
 ・ところ
  * 街を見下ろす小高い丘
 ・人物
　* ペン次郎
  * キンイチ
 -----
 丘を登るペン次郎
 丘を下るキンイチ
 ペン次郎「こんにちわ」
 キンイチ「おう、久しぶりだな」

さて、このままで台本のようなものはできましたが、マンガっぽい表現にはなりません。 しかしこのように適切にマークアップされた脚本が何万本とアーカイブされているのを見てある人が考えました。 これにいくつかパラメータを追加してやって、マンガ風に表示できないか？と。そう時代はマンガ、マンガ、マンガ。ネコも杓子もマンガ。教科書もマンガで描いてないと誰も読まないし理解できません。末法の世です。

シーンをさらに細かくカットに分けて、そのカットがコマになります。actor タグに対応した画像の位置を調整して。 決定した画像の位置は x, y, あと width, height パラメータとして保持します。

speech は通常の楕円吹き出しに変換されます。話し手が誰か？という情報も speaker="penjiro" で持っているので、尻尾が表示され、その向きがペン次郎の画像を指すようになります。但しペン次郎の口の位置に尻尾が向くようにするためにオペレーターによる微調整がいります。このパラメータも保持しておきます。 width, height, tail_angle を保存。

さて、話題に出た尻尾のない吹き出しですが、とりあえず以下のようなマークアップとしてみます。 

  1.  <speech speaker="penjiro">むむ、怪しい雰囲気、、、</speech>
  2.  <speech>ここが魔者の棲む丘とも知らず、旨そうなペンギンが2羽、、、</speech>
  3.  <shout speaker="kinichi">今しゃべったの誰！？</shout>

2 つ目の怪しい声の <speech> タグには話者が設定されていません。ドラマの演出でよくあるやり方ですね。誰とも知れない声。 これを実際に演じる場合は、舞台裏に隠れている声の主の位置が分からないように音響的な工夫を施すでしょう。マイクを使って会場のそこら中に設置したスピーカーから声を出す、とか。

さて、この演出をマンガでやるなら、ひとつには、尻尾の無い吹き出しになります。尻尾があると音の発生源が特定でき、怪しい雰囲気が出ません。しかしこのような演出上の意図が無くても、尻尾の無い吹き出し、というのは作家の好みでフランクに使われています。（縦書き横書き論争を受けて、ぺったんR が国境を越える方向を目指すなら、日本国内の一部のマンガ読者の間で通用するお約束みたいなものは廃して、きちんと話者を指し示す、ほうがいいかもです。内容において特殊性・地域性がでるのはいいと思いますが、フォーマットにおいては割りとカチっとルールにはめる方向がよいのかも。世界中どこでも html のお作法に則るように。）

尻尾に関する話は以上です。ついでに、観客にとって怪しい声の主が（この時点で）不明なのは気分を盛り上げることができ、大変結構なことなのです。一方で、実際に演劇する側にとっては声が人物と結びついていないのはまずいです。実際には以下のようにマークアップされてるんだと思います。 

  1.          <actors>
  2.                  <actor actor_id="penjiro">ペン次郎</actor>
  3.                  <actor actor_id="kinichi">キンイチ</actor>
  4.                  <actor actor_id="monster" invisible>丘の悪魔</actor>
  5.          </actors>
  6.          <script>
  7.                  <speech speaker="penjiro">むむ、怪しい雰囲気、、、</speech>
  8.                  <speech invisible_speaker="monster">ここが魔者の棲む丘とも知らず、旨そうなペンギンが2羽、、、</speech>
  9.                  <shout speaker="kinichi">今しゃべったの誰！？</shout>
  10.          </script>

invisible が振られた人物は、テキストエディタではよろしく隠してくれて、読者の興を削ぐことはありません。

では、仮にペン次郎が舞台（画面）の外に居ただけの場合では、これもマンガの画面では話者の居ないフキダシができることになります。 しかし、役者は先ほど舞台から消えた位置で声を出しているので尻尾はその消えた方向を指します。

話者が舞台（画面）に居る？＼フキダシの尻尾の有無 尻尾有り 尻尾なし
居る 通常の状態。最もよくあるパターン 世界の誰にでも理解する敷居を下げる、という点では尻尾があるべき（要検討）腹話術など発声器官の不明な特殊な状況ではありかも。
居ない 画面から消えた話者の方向をさしている 話者とその声の出た方向が不明。

<speech> のほかには心の声やナレーションがある( <mind /> <narration /> ) 

  1.          <script>
  2.                  <narration>漢どもの暑い、どこまでも暑い、暑苦しい夏は今最高潮を迎えようとしていた、、、</narration>
  3.                  <mind speaker="penjiro">うげ～むさくるしいよ～しかし声に出していったらどうなることやら、、、</mind>
  4.          </script>

yas

脚本の話は大変興味深く読ませていただきました。とても面白かったです。時間が許せばもっと聞かせてほしいところです。この話はテンプレートとは独立していて、ある程度スケールの大きい話なので別のページに分けた方がいいですね。折を見て移動させましょう。

話をテンプレートに戻しますと、結局尻尾の有無をユーザーが選択できるメリットはあるように思えませんでした。むしろ用途が違うのなら「楕円」と「楕円(尻尾付き) 」の二つのテンプレートを用意して使い分けた方がわかりやすいでないでしょうか? これは楕円よりも長方形を例にした方がわかりやすいかと思います。一般的に長方形の吹き出しは時間と場所の移動を意味します。これに尻尾がつくと全く用途が変わってきます。誰がどちらの方向から話しているかよりもずっと大きな変化です。

尻尾の有無は内部データとして用意する形で充分なのではないでしょうか?

itozyun

楕円で考えていたときは迷いましたが、長方形の例で合点がいきました。尻尾の有無について、これは異なる吹き出しとしましょう。

ところで僕は今は、モクモク吹き出しは心の声、ギザギザフキダシは抑制を欠いた声（叫び）、カクカクした吹き出しは機械から出る音や声（ラジオとか）、ゆらゆら揺れるようなフキダシは（恐怖で）震える声、などとデザインと意図をカッチリ一致させては？と考えています。つまりモクモク吹き出しを通常の発言として扱っては NG　で、ギザギザ吹き出しを心の声として扱っては NG です（心の中でどんなに叫んでいても）。実際にシステム上禁止することはできませんが。html で 見出しテキストを <h1> で囲んでね、画面上同じように太字になるけど <b> は違うよ、ってのに似ています。html の場合は検索エンジンの覚えが良くなる、などの理由で <b> でなく <h1> を使う方向に圧が働きます。

システム上制限できることはほとんどないですが、これは html も同じです。吹き出しを、ギザギザなどとその見映えで呼称しないで、大きな声 などと意図にちなんだ名前にする。各吹き出しのデフォルトの大体テキストを調整しておく。（「…」 と 『…』 と「…！」）

これに関しては、また他所で。

Json 及び js

以上を踏まえて json をデザインする

テンプレート　json

  1.  {
  2.          name    : 'uniqueNameInPettanR', // ぺったんR 世界でユニークな名前 ドメインを末尾につける
  3.          caption : 'SampleギザギザBalloon', // ユーザーにも表示する名前（なるべくユニークに！）
  4.          defaultWidth : 200, // 初期値。defaultHeight が height のときに決して破綻しない値の組み合わせを指定
  5.          defaultHeight : 200, // 初期値。defaultWidth が width のときに決して破綻しない値の組み合わせを指定
  6.          hasTail : true, // 尻尾の角度を指定できるか？尻尾の角度指定 GUI は楕円上を移動するものがデフォルトで用意されている
  7.          tailSwithable : true, // tail の使用・不使用をユーザーで指定可能
  8.          params  : [ // バルーンテンプレートが要求するデータ、ここでの順番に引数がセットされる。
  9.                  {
  10.                          name     : 'needleLength',
  11.                          dataType : 2, // 数値入力
  12.                          label    : 'ギザギザの高さ',
  13.                          valueFrom : 1,
  14.                          valueTo : 100
  15.                  },
  16.                  {
  17.                          name     : 'needleOption',
  18.                          dataType : 4,// 選択方式
  19.                          options  : '鋭角,丸みがある,丸い',
  20.                          label    : 'とげの様子'
  21.                  }
  22.          ],
  23.          settings : { ～～ }
  24.  };

html などのフォーム部品を参考にして設計すればいいですね

dataType No. フォーム部品の種類
0 角度指定用
1 数値指定(　レンジ指定する ) 自然数 Int
2 数値指定(　レンジ指定する ) Number
3 ON, OFF
4 選択式

js

パス文字列及び、system picture ID を返してくれる単純な関数があればよい、という気がしている。 

  1.  ExampleBaloon = {
  2.  　getPath: function( width, height, etc... ){ return path_string; },
  3.  　getPictureID : function( width, height, etc... ){ return system_picture_id; }
  4.  };

パス文字列を取得する場合は、calcPathString() を params で指定した引数を指定した順番に与える。

hasAngle が false の場合、tailAngle とtailEnabled が無く、height の直後に　needleLength が続く。

tailSwitchable が false の場合、tailAndle に needleLength が続く。

ルールがめんどくさい、、、ハッシュで渡したほうがいいかも、、、 

  1.  pathString = ExampleBaloon.getPath( width, height, [ tailAngle, tailEnabled, needleLength, needleOption の selectedIndex,,  ] );

まとめ

jqueryのバリデーション

jqueryのバリデーションプラグインの翻訳がありました。Validateルールに設定できるデフォルトのメソッド以下をご覧ください

http://kudakurage.hatenadiary.com/entry/20091211/1260521031

railsのバリデーション

  • NumericalityValidator
    • 数字で入力すること 
      CHECKS 	= 	{ :greater_than => :>, :greater_than_or_equal_to => :>=, :equal_to => :==, :less_than => :<, :less_than_or_equal_to => :<=, :odd => :odd?, :even => :even? }.freeze

デフォルト値

これに加えて、デフォルト値の設定がある。

選択肢の一覧を初期設定する必要もある。

編集 履歴 削除
設定

[ページ情報]  更新日時: 2013-05-14 22:50:46, 更新者: itozyun
[権限]  表示:無制限, 編集:ログインユーザ, 削除/設定:メンバー
[IRI]  https://ja.osdn.net/projects/pettanr/wiki/ClientBalloonEditor