Forums: Developers (Thread #31275)

クライアント関連 (2012-01-02 20:08 by itozyun #61445)

以下に置いてあるクライアント側のプロトタイプについて.
http://pettanr.sourceforge.jp/work.html

getAsHTML (2012-01-03 17:24 by itozyun #61453)

メニューバーの quit に getAsHTML を追加しました.これはとりあえずは、手元テストデータを用意する用のメニューです.
getAsJSON も必要かな??
Reply to #61445

RE: getAsHTML (2012-01-03 18:00 by yasushiito #61454)

>getAsJSON も必要かな??
欲しいっす。
Reply to #61453

RE: getAsHTML (2012-01-04 19:53 by itozyun #61478)

了解っす.
Reply to #61454

RE: getAsHTML (2012-01-05 20:51 by itozyun #61511)

JsonAPI のページを見ながらざくっとやっておきました.まだ良く分かってない点も多々あるかと.
一応 json のバリデートは通りました.
Reply to #61454

RE: getAsHTML (2012-01-06 07:31 by yasushiito #61517)

後で違う部分をまとめます。
Reply to #61511

getAsJsonString (2012-01-06 08:22 by itozyun #61518)

よろです
Reply to #61517

RE: getAsHTML (2012-01-06 18:20 by yasushiito #61525)

panel
x,y,z,t → 追加
xyは0でいいです。
tはコマ番号です。
zはコマのzindex

panel_pictures_attributes
resource_picture_id → 数値だけで
w,h → width,height

balloons_attributes
border → size
resource_picture_id → system_picture_id・数値だけで
w,h → width,height

speaches_attributes
z,t → 追加
w,h → width,height
Reply to #61517

getAsJsonString (2012-01-10 00:53 by itozyun #61565)

ありがとうございます.
http://pettanr.sourceforge.jp/work.html のほうやっておきました.まだダミーなデータが多いのでまたおいおい、、、
Reply to #61525

RE: getAsJsonString (2012-01-10 17:31 by yasushiito #61574)

仕様の詰めが甘いフキダシに食い違いはあるものの、それを除けば以下です。

speaches_attributesにzはいらない。
panel_pictures_attributesのzに負の値がある。

あとは認証トークンを足せばツッコめました。
Reply to #61565

RE: getAsJsonString (2012-01-11 07:39 by itozyun #61606)

ありがとうございます.以下を直しておきました.
z が負の数の方はコードのバグでした、危なかった.

js の構成が変わって 0.4.x になります.リロードをしっかりやって読み込んでください.
http://pettanr.sourceforge.jp/work.html
Reply to #61574

不具合情報 (2012-01-04 19:58 by itozyun #61479)

ie6 の一部で画像が表示されない.
vml の有無の判定が実はできていなかった(対処済み).
気づいたら Opera で動かなくなっていた.少し前の ジオシティーズに置いている物は動くので、いったい何が原因かと、、、
Reply to #61445

operaでも問題なかった 0.2.0 (2012-01-09 22:56 by itozyun #61562)

opera 9.6~11 で問題なく動いていた 去年最後のコードを 0.2.0 として git にあげました.

この opera の不具合に半日かかって取り組みましたが、問題の箇所は絞れるも結局解決には至らず.

問題箇所は、この年始に shift + リサイズ のために大きく書き直した comicElement のための 操作部分.
変数を画面に書き出しながら見ていくと、RESIZE_CONTROLER スコープの変数の内容がときどき undefined になってしまう.
この部分は、コード中でもっとも階層の深いところにあるので、それが関係ある??

ie, firefox, chrome, safari では再現しない.
Reply to #61479

クロスドメイン (2012-01-10 18:32 by yasushiito #61576)

jsonベースでサーバに同梱されるクライアントとjsonpベースでクロスドメインなクライアントで、コードにどの程度差異がありますか?

jsonpの利点はサーバなしで単独使用できることですが、認証が必要なアクションをしたいとなると認証トークンが不可欠です。何らかの形でトークンをwebページに埋め込みたいところですが、認証トークンはパスワード並の秘密情報なので、まさかwebから見える場所に置くわけにはいきません。おそらくjsはローカルなファイルを勝手に開けないでしょうから、事実上クロスドメインなクライアントをサーバなしで運用はできないってことです。

まるで役にたたないじゃん

と言いたいところですが、ビュワー程度には使えますし、webには置かずに手元のマシンに認証トークン付きのページを置いておけば開発テストくらいは役に立ちます。単独で使用できるってことは、こちらのサーバの実行環境をそちらに用意したり、度々マージする必要はなくなります。

もしもクロスドメインなクライアントを用意するのがあまりにも大変なら、ビュワー専用にしましょうね、とだけ言っときます。
Reply to #61445

クロスドメイン (2012-01-10 21:24 by itozyun #61579)

クアイアントのみで行うクロスドメインな通信は、
js のみの場合だと、まず pettanR サーバに、xdomainProxy.html みたいなのを設置します.
これは、スクリプトのみが記述された、html ファイルです.

よそ者のクライアント ttp://itozyun.com/work.html は pettanR から認証と操作を行うために自身のページ内に、隠し iframe を生成してそのurl は
ttp:/pettanr.com/xdomainProxy.html?
id=itozyun&
pass=0123&
action=login&
callback=ttp://itozyun.com/callback.html とかします.

xdomainProxy.html は開かれると、まずは自身の url を確認し、itozyun, 01234 で login アクション を pettanR サーバに対して行います.
認証コードを取得したら xdomainProxy.html は、自身の url を、ttp://itozyun.com/callback.html?result=xxxxxxx などと書き換えます.

これで、ttp://itozyun.com/work.html と ttp://itozyun.com/callback.html は同一ドメインになるので、アクションの結果をもらうことができます.

投稿するときは
ttp:/pettanr.com/xdomainProxy.html?
auth=xxxxxxx&
post={~~~}

みたいにして、再び xdomainProxy.html を iframe 内に呼ぶ感じで.

以上が一番単純な感じで、それでもややこしいですが、基本はこんな感じだと理解してます.
ちなみに、パラメータは url エンコードをしたり、巨大なデータは、window.name という オブジェクトに格納してやります.
window.name だと 2MB 位のデータがやり取りできてしまうので、 pettanR の用途なら十分です.
Reply to #61445

RE: クロスドメイン (2012-01-10 21:54 by itozyun #61582)

でもこの方法だと、悪意のある itozyun.com によってユーザーの id password が盗まれてしまいますね、、、
twitter 連携サービスとかで使う、OAuth 認証を pettanR サーバに対して行う.

なんか混乱してるかも.
Reply to #61579

RE: クロスドメイン (2012-01-11 07:47 by yasushiito #61608)

外部からの操作はOAuthがあるやんって気付いたのはわりと最近の話。ただ、これでも何らかのサーバは要るんで、手軽にポンとはいかない。

おそらくは手軽で安全なエディタ付きのクライアントをwebに置くのは無理だろうと。
Reply to #61582

RE: クロスドメイン (2012-01-22 19:10 by itozyun #61818)

Blogに張られていたコマを継承したコマを作りたい場合は、ブラウザアドオンか、もしくはぺったんRページにジャンプすることになりますね.
Reply to #61608

RE: クロスドメイン (2012-01-23 16:38 by yasushiito #61851)

まぁジャンプでしょうね。
Reply to #61818

0.4.x (2012-01-11 07:42 by itozyun #61607)

0.4 では、
js の構成を稼動時の状態に近づけます.common.js に work.js にあった共用部分を移動していきます.
editor 以外の 画面も作りこんで、サーバからの json (jsonp??) の読み込みをします.
Reply to #61445

RE: 0.4.x (2012-01-15 09:06 by itozyun #61703)

いきなりコマエディターに入っていたのをやめて、ようやく画面の切り替え周りを書いたところ.
http://pettanr.sourceforge.jp/work.html?debug=true

これから、ぺったんリソースの取得・表示・操作 を書きます.
Reply to #61607

RE: 0.4.x (2012-01-19 10:03 by itozyun #61769)

手元ではファイルの取得が動いた.
createTree して ファイルツリー を作り、getCurrentFile で fileインスタンスを取って、ファイル以下のリソースは json にある場合は、getJson する.
treeUpdate イベント で 表示を書き換えるという、まどろっこしさ.
Reply to #61703

RE: 0.4.x (2012-01-22 19:29 by itozyun #61821)

一応、ファイルエクスプローラ状のものが動き始めました。まだ画像だけですが。取得した json を読んで適宜作家別フォルダを作って格納したりもしてくれます.現状、作家が一人なので、、、これから僕も上げてきますw

http://pettanr.sourceforge.jp/work.html?debug=true&view=2&exjson=false

次は、コミックのエクスプローラにいきます.あとはエディターへの panel や picture のやり取りも fileオブジェクトで行うようにしていきます。
Reply to #61769

RE: 0.4.x (2012-01-23 16:49 by yasushiito #61856)

なるほど。こういう見せ方できましたか。wktk。
絵師フォルダですが、参加絵師数が増えてくると大変なので工夫がいるでしょう。例えば、friendsとかで管理するとか。しかし、そねへんはSNSの機能になってくるんで考え方が多岐に渡るでしょう。誰とも繋がらない孤独な作業場であっても悪くはないんだし。Artistとfriendsはコンポーネント風に切り離して使えると勝手がいいですね。
Reply to #61821

RE: 0.4.x (2012-01-24 09:02 by yasushiito #61875)

ざらっとソースをみました。
難しすぎてさっぱりわかりませんでしたが、どんな処理系のサーバにも柔軟に繋がりそうだってことはわかりました(雰囲気で)。

漫画サイトっていうより、漫画OSみたいですね。
へだちも昔そんなもんを作りたいってどっかで言ってた気がするから、正しいあり方だと思う。
Reply to #61821

漫画OS (2012-01-24 22:00 by itozyun #61888)

あざーす!

js のコードを見るときは、コードを色分けしてくれる Aptana Studio3 が一応僕のお勧めです.html css 書くのにも使ってます.

OS 風になるのは、二つの狙いがあります.

ひとつは、WebAPIなどのリソースを利用しやすいようにすること.たとえば翻訳APIを使って海外の翻訳者ユーザーのサポートをするとか、そういう拡張をしやすいようにしたい.そんなことを見据えて、まさにWeb上のリソースを一貫したGUIで操作できるエクスプローラを意識の隅に置いています.

もう一点は、Webサイトというより、作家の仕事部屋という意識でやっています.人が集まる楽しいサイトというより.
Reply to #61875

RE: 漫画OS (2012-01-25 08:00 by yasushiito #61901)

僕もその意見には賛成です。
これからは、そういう形を想定しながらサーバを進めていきます。
Reply to #61888

Webページから画像ギャラリーのイメージは読めない (2012-01-12 07:10 by itozyun #61642)

手元で見れてると思ったら、キャッシュを見ていました(><

webページ
http://pettanr.sourceforge.jp/

画像ギャラリーの画像
http://static.sourceforge.jp/thumb/g/2/930/640x640_0.png
Reply to #61445

RE: Webページから画像ギャラリーのイメージは読めない (2012-01-12 07:13 by itozyun #61643)

たまたま読み込めなかっただけ?
Reply to #61642

RE: クライアント関連 (2012-01-13 08:59 by yasushiito #61664)

クライアントが欲しいデータを掴みきれてません。
サーバやってるとサーバに必要な機能しか追わないんで。
http://sourceforge.jp/projects/pettanr/wiki/ApiIndex
協力していただけると助かります。
Reply to #61445

RE: クライアント関連 (2012-01-15 09:03 by itozyun #61702)

リソースの取得、表示・操作周りを作りながらきちんと考えてみます.
ちょっとまっててください.
Reply to #61664

0.4.1 (2012-01-27 13:03 by itozyun #61944)

画像エクスプローラ in Editor 動作.
Reply to #61445

RE: クライアント関連 (2012-02-05 20:15 by itozyun #62104)

古めの Opera 8 ~ 10(11?) に対しては、svg + データスキーム を使って画像の反転を行う.

以下のテストが、opera 10.1 で動作.他のバージョンについてもまたいずれ、、、
http://pettanr.sourceforge.jp/test/svg.html
Reply to #61445

基本ライブラリについて (2012-02-06 10:06 by itozyun #62111)

atom機でモッサリだったし、あんまり機能を使ってないし、jQueryの ready を待たないと使えない(みたい)だし、なのでjQuery をいずれ外そうと考えています.
Extends.js ってライブラリの書き方が気に入ったので、それを参考に自前で用意しようと思う.
Reply to #61445

RE: クライアント関連 (2012-02-18 23:37 by itozyun #62289)

http://closure-compiler.appspot.com/home

// ==ClosureCompiler==
// @compilation_level SIMPLE_OPTIMIZATIONS
// @output_file_name default.js
// @code_url http://pettanr.sourceforge.jp/javascripts/common.js
// @code_url http://pettanr.sourceforge.jp/javascripts/work.js
// @code_url http://pettanr.sourceforge.jp/javascripts/system.js
// @formatting pretty_print,print_input_delimiter
// ==/ClosureCompiler==

closure-compiler で minify したらサクッっと動く.これで atom 機で様子を見てみます.
クライアントは、今は pettanr.editor を close, open できるようにしています.panel file 読み込めるようにもしていきます.あとは、ズーム機能を含む panel viewer か.

file 周りでちょっと迷っていて、OS 的なものにしていく場合、pettanR のAPI や json のパラメータ とかの設定もファイルドライバみたいなものに置かなくちゃな、と.(サービス毎に様々な API や データパラメータを変換したりして、js製 OS のファイルシステム用のファイルデータとして 格納する)

基本的に クライアントは 同一ドメイン上のサーバのサポートがなければ何もできないのですが、jsonp で使えるサービスもあるし、js で認証・更新できる Webストレージサービスなんてのも もうあるのかな?? 現状でもクライアントを AIR で作るなり、ブラウザアドオンにすると、複数のペッタンR サイトに同時にログインして、データを操作する、なんてことは当然視野に入るわけで、それを見越しておくと、pettanR 準拠サーバー用標準ファイルドライバ、ということになる.
Reply to #61445

Javascript本 (2012-02-27 19:00 by itozyun #62480)

結構評判のいい パーフェクト Javascript がようやく図書館で借りられた.ざっと読んだけどいい感じです.高速化手法も仕入れられたし、ファイルのドラッグドロップできるAPI とかワクワクする.ついでに 老子 も借りておこうと思ったけどなかった(><
オライリー の javascript も結構いい感じで重宝しています.
Reply to #61445

0.5.x (2012-03-05 21:21 by itozyun #62604)

ここしばらくの議論によると、ぺったんR WebAPI に由来するデータ、他のWebAPI に由来するデータがシステムに混在することになるので、めんどくさいことになりそう.そこで、大掛かりな変更を考えている.

名前空間を os と pettanr に分けて、pettanr はファイル取得の手続きをファイルドラバとして os に登録する.エディターもアプリケーションとして os に登録する.そんな感じに、OS を例え話にすれば、コードが見渡しやすくなるかな、と.

で、現状のコードからどうやって 0.5.x なコードに修正していくか?を考えていたのだけど、フルスクラッチは嫌だ(><
そんなことをずっと考えていたけど、どうも、pettanr.file 内の pettanR サーバ固有の処理を外に出す、そこから手を付けるのがいいみたいだ.
Reply to #61445

RE: 0.5.x (2012-03-06 07:53 by yasushiito #62617)

サーバの機能の結構な部分をクライアントでもやらなきゃいけないんで大変ですよね。
サーバに組み込まれているプラグインとかサーバの設定をクライアントが知らないと話が進みませんよね。
Reply to #62604

プラグインとかサーバの設定 (2012-03-07 13:25 by itozyun #62636)

コミック、パネル、アーティスト、作家、ライセンス、といったコアなデータについては、API の URL の一覧と、author_id, artist_id があれば、ツリー状にデータを蓄えていけます.
json が ページ状になってきたら、その最大ページ数は、どのタイミングでもらえましたっけ?まだ更新くださった Wiki を見ておないので、もう書いてあったらスイマセン.

> サーバに組み込まれているプラグインとかサーバの設定をクライアントが知らないと話が進みませんよね
どんな機能のプラグインかにも寄ってくると思いますが、js に追記や変更が必要になりそうですね~ 追加のドライバーとして記述できるなら、ずいぶん管理は楽になりそうです.サーバが側で script タグを足すだけにできそうです.
ユーザーがどんな エクスプローラコンテナ を追加しているか?みたいな情報もサーバ側で持たないとまずいのかな、、、??ちなみに Opensocial Dashbord では、ユーザーがいろいろセッティングした情報は 数キロバイトまで、という制限はありますが、Google さんが持ってくれてました.
Reply to #62617

RE: プラグインとかサーバの設定 (2012-03-09 18:31 by yasushiito #62692)

[メッセージ#62636 へのフォロー]

> > サーバに組み込まれているプラグインとかサーバの設定をクライアントが知らないと話が進みませんよね
> どんな機能のプラグインかにも寄ってくると思いますが、js に追記や変更が必要になりそうですね~ 追加のドライバーとして記述できるなら、ずいぶん管理は楽になりそうです.サーバが側で script タグを足すだけにできそうです.
> ユーザーがどんな エクスプローラコンテナ を追加しているか?みたいな情報もサーバ側で持たないとまずいのかな、、、??

おぼろげな構想ですが。
コンテナとかいうのは二つあって、一つはタブメニュー(Home|Comic|list|Picture|Setting)で、もう一つは編集ページのWindowメニューで出てくる機能です。どちらのメニューにも機能追加していけます。railsには機能追加の仕組みが備わっているので、新機能にかかわるページを指定した上で、要所にフックとコールバックをかませればできそうな気配です。ただ、jsで同じことやるには???です。このやり方はサーバがプラグインを組み込んでいないとできないですが、大抵の拡張はできます。サーバ管理者がありったけプラグインを組み込んで、使う使わないはユーザの自由って形ですね。
サーバのプラグインに頼らないプラグインも技術的には可能っぽい。ただ、設定ページみたいなのはぺったん側は持てないので、プラグインが使う外部サイトがぺったんR専用の拡張サイト(そっちはそっちでログインしといて)か、設定情報がまるで要らないサイトかのどちらかになりますね。どっちも使い道が限られるので、大半はサーバに組み込むプラグインになるかと。

まだrailsの拡張の仕組みを調べている最中なので、まだまだですね。
Reply to #62636

RE: プラグインとかサーバの設定 (2012-03-12 08:43 by itozyun #62729)

> 一つはタブメニュー(Home|Comic|list|Picture|Setting)で、もう一つは編集ページの Windowメニューで出てくる機能です。
今進めているコーディングと違和感ないと思います.
タブメニューは、アプリケーションのクイックランチャーとなるように書き換えています.
編集ページはアプリケーションという扱いになります.あとからでも Window を追加できるように、メソッドを出しておきますね.とりあえず、デバッグモードの時だけデバッグログ用の Window を外から追加させようと思っていたので、それが最初のサンプルになるかもしれません.

> ただ、jsで同じことやるには???です。
ここら辺は錬りこんでないですが、どれも js を結構書くことになってしまいそうに思います.
サーバには明るいけど、js はやっていない座長には負担になるかも、、、

■ドライバーを書くだけでできるケース
例えば、ニュースサイトの新着フィードからテキストを引用して、バルーンのテキストにする、という機能追加の場合.
Ajax Feed API とかでニュースフィードを jsonp で取得して、エントリーの一件ごとにテキストファイルを作って蓄えていく、ファイルドライバーを書きます.
このテキストをエクスプローラからアプリケーションにドロップすると、fileDrop イベントをアプリケーションがキャッチして、テキストファイルだったので新規にバルーンを追加、という感じかな、と.

本格的なものとなると、ドライバー と アプリケーション を用意することになりそうです.または、ドライバーと 編集アプリ用の追加 Window ですね.

以上は、データや js を ぺったんR が提供する場合です.
外部サイトが絡む場合は仰るとおり、使いどころが限られたり、外部サイトでも認証が必要だったり、綺麗にはいきませんね、、、

そういえば、拡張機能を導入してまで コマを編集したい、というユーザーはなかなかのヘビーユーザなので、ブラウザアドオンやインストールアプリ経由で投稿というふうになっていくのかも.
Reply to #62692

システム定数 (2012-03-13 22:43 by itozyun #62760)

今、ファインダーいじってましたが、そういえばいちコミック辺りのパネル数って制限ありましたか??システムの定数としてあったりしたら、教えて欲しいです.上限に達したらクライアントでも、新しいコマを作る、を禁止しておきます.

パネルも、あんまり大量な要素を貼り付けられても、システムにもブラウザにも負荷がかかるだけなので、制限設けておきましょうか?これは実際に動き出してから操作しながら決めていけばいいですが.

アップロード画像のファイルサイズ上限も、まだ Chrome だけとか限られそうですが、あらかじめクライアントでファイルサイズを取得しておくことができるかも.上限を超えていたらその時点でアップロードを中止できます.
Reply to #62617

RE: システム定数 (2012-03-14 07:56 by yasushiito #62762)

[メッセージ#62760 へのフォロー]

> 今、ファインダーいじってましたが、そういえばいちコミック辺りのパネル数って制限ありましたか??システムの定数としてあったりしたら、教えて欲しいです.上限に達したらクライアントでも、新しいコマを作る、を禁止しておきます.
>
> パネルも、あんまり大量な要素を貼り付けられても、システムにもブラウザにも負荷がかかるだけなので、制限設けておきましょうか?これは実際に動き出してから操作しながら決めていけばいいですが.

今のところありませんね。

> アップロード画像のファイルサイズ上限も、まだ Chrome だけとか限られそうですが、あらかじめクライアントでファイルサイズを取得しておくことができるかも.上限を超えていたらその時点でアップロードを中止できます.

一応2MBとなってますが、もっと小さくてもいいかも。
Reply to #62760

RE: システム定数 (2012-03-15 14:00 by itozyun #62790)

> サーバの機能の結構な部分をクライアントでもやらなきゃいけないんで大変ですよね。
> サーバに組み込まれているプラグインとかサーバの設定をクライアントが知らないと話が進みませんよね。
この意味がようやく分かりました(><

サーバ側で行うすべてのチェックと同じものをクライアント側でも行えば、サーバへのリクエストを最少にできます.
しかしサーバ側にある関係する全ての処理と設定をクライアントに組み込んだり通知したり、は無茶なので.

じゃぁ、どうしましょう って話ですね.
ぺったんR OSS の仕様になるのかな?
通知する・通知しない の線引きからまず決めた方がいいでしょうか??

・絶対通知する
・通知しておけばクライアントがうまく扱ってくれるかも.
・絶対通知してはいけない
Reply to #62762

RE: システム定数 (2012-03-15 18:43 by yasushiito #62792)

通知というか、クライアントが問えばサーバが応える形ですかね?
もう少し「見えて」から話を進めたほうがいいかな。
Reply to #62790

0.4.4 (2012-03-14 21:43 by itozyun #62776)

pettan.file に 埋め込まれてた pettanR サーバに固有な部分を pettanr.driver に分離しました.おかげで見晴らしが良くなって、Comic, Panel, Author, Artist といった pettanR 固有なファイル形式に対していい感じに対応できるようになりました.残念ながら フリーアイコン素材に Comic, Panel, Author, Artist といった素材がないので、今回は僕がさっさと殴り書きしています.

コミットはしていませんが、プロジェクトの Web ページにはアップロードしました.http://pettanr.sourceforge.jp/work.html?view=1&exjson=false&debug=true
Comic を表示すると PettanR root からの階層が表示されますが、これはデバッグ用に一時的にそうしています.

ちなみに、ファイルシステムには Windows や Linux のように tree 状になるものと、TORON のようなハイパーリンク式になるものがあります.
そして ぺったんR ではどうも ハイパーリンク式になりそうです.ハイパーリンク式の場合、永遠に階層を下っていけるような挙動になります.Web ページのハイパーリンクを永遠に移動し続けられるのと同じです.ツリーで表現するのがいいのか?ハイパーリンクがいいのか?は扱うリソースによって変わるのだと思います.
Reply to #61445

RE: 0.4.4 (2012-03-15 07:44 by yasushiito #62782)

ふむ。
サーバの現状では
PettanR root > Comics

LatestComics(Default)
フォルダがあって、そこをクリックすると新着順で見れる感じかな。
他のフォルダはプラグインっぽいので機能追加と。このクライアントはデフォルトで自分の作品と作家別を追加してある感じ。
Reply to #62776

RE: 0.4.4 (2012-03-15 08:15 by itozyun #62784)

> LatestComics(Default) フォルダがあって、そこをクリックすると新着順で見れる感じかな。
(`Д´)ゞラジャー!!
Json の url とあとちょっとパチパチ書くだけで、多分いけます.

> 他のフォルダはプラグインっぽいので機能追加と。
なるほど.例えば、Comics の下に プラグインフォルダを追加したい場合に備えて、pettanr.driver.resisterPlugin() みたいなのを考えておきます.

> このクライアントはデフォルトで自分の作品と作家別を追加してある感じ。
サーバからもらった current_author.id を pettanr.driver の MyAuthorID に突っ込むように書き直しておきます.
Reply to #62782

iframeオーバーレイ (2012-03-15 08:52 by itozyun #62785)

work.html 以外のページで ヘッダーのランチャーをクリックすると iframeオーバーレイで work.html に入っていました.でも、アドレスと画面が一致しない、元の画面と iframe の2画面を表示しているのは負荷が高い、遷移で十分じゃん、ということで iframe オーバーレイを外そうと思います.

ちなみに、一画面で完結する Web アプリケーションには、レスポンスが早い、リクエストを減らせる、というメリットがある一方、ページ遷移には js で貯まったガベージがクリアできる、というメリットもあります.このあいのこで、ずっと保持したいデータは元ページにおいたうえで、複雑なアプリケーションを iframe 内で読み込めば、iframe を閉じるだけでメモリを開放できるかも、と思いました.でも参照が残ってしまうと 複雑なアプリケーションのメモリを消しきれないで逆に足を引っ張ることになるかもで、それなら一ページできちんとメモリ開放するのと変わらないかも.
Reply to #61445

MyComics と MyPictures (2012-03-19 20:45 by itozyun #62846)

MyComics と MyPictures の直下に、作家名のフォルダができていますが、これは間違いです.手元では直ってますので、悪しからず!
Reply to #61445

version0.4.5 (2012-03-25 13:39 by itozyun #62906)

画像アップローダーとコミックの新規作成(こちらはモック)を追加した、version0.4.5 をコミットしました.
localhost での 画像アップロードテストは、ie6,7,8, Firefox3.6, Safari3, Iron8, Opera9.6, Opera11 で動作を確認しています.ブイv

current_artist が貰えていないので、MyPictures には id:1 の絵師のデータが入っています.
Reply to #61445

version0.4.6 (2012-03-30 10:35 by itozyun #62982)

コミックの新規作成がとりあえず動いた version0.4.6 をサーバーのmasterに commit しました.
フォームUI で select をまだ作っていないので、visible, editable がセレクトになっていない(動作しない)のと、コミック一覧を panels.json で作っているのをそういえばまだ修正していないので新規に作成したコミックがエクスプローラに反映されません.(パネルを作れば反映されると思います、、、)悪しからず.
Reply to #61445

RE: version0.4.6 (2012-03-30 17:00 by yasushiito #62985)

[メッセージ#62982 へのフォロー]

> コミックの新規作成がとりあえず動いた version0.4.6 をサーバーのmasterに commit しました.

もう少ししたらブランチ切りましょうね。こちらは原画コントローラのテストが通ったあたりで止めます。

> フォームUI で select をまだ作っていないので、visible, editable がセレクトになっていない(動作しない)
データ足りますか?サーバが用意するべきものがあれば言ってください。

> コミック一覧を panels.json で作っているのをそういえばまだ修正していないので新規に作成したコミックがエクスプローラに反映されません.(パネルを作れば反映されると思います、、、)悪しからず.
こちらが途中で仕様を変えたんですよね。コマの削除関連で処理が複雑になるのを嫌って二段階にしたんです。ユーザから見れば不親切なんで、同時に投稿できるUIも悪くはないんですが。
あと、コミック一覧で返ってくるリストは非公開コミックを含まないことをお忘れなく。
Reply to #62982

RE: version0.4.6 (2012-03-30 22:03 by itozyun #62988)

> データ足りますか?サーバが用意するべきものがあれば言ってください。
今週末でローカル環境を触りつつ、思いついたことがあればまとめておきます.

コミックの新規作成時の、width, height のデフォルト値と visible と editable の選択肢ですが、事前に教えてもらえているとあとあと楽かもしれません.(それほどいじるようなものでもないので、js に定数として埋め込んじゃってもよさそうですが.友人まで編集可能、とかの選択肢をサーバがフレンド機能をサポートしない場合は外しておくとか.)

新規コミックのコンソールを開くたびに js を取得する実装では、ユーザが新規コミック作ろうかな、やっぱやめた、やっぱり作る、やっぱやめた、を繰り返すと、毎回発生する js のリクエスト分損になります.そこで、ユーザーが全てのデータを入力してバリデートも通った段階で、はじめて js を取得してhidden なフォームを作る、という手順にしたいと思っています.(そんなわけで事前に貰えると助かります.)

> コミック一覧で返ってくるリストは非公開コミックを含まないことをお忘れなく。
おっしゃるとおり!言ってもらわないと危なかった、、、
Reply to #62985

RE: version0.4.6 (2012-03-31 07:48 by yasushiito #62989)

[メッセージ#62988 へのフォロー]

> コミックの新規作成時の、width, height のデフォルト値
これはクライアントが勝手に決めていいです。サーバには妥当な数値はわからないので。

> visible と editable の選択肢ですが、
これは非公開・自分だけです。勝手に公開されても困るし。知らないうちにコマ投稿されちゃうとか笑い話にもならない。

> 新規コミックのコンソールを開くたびに js を取得する実装では、ユーザが新規コミック作ろうかな、やっぱやめた、やっぱり作る、やっぱやめた、を繰り返すと、毎回発生する js のリクエスト分損になります.そこで、ユーザーが全てのデータを入力してバリデートも通った段階で、はじめて js を取得してhidden なフォームを作る、という手順にしたいと思っています.(そんなわけで事前に貰えると助かります.)
もしかしたら一度渡したフォームを使い回せません?ダメ元で試して欲しいところ。
Reply to #62988

RE: version0.4.6 (2012-03-31 08:19 by itozyun #62990)

> もしかしたら一度渡したフォームを使い回せません?ダメ元で試して欲しいところ。
仰るとおり、その手が一番効果的です.可能です.この件には認証文字列を埋め込んだフォームの寿命が関係ありそうだったので、その点を確認してから、と思っていました.一度発行したフォームの有効期限ですが、フォームが submit() されるまで、またはユーザーのログアウトまで、ということで大丈夫ですか??
Reply to #62989

RE: version0.4.6 (2012-03-31 08:45 by yasushiito #62991)

http://d.hatena.ne.jp/koshigoeb/20110308/1299588233

これを見るかぎり無理っぽい?っていうか、複数のフォームをあちこちで使うとまずい…のか?

http://d.hatena.ne.jp/willnet/20080509/1210338845

このように、認証文字列だけもらうって手もあるみたい。
Reply to #62990

RE: version0.4.6 (2012-03-31 10:29 by yasushiito #62992)

一旦コミットしてPUSHしときました。
Reply to #62985

version0.4.7 (2012-03-31 12:35 by itozyun #62994)

pull して動かしてみました.

画像をアップロードコンソールからアップロードすると 500 Internal Server Error が返ります.でも画像は追加されていて、エクスプローラに表示されます.
original_pictures.json の内容ですが、自分がオーナーの画像しか取れなくなっているようです.これはこの動きで正しかったですか?

僕も comics エクスプローラ周りをいじった version 0.4.7 を push しておきます.コミック を comics.json から取得するようにしてあります.MyComics については とりあえず author_id を見て突っ込んでいます.

panel 以下の取得は、comics がクリックされたら、コミックの id:1 の場合 comics/1.json/play を取得すればいいでしょうか?
Reply to #62992

RE: version0.4.7 (2012-03-31 13:43 by yasushiito #62995)

[メッセージ#62994 へのフォロー]

> pull して動かしてみました.
>
> 画像をアップロードコンソールからアップロードすると 500 Internal Server Error が返ります.でも画像は追加されていて、エクスプローラに表示されます.
申し訳ない。テストが通ったといってもコントローラだけでして、モデルでコケてました。pushしたので大丈夫。

> original_pictures.json の内容ですが、自分がオーナーの画像しか取れなくなっているようです.これはこの動きで正しかったですか?
そうですね。こちらは原画なので、本人だけ。他人のはresourcesの方でみます。

> 僕も comics エクスプローラ周りをいじった version 0.4.7 を push しておきます.コミック を comics.json から取得するようにしてあります.MyComics については とりあえず author_id を見て突っ込んでいます.
こちらの動きは後でじっくりと。

> panel 以下の取得は、comics がクリックされたら、コミックの id:1 の場合 comics/1.json/play を取得すればいいでしょうか?
今のところは。ここはテスト書いてないゾーンです。
URLがダサいので落ち着いたら変えようかと考えてるんですよ。
http://sourceforge.jp/projects/pettanr/wiki/ComicsShow
こっちが未使用なのはもったいないから統合するかも。
Reply to #62994

version0.4.8 (2012-03-31 16:05 by itozyun #63000)

> テストが通ったといってもコントローラだけでして、モデルでコケてました。pushしたので大丈夫。
pull して修正を確認しますた!

> > original_pictures.json の内容ですが、自分がオーナーの画像しか取れなくなっているようです.これはこの動きで正しかったですか?
> そうですね。こちらは原画なので、本人だけ。他人のはresourcesの方でみます。
> > panel 以下の取得は、comics がクリックされたら、コミックの id:1 の場合 comics/1.json/play を取得すればいいでしょうか?
> 今のところは。
resource_pictures.json で画像一覧取得、MyPictures 以下は original_pictures.json に修正してみました.
コミック下のパネルを comics/1.json/play(等)で取得するように修正しました.

以上の変更したものを push しておきました.
今後の commit は変えたほうがいいでしょうか?

そうそう、IE6, 7 で確認しましたが、新規登録時に current_artist.id の値がないためエラーが出ていました.
アーティスト登録していないユーザーには、current_artist = {} 自体を出力しない感じでいかがでしょう?
current_artist = {
 id: ,
 name: "テスト"
}
Reply to #62995

RE: version0.4.8 (2012-04-01 09:28 by yasushiito #63009)

[メッセージ#63000 へのフォロー]

> 今後の commit は変えたほうがいいでしょうか?
そのほうが話は速いかも。

> そうそう、IE6, 7 で確認しましたが、新規登録時に current_artist.id の値がないためエラーが出ていました.
> アーティスト登録していないユーザーには、current_artist = {} 自体を出力しない感じでいかがでしょう?

では、そうします
Reply to #63000

RE: version0.4.8 (2012-04-01 13:02 by itozyun #63017)

> > 今後の commit は変えたほうがいいでしょうか?
> そのほうが話は速いかも。
よさそうな解説ページがあったのでブランチ・マージ理解できるようにします (`・ω・´)ゞ

http://progit.org/book/ja/ch3-2.html
Reply to #63009

RE: version0.4.7 (2012-03-31 13:49 by yasushiito #62996)

v03_testにブランチしときました。
これからはこっちでテストゴニョゴニョします。
Reply to #62994

version0.4.9 (2012-03-31 17:52 by itozyun #63003)

コンソールのデザインをきちんとさせたものを master に push しました.個人的にデザインをある程度やっておかないとモチベーションが落ちるので、、、
Reply to #61445

RE: クライアント関連 (2012-04-01 10:10 by yasushiito #63010)

masterをv03_testにマージしておきました。
Reply to #61445

コマの投稿 (2012-04-01 12:04 by yasushiito #63015)

超やっつけですが、コマの投稿を受け取れるようにしました。
http://sourceforge.jp/projects/pettanr/wiki/PanelsControllerCreate
テストもしてないしドキュメントもありませんけど。例外処理もしてないのでInvalidなデータを送るとモロこけします。

http://localhost:3000/panels/new.js
のフォームを使ってjsonってフィールドにjsonデータ入れて送信してください。

与えるデータはpanelより下のデータを文字列化したものです。
http://sourceforge.jp/projects/pettanr/wiki/JsonApi
これでいうなら、

{
"border": 1,
"comic_id": 5,
"resource_picture_id": 1,
"width": 400,
"height": 200,
....
}

のようにpanelを含まないようにしてください。
Reply to #61445

RE: コマの投稿 (2012-04-01 12:50 by itozyun #63016)

ありがとうございます.では早速パネルテストPOST用のコンソールを組んでみます.
Reply to #63015

RE: コマの投稿 (2012-04-01 14:35 by itozyun #63018)

パネルのコンソールを追加した v03_client_test って ブランチを作って commit して push しましたが sourceforge に表示されない、、、

手元では、以下のデータを ポスト してみましたが、500 Internal Server Error でした(><
{"border": 1,"comic_id":9,"width":300,"height": 200,"t":1}

comic_id はログインユーザーの作成したコミックのものです.
Reply to #63015

RE: コマの投稿 (2012-04-01 14:48 by itozyun #63019)

困ったので master に push してしまいました、サーセン(><
Reply to #63018

RE: コマの投稿 (2012-04-01 16:22 by yasushiito #63020)

これでどうですか。
{"comic_id":1,"resource_picture_id":1,"width":400,"height":200,"border":1,"x":0,"y":0,"z":1,"t":1,"panel_pictures_attributes":{"new1":{"resource_picture_id":3,"x":10,"y":135,"z":3,"t":1,"width":100,"height":103},"new2":{"resource_picture_id":2,"x":20,"y":275,"z":4,"t":2,"width":150,"height":233}},"balloons_attributes":{"newf1":{"balloon_template_id":1,"system_picture_id":2,"tail":1,"size":1,"x":35,"y":120,"z":5,"t":3,"width":81,"height":63,"speaches_attributes":{"newf1s1":{"content":"test","x":10,"y":10,"t":1,"width":61,"height":43}}},"newf2":{"balloon_template_id":1,"system_picture_id":1,"tail":1,"size":1,"x":95,"y":220,"z":6,"t":4,"width":51,"height":33,"speaches_attributes":{"newf2s1":{"content":"test","x":10,"y":10,"t":1,"width":61,"height":43}}}}}
Reply to #63018

RE: コマの投稿 (2012-04-01 16:25 by yasushiito #63021)

v03_testで一緒にやりましょう。
マージもしておきましたから。
Reply to #63018

RE: コマの投稿 (2012-04-01 16:45 by itozyun #63023)

アザース(><

v03_test に パネルのコンソールからの追加、エクスプローラへの反映 の可能な version0.4.11 を push しました.

ちなみに以下のデータで、パネルの登録ができました.
comic_id はユーザーの所有する コミックのものに、t は連番となるように、wdth は コミックの width に合わせておきました.
{"border": 1,"comic_id":1,"width":300,"height": 200,"x":0,"y":0,"z":0,"t":1}
Reply to #63021

RE: クライアント関連 (2012-04-01 16:30 by yasushiito #63022)

「新しいコマを描く」ってのは機能的に無理ですね。
コミックとコマは主従関係にありますから、先にコミックを選んでおかないと。
Reply to #61445

RE: クライアント関連 (2012-04-01 16:48 by itozyun #63024)

> コミックとコマは主従関係にありますから、先にコミックを選んでおかないと。
そうでした.エクスプローラからアプリケーション(パネルエディター)を起動できるように作りこんでいきまっす.
Reply to #63022

RE: クライアント関連 (2012-04-23 19:19 by yasushiito #63384)

週末の反省の結果、間違っているのはこっちと判明。
柔軟性という理想としてはコマが主であるべき。コミックありき、なんてただの先入観・思考停止でした。
将来コマは自由に作れて、後からストーリーを編集していける形にしたい。

Reply to #63022

RE: クライアント関連 (2012-04-24 07:49 by itozyun #63389)

> 柔軟性という理想としてはコマが主であるべき。コミックありき、なんてただの先入観・思考停止でした。
それは僕もでしたw

実装としては難しくなりそうですが、とにかくひとコマ作ってみて、あとからさらにコマを追加したくなってコミックという箱が必要になる、そんな流れはありそうです.
Reply to #63384

RE: クライアント関連 (2012-04-27 07:04 by itozyun #63447)

コミックが指定されていない状態で新規パネル作成を始めたら、パネルのポストのときにまずはコミック作成のリクエスト投げたらどうでしょう??
これならクライアントにコード追加するだけです.
Reply to #63384

RE: クライアント関連 (2012-04-27 08:21 by yasushiito #63448)

わざわざコミックを作成しなくても、作家のマイパネル一覧で探せるので、後からコミックと関連付けできますよ。
それよりも、コミック読みながら末尾に追加するときは関連付けテーブルも同時に作成する必要がある。
Reply to #63447

絵師登録 (2012-04-01 17:21 by yasushiito #63025)

絵師登録が済んでないと素材の投稿フォームが壊れますね。
登録フォームを用意しました。そういう時はこちらを使ってください。
http://localhost:3000/artists/new.js
文書はこっち。
http://sourceforge.jp/projects/pettanr/wiki/ArtistsNew
Reply to #61445

RE: 絵師登録 (2012-04-01 17:49 by itozyun #63028)

ラジャー、コンソールに仕立ててみます.
Reply to #63025

RE: 絵師登録 (2012-04-01 19:23 by itozyun #63034)

絵師登録コンソールを追加した version0.4.12 を push しました.

> 絵師登録が済んでないと素材の投稿フォームが壊れますね。
まだ先になりますが、current_artist を貰わなかった場合は登録フォームを変わりに表示する、とかにします.

> 登録フォームを用意しました。そういう時はこちらを使ってください。
コンソール作りました.200 は返って来ますが、実際の絵師登録はできていないようです.
画像アップロードコンソールを開くと original_pictures/new.js が貰えず、アップロードフォームのあるページを開くと絵師登録を促す画面が表示されます.
Reply to #63025

RE: 絵師登録 (2012-04-02 08:06 by itozyun #63040)

iframe の内容を確認すると Artist was successfully created. と書かれたページは返ってきていました.
Reply to #63034

RE: 絵師登録 (2012-04-02 08:59 by yasushiito #63042)

作家idが伝わってなかったみたい。
修正はしましたけど、他でおかしくなるかも。
そもそも、作家と絵師は一対一の関係だから何回も登録できるわけないし。
Reply to #63040

RE: 絵師登録 (2012-04-02 12:40 by itozyun #63044)

> 修正はしましたけど、他でおかしくなるかも。
想像ですが、ややこしくなったり他への影響が怖い部分の気がします.

> そもそも、作家と絵師は一対一の関係だから何回も登録できるわけないし。
クライアントはいずれ、current_artist がなかった段階で、絵師登録コンソールを開けるようにして、絵師登録が成功したら絵師登録コンソールをオフにします.

Reply to #63042

RE: 絵師登録 (2012-04-02 20:52 by itozyun #63055)

動作確認しました.

複数のブラウザからアクセスしていて、一方のブラウザでは絵師登録を済ませて、とかになるとややこしそうですね.
幸い new.js が来たり来なかったりで判断は付くので、絵師でないのに絵師登録の js が来なかったら、別のブラウザで絵師登録を済ませた、と判断してリロードを促すとか、そこはまたおいおい.
Reply to #63042

version0.4.11 (2012-04-01 17:28 by itozyun #63026)

パネルのコンソールからの追加と、エクスプローラへの反映ができる.

親データへの参照(例えば、パネルデータにとっての所属コミックや作家)が 実データで来る場合、リソースへの id で来る場合があり、その両方に対処すべく pettanr.driver を書き換えた.
コミックをクリックしたときに取れるパネルデータの場合、まずコミックのデータを取得してから初めて取得できるので、問題なくパネルにコミックへの参照を埋め込むことができる.しかし今後そうはいかない状況があるかもしれない.その場合、不足データができたときに自動で取得する仕組みがいる.
Reply to #61445

RE: version0.4.11 (2012-04-01 17:39 by yasushiito #63027)

もしかして:
二人でブランチいじりまくるとconflict大量発生?


さっき、その0.4.11をだいぶいじりました。大丈夫かな。
Reply to #63026

RE: version0.4.11 (2012-04-01 17:50 by itozyun #63029)

僕が主にいじるのは、app/views/layouts/application.html.erb と public/asset/ 下の js だけになります.おそらく大丈夫かと.
Reply to #63027

version0.4.20 (2012-04-15 17:36 by itozyun #63248)

クライアント内部を、os と pettanr に分けて交通整理していく準備が整ってきた.
version0.5 では上記分離を行い、HelloWorld サンプルも用意できると思う.

0.4.20 は、エクスプローラのコミック・パネルからエディターを起動できるようになった.
アーティストからは、イメージエクスプローラを起動できる.
また、エディターのパネルピクチャ変更用のイメージエクスプローラも絵師フォルダを受け取って、その下のリソース画像一覧を表示するようになった.
Reply to #61445

version0.4.22 (2012-04-18 22:23 by itozyun #63317)

エディタ内部にあった、パネルデータの json出力、html出力 を外に出して、flipH, flipV は width, height をマイナスにするという最新の仕様を(ようやく)反映しました.
エクスプローラのコミックやパネルからエディタを起動して編集した場合、コミックやパネルのIDが json にも反映されます.(コミックからエディタに入った場合は、パネルIDは設定されない.)
画像を追加するためには、一度エクスプローラで 画像のjsonを読み込んでおく必要があるのと、新規画像の追加ではまだ 絵師ID が 1 の人しか追加できません、、、まだまだエクスプローラの作りこみが甘いのです、、、(>< いずれはドラッグドロップで画像をエディタに追加したり、ローカルの画像ファイルをエクスプローラにドロップでアップロードさせたりしたいです、、、
Reply to #61445

version0.4.23 (2012-04-20 08:41 by itozyun #63357)

ie で geJson 時のファインダーの更新がうまく行かないのを修正.原因は $.ajax() だった.

getJson のファインダーの更新は、非同期に行われるはずだったが、json リソースが開発中でローカルファイルの場合、ie では同期で success() が呼ばれていた.必ず非同期になるように処理をかませた.

イメージエクスプローラ への画像の追加が、画面サイズによって(?)うまく行かない挙動に遭遇した.(Firebugを表示してウィンドウのサイズが半分になるとなぜか画像の追加がこけていた)Dom処理がたて続く部分なので、画像の追加をフェードインの後とすると症状は治まった.
Reply to #63317

version0.4.26 (2012-04-24 21:40 by itozyun #63401)

新機能を実装したいところですが、ie6, 7 で頻繁にクラッシュするという挙動に遭遇してしまい、急遽コードのブラッシュアップを行うことにしました.
イメージエクスプローラの操作の前後でよくクラッシュするので、画像ロード用のイベント解除などをきちんと行うように見直しました.

ややクラッシュの頻度は減ったみたいですが、まだとても人には使ってもらえないレベルです、、、

js のコード量が 260KB、jQuery.min を加えると 350KB に達しているのでそのせいかもしれません、、、または最近 prototype や instanceof を使うようにコードをいじっていますがそれが影響しているのかも、、、

・コードの minify をしてブラウザへの負荷を減らすとどうなるか?試してみる.
・以前のバージョンを動かして症状の出始めた変更を特定する.
・IE 用のメモリリーク監視ツールを使ってみる.

こんなことを少しづつ取り組んでみます.

またアプリケーションの close で全ての dom 要素とイベントリスナを削除して省メモリするような 実装が必要かもしれません、、、ぱねぇw
Reply to #61445

RE: version0.4.26 (2012-04-25 07:57 by yasushiito #63407)

ある程度のスペックは必要ってことですね。たぶん。
今の段階で苦しいとなると根本的対処をしないことには安定した開発体制を継続できないですね。まだまだ先は長いので。

ところでサーバがメモリ食い過ぎじゃないですか?サーバを別マシンでやってみては。
Reply to #63401

RE: version0.4.26 (2012-04-25 08:53 by itozyun #63409)

これはマシンスペックや、そのときのマシンの負荷に関係なく、ie6,7 のおそらく js 周りの実装の甘さとして起こるみたいです.

ie6 なぞは ajax という言葉が生まれる前のブラウザですし.この辺りのブラウザは最新のブラウザと比べて、十倍以上の js 実行速度の開きがあります.また負荷が高くなると勝手に js の実行をあきらめることもあるとかないとか.

なので、開発体制自体に影響はありません.デバッグでメインで使っている firefox3.6 では pettanR クライアントはガシガシ動いています.

GoogleMap みたいな非同期でガンガン画像を読み込むアプリだって ie で動いているので、単純に僕の腕が足りていないのだと思います.モバイル対応のためにも、コードの最適化は鋭意進めていきます.
Reply to #63407

RE: version0.4.26 (2012-04-25 16:25 by yasushiito #63426)

なるほど。
知らないで出過ぎた口を挟みました。

ie死ねって言われるの、分かりましたわ。
Reply to #63409

RE: version0.4.26 (2012-04-27 06:58 by itozyun #63446)

コードの minify をやってみましたが駄目でした(><

今度は メモリリーク監視ツールを使ってみます.これには、IE6がインストールされてる環境を用意しなくちゃいけません、、、
そして一番やりたくないのが、バージョンを戻しながらのテスト、、、

僕はキャリアが浅いので、過去のノウハウを探しつつやる様は、ブラウザの歴史を遡っていくような感覚になるときもあります.
ie6 はデフォで png を使えないのが辛いですが、それ以外はなんだかんだで対処法もあったりするのでリリース時期にしては健闘している、という印象を今回の対処ができた暁には持とうと思います.

そうそう、健闘したのは、氏ね、といっているそのWebエンジニアのみなさんなわけですがw
Reply to #63401

version0.4.27 (2012-04-28 06:56 by itozyun #63457)

たくさん appendChild するときには timer を入れてあげる、と kQuery の人がブログで書いていたのを思い出したので、それを入れています.
イメージエクスプローラではこけなくなった気がしますが、テキストの追加でこけます、、、

いい機会なので、メモリリーク監視をやって、あとなんとなくアレじゃないか、という変更も思いつくので、ロールバックもやってみます.
version 0.3 は全く問題ないのでなんとかなるでしょう、、、

> ビルトインオブジェクトに拡張したい10のメソッドCommentsAdd Star
> http://d.hatena.ne.jp/ofk/20080922/1222047483
> Array.prototype.eachAsync 何度もDOMツリーに項目を追加するときなどはこれを使う。

おっと、js でかっちりイメージを触りだすときにとても助かる、uupaa さんの画像用ライブラリを jQuery 実装されてますね.あとでコード見ておきます.
> jQueryのプラグインを三つ作りました。
> http://d.hatena.ne.jp/ofk/20110905/1315232333
>完全に状況を掌握した画像の遅延読み込みの実現 - latest logと JavaScript で、画像本来のサイズ(幅, 高さ)を取得する方法 - latest logをjQueryプラグインとして実装したものです。

kQuery の最終版が Webアーカイブにもない、、、
Reply to #61445

version0.4.31 (2012-05-15 23:25 by itozyun #63810)

add Image から 絵師を横断して画像を選択できるよ!

http://sourceforge.jp/projects/pettanr/images?id=3212
Reply to #61445

version0.4.32 (2012-05-17 07:01 by itozyun #63834)

add Image から 素材画像ファイルをクリックするだけで 画像をコマに追加できるよ!

http://pettanr.sourceforge.jp/work.html?debug=true
Reply to #61445

RE: version0.4.32 (2012-05-18 08:03 by yasushiito #63851)

だいぶそれらしくなってきてwktk
Reply to #63834

RE: version0.4.32 (2012-05-19 16:51 by itozyun #63875)

キャラが並ぶと壮観ですね!
Reply to #63851

version0.4.33 (2012-05-19 16:50 by itozyun #63874)

バルーンの尻尾を 0 度のとき 上を向くようにして、0 ~ 359 の範囲となるようにする.
パネルデータ有りでエディタを起動した時に、要素の上下が正しく反映されない問題を修正.(検証用のパネルが Hello world コミック 2 コマ目になります.)
リソースのURL取得がうまく行かない場合があり、サーバーのサポートがない場合を(file:// と http://pettanr.sourceforge.jp/)var has_server_support = false; の有無で判別するようにする.
Reply to #61445

version0.4.34 (2012-05-21 08:19 by itozyun #63927)

吹き出しが小さいときは、線の太い画像を使うようにする.
吹き出しのリサイズ時(vector=false)に ie6 で画像のリサイズが行われない問題に手当て.

以下からアクセスするとSVG等を備えたブラウザでも ベクター画像のないブラウザのモードが再現できます.
http://pettanr.sourceforge.jp/work.html?view=editor&vector=false
Reply to #61445

RE: クライアント関連 (2012-05-23 19:25 by yasushiito #63977)

素材一覧にライセンスのマークを入れるスペースありますか?
もしかしたら複合的に作成された派生作品では、原作たちのライセンスがずらーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーっと並ぶかもしれないんですけど。
そうでなくともタイトルとかあると表示スペースけっこう取りますが。
Reply to #61445

RE: クライアント関連 (2012-05-24 05:41 by itozyun #63990)

エクスプローラ画面で素材をクリックしたときの素材のビュワー画面になると思いますが、情報が増えてもきちんと表示させます.
Reply to #63977

RE: クライアント関連 (2012-05-24 08:02 by yasushiito #63993)

[メッセージ#63990 へのフォロー]

> エクスプローラ画面で素材をクリックしたときの素材のビュワー画面になると思いますが、

エクスプローラ画面も、です。
マークというと語弊があるかもですが、その画像がどういう経緯で構成されたかわかるように、すべてのライセンスを表示するってことです。
三つの画像を合成したなら、三個(自分のライセンスも含めれば四つ)のライセンス表示がでますよね?
まぁ数個くらいなら余裕なんでしょうが、構造上二十個とかもありえるんで、そうなった場合、場所を食い過ぎて一覧としての用をなさないですよね。かといって一部は省略って訳にはいかないし、システム側が「五個までにしてください」なんて頼めないし、どうしましょ。 
条文を読む限り「クリックすればわかるやん」って逃げる訳にはいかないので。
Reply to #63990

RE: クライアント関連 (2012-05-24 09:28 by itozyun #63998)

エクスプローラ画面では、yas さんも危惧されている通り、仮に複雑なライセンス情報を表示するとなると、
操作性を損なうことになりかねません.

>(5)二次的著作物の場合には、当該二次的著作物中の原著作物の利用を示すクレジットを表示しなければならない。
> これらのクレジットは、合理的であればどんな方法でも行うことができる。

そこで、ビューワ( pettanr.premiumStage )だけと言ったことですが根拠ですが以上の、合理的であればどんな方法でも行うことができる になります.

--------------------------------------------

本家がやってる CC の検索ページになります.
この画面を参考にまた考えておきますね.
http://commons.wikimedia.org/w/index.php?title=Special%3ASearch&redirs=0&search=sky&fulltext=Search&ns0=1&ns6=1&ns14=1&title=Special%3ASearch&advanced=1&fulltext=Advanced+search
Reply to #63993

RE: クライアント関連 (2012-05-24 16:48 by yasushiito #64000)

合理的であっても不公平な扱いがあると許さないと解釈してます。僕もぺったんRライセンスのサムネイル化では「バラバラに縮小しちゃダメ」って書きました。機械的にみなが同等の扱いを受ければいいのですが。

まぁガラクタデータでもいいので、いっぺん表示イメージをみるのが話は早そうですね。
Reply to #63998

RE: クライアント関連 (2012-05-24 20:56 by itozyun #64003)

ちなみに こちらは Google の画像検索で 改変後の営利目的での再使用が許可された画像 の検索オプションでの表示結果になります.
ライセンス表示とかはありません.

https://www.google.co.jp/search?hl=ja&as_st=y&biw=1920&bih=893&tbs=sur%3Afmc&tbm=isch&sa=1&q=cc&oq=cc&aq=f&aqi=g10&aql=&gs_l=img.3..0l10.4949.5405.0.5611.2.2.0.0.0.0.152.276.0j2.2.0...0.0.KAI0Q3w1IYQ

---------------------------------------------------------------------------

検索エンジンが画像をキャッシュしたりリサイズしたり、並べて表示できる根拠ってなんでしたっけ、、、??
Reply to #64000

RE: クライアント関連 (2012-05-25 07:45 by yasushiito #64011)

Googleは割と挑戦的だから参考にしない方がいいと思う。
Googleの「合理的」って一般人の度を越しているし。
Reply to #64003

RE: クライアント関連 (2012-05-25 08:56 by itozyun #64014)

検索エンジンのサムネイル表示について

サムネイル表示は著作権侵害に該当せず、リンク表示は今後の課題に 2003/07/09
http://news.mynavi.jp/news/2003/07/09/50.html
Reply to #64011

version0.4.35 (2012-05-28 13:26 by itozyun #64044)

コミックリーダーを追加しました.エクスプローラでコミックやパネルをクリックすると、コミックを読むことができます.
http://pettanr.sourceforge.jp/work.html にも最新を上げておいたけど、動いていないと思われ.単に jQuery のリンク先を間違えているだけなので、あとで直しておきます、サーセン.
Reply to #61445

RE: version0.4.35 (2012-05-28 23:24 by itozyun #64053)

直した.enjoy!
Reply to #64044

0.5.x (2012-07-27 08:48 by itozyun #64774)

まだようやく動いた段階ですので、一時的に次の url で 公開します.
pon と パネルエディター だけは アプリケーションを閉じて ホーム画面に戻れます.Enjoy!

http://pettanr.sourceforge.jp/0.5.x/work.html

既知の問題としては、
・IE で 動的に追加した要素に正しく css が当たらないため、パネルエディタのマウス操作がうまくいかない.
・Firefox で 要素が body の外に追加される.
Reply to #61445

version 0.5.1 (2012-07-30 10:51 by itozyun #64807)

・0.4 -> 0.5 の書き換えのときに未修整だった部分を修正.
・パネルファイルをパネルエディタで開いたときにデータを受け取れなかった問題の修正.
・オーバーレイアプリケーションが ie6,7,8 でこけていた問題の修正.起動時の dom 追加処理に タイマーを噛ませるなど.

次は version0.4 なぺったんR サーバへの組み込みです.
Reply to #64774

RE: 0.5.x (2012-08-02 10:35 by itozyun #64859)

サーバの吐き出した html と Metro なホームが(当然のこととして)干渉を起こすので、
・静的な html の部分を アプリケーション として登録.
・他のアプリケーションと同様に Metro ホームから起動する、シャットダウンして Metro ホームに戻る、機能を実装.

これで、v0.4サーバ と v0.5クライアント の結合テストが続けられる.この部分は今日・明日でテストしてコミットします.
Reply to #64774

RE: 0.5.x (2012-08-03 23:12 by itozyun #64897)

version0.5.2
ページ読み込み時にあった 静的な html タグを Page アプリケーションとして登録して、ホーム画面から Page に戻れる機能を追加.

version0.5.3
アプリケーションの要求する css を動的に追加.シャットダウン時に削除する機能の追加.アプリケーションの css が Page と干渉するために入れた処置.
Reply to #64774

RE: 0.5.x (2012-08-05 05:03 by itozyun #64923)

> ・IE で 動的に追加した要素に正しく css が当たらないため、パネルエディタのマウス操作がうまくいかない.
v0.5.5 では以上の問題を確認していない.

動的に css を追加する appplication.fetchCSS( url ) を書いたあたり v0.5.3 から直っている?
動的 css の副作用として 正しく css が適用されている??
Reply to #64774

0.5.9 (2012-08-19 00:10 by itozyun #65125)

・KeyEvent でチャタリングが起こっていたのを修正.
・コミックコンソールで close ボタンを [enter] するとエラーが起きていた.UI で onUpdate の呼び出しを非同期とする.
・UI の キー操作が IE でできなかった問題の修正.
・Util.getElementsByClassName は修正途中.
Reply to #64774

0.5.10 (2012-08-31 13:17 by itozyun #65370)

・Panel の下に MyPanels, LatestPanel を追加 /panels.json, home/panel.json を取得・表示できます.
・DHTML 用コードのつくり途中.まじめいやるとムズイ、、、
Reply to #64774

RE: 0.5.10 (2012-08-31 15:00 by itozyun #65371)

ie で DomReady イベントが http でアクセスしている場合にただしく動かない.仕方なく、ie については onload をフックする.
Reply to #65370

0.5.11 (2012-09-02 16:11 by itozyun #65379)

・UI部品へのキーイベントが動かなかった問題の修正(チャタリングの対処以降で起きていた模様)
・UI部品のコンボボックスでキーナビゲーションが動かなかった問題の修正と選択しているオプションに色を付けるようにする.
・素材画像、サムネイル画像、コマ画像のパスを最新のサーバにあわせる.
Reply to #64774

0.5.12 (2012-09-02 17:56 by itozyun #65382)

・Combobox のカレントオプションの不具合修正.
・パネルコンソールに Publish 選択の追加.
・パネル POST 時に Panel.comic_id, Panel.id, Panel.t の値があればそれを渡すように修正.(でもパネルの更新でなく、新規作成になってしまう、、、)
Reply to #64774

0.5.13 (2012-09-07 21:08 by itozyun #65435)

・カレントなパネルエレメントをマウスクリックでロックするコードを外す.
Reply to #64774

0.5.14 (2012-09-10 09:21 by itozyun #65457)

・system.UI で、フォームの2度目表示以降にエラーが起こる問題の修正.
・system.Page で 現在のページが system.js の アプリケーションとして api を利用できるようにする.(未チェック)
・Util.hasClassName の実装修正.複数のクラス名に対応.
・peta.apps.common 内で form 取得型アプリケーションのコード共通化.
・DomReady イベントのie 向け実装の修正.
・CSS の追加.DHTML 用の スタイルラッパーを提供.
・system.DHTML 一応アニメ部分のコードはだいたい揃う.filter 周りはまだ.未チェック.
・ie8以下でエラーになる不要な , の削除.
-----------------------------
・ie6(7?) 以下では、長すぎる js がエラーになる.分割か minify すると動作する.file:, localhost では動くみたいで質が悪い.
Reply to #64774

RE: 0.5.14 (2012-09-11 22:04 by itozyun #65471)

以下は勘違い,,, orz

・ie6(7?) 以下では、長すぎる js がエラーになる.分割か minify すると動作する.file:, localhost では動くみたいで質が悪い.
Reply to #65457

未実装 (2012-09-11 08:50 by itozyun #65464)

UIがない
・パネル要素の t 順変更のためのドラッグによる並び替え
・パネルのコミック内での 並び替えや削除・追加
・以上のための system.Finder の作りこみ.
・景色、リピート画像の選択 (形式は 画像、スピーチバルーン に次ぐ 第 3 のパネル要素)
・パネル要素の x,y,w,h 等の数値での入力

この他に
・パネルの詳細な内容取得.
・スピーチバルーンの定義の 外部 js 化
Reply to #64774

未実装メモ (2012-09-11 22:11 by itozyun #65472)

ファイルアイコンのドラッグ・ドロップを、異なる apiuser( アプリケーション ) を生成者に持つ Finder 間でも可能にするのが シェル の効能.
これをやるには、PanelEditor で実装している、独自マウスイベント伝播やら Window コントローラを system.js 側に移すことになる.

スマホ みたいな環境でファイルの操作ってどうしてるのだろう?あんな環境でも快適にファイル管理できる UI があるなら参考にしたい.
Reply to #65464

RE: 未実装メモ (2012-10-08 21:53 by itozyun #65789)

addEventListener に処理を挟んでレイヤー下にある要素へのイベント追加は、独自の経路で流すようにする.これだけで、ツールボックスの操作についてはできるように復旧した.マウスホバー時に window の body 部分をレイヤーの上に浮上させる機能を削る.

トップのメニューバーや Help window, パネル要素の操作盤、フォーム部品の書き換えはまだ、、、
Reply to #65472

RE: 未実装メモ (2012-10-15 23:07 by itozyun #65872)

トップのメニューバー, パネル要素の操作盤 は済んだ.他に見かけないわけでかなりてこずるけどコードが動いてきた!
Reply to #65789

RE: 未実装メモ (2012-10-17 21:15 by itozyun #65894)

MouseEvent のコールバック時の this を変更できるオプションを指定できるようにしてみた.

callback.call( thisObject, event );

すると、クロージャ( コンストラクタ内の function )がいらなくなり随分コーディングが楽になって メソッドを全て prototype に入れることも可能に.

クロージャのデメリットは以下になるのかな.自信なし、、、
・function ひとつ分メモリ消費が増える(多分)
・無名クロージャのメモリリーク( ie6 だけ? )
Reply to #65872

RE: 未実装メモ (2012-10-21 12:21 by itozyun #65910)

PanelEditor の WindowControl を .prototype を使うものに書き換えた.private な変数や関数にはアクセスできないようになっている.先々は system.js のシェルモジュールとしてそちらに移すと思う.

Finder の独自マウスイベントリレーの実装に昨日から取り組み中.数千ファイルを持つフォルダを表示しても大丈夫なように作り込むの、あたし.
Reply to #65894

RE: 未実装メモ (2012-10-22 09:20 by itozyun #65918)

DOM 構造を無視した独自イベント伝播のやり方がようやく見えてくる、、、

InterractiveLayer.createLayer(
 {x, y, w?, h? (MetaLayer)} || elm || id || htmlText,
 layout?, hover?, dragdrop?, scroll?,,, )

レイアウトやイベント伝播を独自実装してしまうことで、高速化を狙うという変態さん( 実体の html 要素はことごとく絶対配置 ).
Flex の Group あたりを js + html で実装する感じ、、、
Reply to #65910

RE: 未実装メモ (2012-10-22 09:24 by itozyun #65919)

遅々としててサーセン.こんなイメージなのでそれなりに作りこみます(><

例えばタッチ操作で学習できるテーブル
http://www.sharp.co.jp/igzo/images/03_04.jpg
http://www.sharp.co.jp/igzo/#Anchor03
Reply to #65918

RE: 未実装メモ (2012-10-26 09:19 by itozyun #65982)

独自マウスイベント伝播の意味がようやく見えてきた.

DOM は 表示上の DOM ツリー 順に マウスイベントを伝えていくが、必ずしもそうでない場合、独自のイベント伝播ツリーを作らなくてはいけない.

こうなってくると、通常の ブラウザ js とかけ離れた書き方になってしまうのは仕方がない.(ずっと迷ったけど)

大抵の場合、イベント伝播ツリー イコール DOM ツリーで問題ないが、パネルエディターのようにフォトショップライクなアプリを作ろうとするとそうでなくなる.
Reply to #65919

RE: 未実装メモ (2012-11-08 09:30 by itozyun #66179)

独自マウスイベント伝播 がようやく動いてきた、、、もう少しで push できます.
Reply to #65982

RE: 未実装メモ (2012-11-08 11:23 by yasushiito #66181)

Washoy待ち
Reply to #66179

0.5.15 (2012-09-11 21:50 by itozyun #65469)

・コンボボックスの選択肢ボックスの表示位置が変わった場合に追従するタイマーの追加.
・コンボボックスがカーソルキー操作時に変化方向が逆だったのを修正.
・peta.apps.js のフォーム取得型アプリケーションの共通部分をまとめて冗長なコードを削る.
Reply to #64774

0.5.16 (2012-09-14 23:24 by itozyun #65508)

・DHTMLアニメ が動作.こいつは px 単位指定以外の em, cm, pt といった単位でも動作を指示できるように作っている.
Reply to #64774

RE: 0.5.16 (2012-09-19 10:50 by itozyun #65549)

パネルエディタで、画像を追加 → その画像を削除 → ヒストリーを戻す → 復活した画像を移動 すると画像が消えるという不具合.今朝気づいて原因特定・修正したけど、いつからバグってた、、、?
Reply to #65508

0.5.17 (2012-09-24 09:06 by itozyun #65602)

* パネル要素の削除とヒストリーバックで起こる問題の修正.
* api の名前変更、addMouseEventListener -> addEventListner
* AsyncCall.add で thisObject も指定できるようにした.
* 画像のロード監視を system.js 側にコピー
* FileDrop テスト用のアプリの追加.画像をブラウザ上にドロップすると 縦横最大100px で比率維持して表示する.対応ブラウザは Firefox3.6 以降、Safari4以降.Chrome ( はサーバにあげない FileAPI が動かない.または ブートオプションを指定.)これ以外は Silverlight, GoogleGears, YahooBlowserPlus などのアドオンをインストールしてある場合のみ、クロスバックエンドな File の Drop ができる.
Reply to #64774

RE: 0.5.17 (2012-09-24 15:10 by itozyun #65609)

> これ以外は Silverlight, GoogleGears, YahooBlowserPlus などのアドオンをインストールしてある場合のみ、クロスバックエンドな File の Drop ができる.
この部分はまだです
Reply to #65602

version 0.5.18 (2012-11-12 09:08 by itozyun #66249)

えいやっと上げましたが、ポインティングイベントの開放処理をまだ書いてなかったりで、アプリケーションの切り替え時にエラーになったりします.サーバーにはまだ組み込まないでください.
・6000 行以上書き換えてる.バージョンを変えていいレベル.
・独自イベント伝播を system.js に追加し、それ用にパネルエディターを書き換えている.まだ書き換え切れていないキャビネットでエラーが出る.
・ファインダーから、ビューワー、エディターメニューが消えている.すぐに戻します!
・prototype を使って不要なオブジェクトの生成を極力防いでいる.
・コールバックに thisObject を指定できるようにして、クロージャを使わないようにしている.
・カーネルAPIから受け取るオブジェクトのプライベートな変数・関数を隠蔽している.
Reply to #64774

version 0.5.21まで (2012-11-16 09:17 by itozyun #66307)

> えいやっと上げましたが、ポインティングイベントの開放処理をまだ書いてなかったりで、
・上記が解決.
> ファインダーから、ビューワー、エディターメニューが消えている.すぐに戻します!
・まだ.

・パネル要素のコンソール(編集・削除・前へ・後へ)のキーイベントが効かない、、、
Reply to #66249

version 0.5.23 まで (2012-11-23 23:10 by itozyun #66381)

> ファインダーから、ビューワー、エディターメニューが消えている.すぐに戻します!
>・まだ.
まだ、、、

>・パネル要素のコンソール(編集・削除・前へ・後へ)のキーイベントが効かない、、、
・system.js の UI 以下の Private な値・関数を隠蔽.
・system.js の UI 以下を PointingDeviceEventTree に会わせて書き直し.
・PanelEditor の パネル要素コンソールが動く.デザインも変更.
Reply to #66307

RE: version 0.5.23 まで (2012-11-25 12:46 by itozyun #66407)

・system.js の PointingDeviceEventTree の イベントのターゲットな要素の特定やイベント発火周りをリライト.早くなっているはず.
・そのせいか、パネル要素の動作盤が外に出たときにマウスを乗せるのが難しくなっている.この辺りはまだまだ書き方が PointingDeviceEventTree に準じてないので、、、

http://sourceforge.jp/projects/pettanr/images?id=3575
Reply to #66381

version 0.5.25 まで (2012-11-30 09:05 by itozyun #66514)

> そのせいか、パネル要素の動作盤が外に出たときにマウスを乗せるのが難しくなっている.
直した.

> この辺りはまだまだ書き方が PointingDeviceEventTree に準じてないので、、、
引き続きこれ.
Reply to #66407

version 0.5.27 まで (2012-12-03 11:21 by itozyun #66540)

> この辺りはまだまだ書き方が PointingDeviceEventTree に準じてないので、、、
> 引き続きこれ.
準じた!
Reply to #66514

version 0.5.30 まで (2012-12-11 09:08 by itozyun #66625)

コミックコンソールやパネルコンソールなどを、PointingEventTree にあわせて書き直す.

まだ対応できていないのが、画像アップロードコンソールの File フォームとアップロードコンソールの Textarea 、、、

<input type="file"> は制約が多くてメンドイ、、
Reply to #66540

Input type=file のコントロール (2012-12-13 19:45 by itozyun #66642)

Input type=file はいろいろ制約がきつくて、ブラウザ毎の挙動・デザインがマチマチ.

古典的な記事?では以下がある.かなり古いブラウザでテストしていてよい.これ以降も基本的にみんなうまくいってなくて、firefox3.6 で動かないとかのしょぼいサンプルを公開している.
http://www.quirksmode.org/dom/inputfile.html
Reply to #66625

version 0.5.33 まで (2012-12-15 18:51 by itozyun #66663)

form の POST の結果を入れている隠し iframe を可視にしました.
サーバへの組み込みテストとコミットはまだです.
Reply to #66625

version 0.5.37 まで (2013-01-01 11:54 by itozyun #66821)

・ファインダーのページ切り替えで、スライドアニメーションを追加.
・ファイルの詳細表示にもスライドアニメーションで切り替わり、その画面でファイル名の変更や詳細確認、関連付けられたアプリケーションの起動を行うようにする(実装途中)
・ファインダーのフォルダ階層表示に、表示エリアの幅に合わせて自動でリサイズする機能を追加.
Reply to #66663

version 0.5.38 (2013-01-02 23:05 by itozyun #66840)

・ファイルの詳細ページから、ファイルに関連したアプリケーションを開く.
・フォルダの場合は、アイコンの右端の > の辺りをクリックすると詳細ページに入る.
Reply to #66821

0.5.39 (2013-01-12 14:12 by itozyun #66942)

・最新の v05 サーバー環境で、パネルエレメントの取得まで動作.ビュワーでの表示までが可能に.
・クライアント単体テスト用の json が v05 仕様のものではないので、クライアント単体テストが動作しません、悪しからず、、、
Reply to #64774

0.5.44 (2013-02-02 20:07 by itozyun #67229)

・ぺったんR ならではの複雑なリソース(ファイル)構造を正しく取得、扱えるように修正.素材画像の id など.
・リーダーでの パネル ファイル、ストーリー ファイル の閲覧が可能に.
・パネル 下の パネル要素の内容までを ファインダーで表示.
Reply to #64774

RE: 0.5.44 (2013-02-04 10:22 by yasushiito #67242)

wktkするほどカッコいい
Reply to #67229

RE: 0.5.44 (2013-02-04 17:34 by itozyun #67247)

アザース!!
Reply to #67242

0.5.48 (2013-02-28 09:12 by itozyun #67522)

・バルーンテンプレートの json を取得。ファイルツリーに反映、まで。
Reply to #67247

0.5.49 (2013-03-17 21:23 by itozyun #67705)

テキストの投稿ができるようになりました。
但し現在は単にデータが決め決めで、バルーンテンプレートを元にしているわけではありません。Enjoy!
Reply to #67522

RE: 0.5.49 (2013-03-18 17:16 by yasushiito #67720)

わっしょい!
Reply to #67705

0.5.50 (2013-03-31 00:19 by itozyun #67944)

pettanr.newBalloon に新しい吹き出しを作ってる途中。
今回は、balloon templete の json を取得したときに、pettanr.newBalloon.register( classname, templete ) するとこまで。つまり画面上は変化ないです、、、
Reply to #67720

0.5.51 (2013-03-31 22:02 by itozyun #67954)

・パネルエディターが新吹き出しに対応。吹き出しの追加でまずは吹き出しの一覧をエクスプローラで表示。プレミアムステージは画像にしか対応できていないので今後書き直し。
・パネルエディター上で吹き出しの大きさを変えると、正方形改では使用する画像が変わるのも確認。
・Model がまだ新バルーンにあわせられていない。Comic Reader も。
washoi!
Reply to #67944

0.5.52 (2013-04-07 18:35 by itozyun #68173)

・Editor と Comic Reader が新バルーンに対応。
・スクリプト読み込み直後に バルーンテンプレートを取得するようにする。
・素材画像のエクスプローラで詳細情報のデータが大きすぎるためサムネイルが見えなくなっていた問題の修正。
Enjoy!
Reply to #67954

0.5.54 (2013-05-07 18:26 by itozyun #68640)

ベクター非対応ですが circle テンプレートの尻尾の操作 POST、Reader での表示までで動作しました。

次はまず、コマの編集から保存ができるようにします。
Reply to #68173

0.5.55 (2013-05-07 22:17 by itozyun #68647)

コマの編集フォームの js を正しく取るように修正。でも、コマの編集ができない、、、
Reply to #68640

0.5.56 (2013-05-08 07:03 by itozyun #68654)

svg のバルーンが復活しました。ie では動きません、しばらく動きません、、、
Circle というオブジェクトを追加しています。現在は peta-common.js 内に書いていますが、本来は動的に追加されます。
Reply to #68647

RE: 0.5.56 (2013-05-08 07:12 by yasushiito #68655)

[メッセージ#68654 へのフォロー]

> Circle というオブジェクトを追加しています。現在は peta-common.js 内に書いていますが、本来は動的に追加されます。

了解です。動的な追加方法に関する話は、いずれ相談しましょう

Reply to #68654

0.5.57 (2013-05-17 06:50 by itozyun #68777)

>> Circle というオブジェクトを追加しています。現在は peta-common.js 内に書いていますが、本来は動的に追加されます。

> 了解です。動的な追加方法に関する話は、いずれ相談しましょう

よろしくお願いします、もう少し先で大丈夫です。


・バルーンテンプレートの整形位置を Balloon.register 内で行うように修正。ベクターバルーンのときも POST 時に system_picture_id が必要なので、getPictureID() できるように修正。
Reply to #68655

version 0.5.4 (2012-08-04 22:03 by itozyun #64915)

コンボボックスのアップデート.アウトプットコンソールの コンボボックスの表示順が逆になっていた.コンボボックスの値の変化で 出力文字列を変更するように修正.
Reply to #61445

version 0.5.5 (2012-08-05 04:59 by itozyun #64922)

Cabinet( コミック書庫のエクスプローラ ), Gallery( 画像書庫のエクスプローラ ) に 閉じるボタンを追加しました.
これで 静的 HTML ⇔ Metroホーム ⇔ アプリケーション を移動し続けることができるようになります.Enjoy!
Reply to #61445

RE: クライアント関連 (2012-10-01 18:20 by yasushiito #65693)

非常に個人的な話で恐縮なのですが…

[ESC] キーを押すと Metro ホームに入るよ

って言われても、そこ、指が届かなくて押せないんですね。もう、それだけで開く気力が萎えちゃって…
キーボード無し環境も考慮してクリックでもokにできませんか?
Reply to #61445

RE: クライアント関連 (2012-10-02 08:19 by itozyun #65697)

了解です、ちょっと待っててください.
Aptana がうまく動かなくなって、アップデートしたり嵌ってました(><
Reply to #65693

RE: クライアント関連 (2012-10-02 09:16 by itozyun #65698)

ズザッとページに Home へ ボタンを追加しました.赤枠線のメッセージ部分をクリックしても Home に入ります.

その際に v04 に ブランチをマージしてしまいました(>< サーセン、、、
Reply to #65697

RE: クライアント関連 (2012-10-02 18:51 by yasushiito #65703)

あざっす
Reply to #65698

RE: クライアント関連 (2013-05-24 08:09 by yasushiito #68870)

http://www.yoheim.net/blog.php?q=20130103

JavaScriptはファイルの分割をすることが難しいと聞いていましたが、最近ではそれを補助するツールも揃ってきているみたいですね。スクリプトが小さいうちは同じファイルに入っていてもそれほど苦にはなりませんが、ある程度の規模になってくると、全体の見通しが悪くなって、全体の構造を見失ってしまいます。これがファイルに分かれていれば、 「どんなクラスがあって、どのクラスとどのクラスが関係を持っているのか」を一気に見通せるようになります。初めてソースコードを追いかける人にとっては重要な道しるべですね。いちど上記のソフトを試してみませんか?
Reply to #61445

RequireJS (2013-05-26 20:24 by itozyun #68897)

RequireJS は、ちょうど僕も見ていました。
PCにサーバを用意して、、、ということで苦手な部類ですが、全くこのようなツールが必要なタイミングです。
Reply to #68870

js ファイルを分割して開発 > 一本化 > 圧縮 (2014-10-11 19:17 by itozyun #74577)

現在の状況は、

次のような window でバッチファイルを実行してjsファイルを一本化 > closure compiler で圧縮しています。

js flash から離れるとずぶの素人のなので、たったコレだけのことにも苦労しました、、、

js のファイル名を数字から始める、というスタイルはあまり見かけませんが、Aptana IDE 上で名前順で表示されるので前後関係が分かりやすい、以下の .bat ファイルでも、 ファイル名順に処理してくれるので、特にファイルの前後関係を指定する必要がない、と大変お勧めです。欠点は、数字の付け替えと内容の変更が同時に発生した場合に、git 上ではファイルの削除・新規作成になってしまい履歴が追いづらくなります。ファイル名だけ変更して commit -> 内容を最新のものにして commit と、二段階にしています。
(最初のコミットのものではコードがエラーを吐くので、これもあまりよくないですが)

ファイル名 : ClosureCompiler.small.bat
設置場所 : index.html と同じ階層
備考 : C:\ClosureCompiler\ に compiler.jar を配置しています

@echo off
echo --------------------------------------------------------
echo pettanR 用 js ファイルを連結、ClosureCompiler に通します
echo C:\ClosureCompiler\ に compiler.jar を配置しています
echo --------------------------------------------------------

REM full.js というファイルを作る
type nul > ui.js

echo (function(window,document,navigator,location,screen,undefined){ >>ui.js

type js\01_core\*.js >>ui.js
type js\02_dom\*.js >>ui.js
type js\03_plugin\*.js >>ui.js
type js\04_util\*.js >>ui.js
type js\05_net\*.js >>ui.js
type js\06_audio\*.js >>ui.js

type js\20_ui\*.js >>ui.js

echo ;window['X']=X;X_TEMP.onRearchEndOfScript(); >>ui.js
echo })(window,document,navigator,location,screen); >>ui.js

REM コンパイルして full.min.js を作る
java -jar C:\ClosureCompiler\compiler.jar --js ui.js --js_output_file ui.min.js
REM --compilation_level WHITESPACE_ONLY --formatting pretty_print

PAUSE
Reply to #68897

Version 0.6.x (2014-02-16 11:51 by itozyun #71904)

こりゃいかん、ということでフレームワーク作りからはじめた 0.6 系について。
ぺったんアプリといえるものはまだ動いていません、、、
Reply to #61445

Version 0.6.18~ 文書操作の非同期化 (2014-02-16 12:21 by itozyun #71905)

この版で、X.Dom 以下にある jQuery 風な DOM API 抽象化レイヤーの DOM 更新処理が非同期になった。

つまり、className などの属性や style の変更、要素の追加・削除 などしたときに、実際の HTMLElement への反映は、setTimeout や requestAnimationFrame で一瞬置いた後にまとめて実施される。

ただし、要素のサイズや位置の取得関数が呼ばれた場合はその限りではなく、変更を適用し、そののちに要素の値を返す。( elm.offsetWidth や elm.offsetLeft など )

このような最適化の仕組みは、ブラウザや Adobe Flex の内部で行われている。
それをこのほど、jQuery 風ライブラリでやってみた。

https://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/7392bd7eff3b3f4877467fc0fcfe480206945fba


さて、その jQuery でサイトの前面にオーバーレイを表示するコードを以下に示す。

$('<div class="black-overlay"></div>').css( 'opacity', 0.5 ).appendTo( document.body );

div.black-overlay という空要素を新たに生成、その要素を 50% で半透過させています。document.body に追加しています。

opacity は IE8 以下では使えませんが、jQuery が filter 指定に置き換えてくれます、そのはずなのですが、、、

実はこのコード、IE8 以下で透過されません。IE では文書ツリーに追加される前に filter 指定が行われると、指定が無視されます。

意図したように動くコードは以下になります。

$('<div class="black-overlay"></div>').appendTo( document.body ).css( 'opacity', 0.5 );

先に文書ツリーに追加した後に、filter がセットされるようにします。

jQuery はクロスブラウザライブラリだといわれますが、クロスブラウザのためにはいろいろ注意が必要です。

一方で、非同期に要素を操作する X.Dom では、以上のような配慮は必要ありません。要素への変更はすべて変数に蓄えられて、一定時間後に、要素の生成 > 文書ツリーへの追加 > style や属性、イベントの適用 の順に一気に行われるからです。

クロスブラウザを謳うライブラリは数あれど、そのクロスブラウザの謂うところは、ライブラリ毎にまちまちで注意が必要なわけです。enjoy!
Reply to #71904

Version 0.6.26 (2014-03-03 21:50 by itozyun #72052)

偉そうに上の文章を書いている時点では、実は opacity -> filter 変換が動いていなかった(汗
いまでも、filter が必要な場合のロジックが甘いと思う、、、

ここまでで、例えば以下の H3-H6 タグを見つけて目次を作るコードがきちんと動くようになった。
jQuery や jQuery ライクな DOM 操作ライブラリは Web ページをちょっといじって便利にしたい、って場合にはご覧の通り大変便利。
でも、この調子で jQuery を使って Web アプリのフロントを書こう、は多分挫ける。Web ページと Web アプリは別の世界と思ったほうがいい。

最後に今回の更新で、ベースのフォントサイズが変更されたときに発火する X.Dom.Event.BASE_FONT_RESIZED をささっと実装しましたよ。Enjoy!

X.Dom.listenOnce( X.Dom.Event.XDOM_READY, function(){
var xnIndex = Node.create( 'ol', { 'class' : 'page-index' } ),
id = -1,
lastH = 3,
olList = [ xnIndex ],
lastOL = xnIndex,
lastLi;
X( 'h2' ).after( xnIndex );

X( 'h3,h4,h5,h6' ).each( function(){
var h = parseFloat( this._tag.slice( 1 ) );

if( h < lastH ){
lastOL = olList[ h - 3 ];
} else
if( lastH < h ){
lastOL = lastLi.create( 'ol' );
olList.push( lastOL );
};

this.before( '<a name="inner-link-' + ( ++id ) + '"></a>' );
lastLi = lastOL.create( '<li><a href="#inner-link-' + ( id ) + '">' + this.text() + '</a></li>' );
lastH = h;
} );
} );
Reply to #71905

X.Dom Dom 操作ライブラリを使ったアプリのデモ (2014-04-26 07:14 by itozyun #72806)

jQuery の変わりに仕事で使ってみたところ、this コンテキストの指示ができて jQuery より楽だった.

カレンダーUI pettanR DOM 操作ライブラリ使用
https://www.youtube.com/watch?v=WeuI9zPLiC0&feature=youtu.be

css3 アニメを使っているのでよく動いているけど、X.Dom 自体はアニメーションを持っていないのです.
Reply to #72052

X.UI について (2014-03-08 18:41 by itozyun #72085)

手元では動いているけど、サンプルのひとつすらあげていない X.UI について。

こいつは、X.Dom 上に作られる UI フレームワークで、Adobe Flex みたいなものです。

最大の特徴は、photoshop のような使い心地の Web アプリを作ることを目標にしていること。テキストが不用意に選択されないように一番手前に画面を覆う要素を置いて、ポインターイベントはすべてそいつがキャッチして、フレームワークが描画要素へのイベント伝播を行う。

以上をすでに実装している 0.5 までのパネルエディタの使い心地を見てもらえば、独自イベント伝播の実装が有効だと分かる。

0.5 までは jQuery + べた書きで実装していたのを、UI フレームワークにしてしまおうというのが 0.6 の X.UI になる。

フレームワーク化して、

・ブラウザの違いを吸収
・ポインターイベント(タッチ、マウス、ペン)を抽象化
・画面サイズによる分岐を記述しやすく
・フォントが小さい!といったときに、フォントサイズを拡大しても UI が破綻しない

といったことを目指します。

なんで X.UI のサンプルをあげないかというと、仕事で書きかけたものが混じっていて、、、

サンプルではなくて、こんな風だよ、というコードを示しますと、以下のように、Flex の画面記述言語 mxml を js に置き換えたような感じで記述できます.

{{{ code javascript
var popup = Popup(
VerticalLayoutManager,
Text( message ),
HBox(
Button( 'yas' ).listen( 'click', yesClickHandler ),
Button( 'no' ).listen( 'click', yesClickHandler )
)
).listen( 'close', closeHandler );
}}}
Reply to #61445

Re: X.UI について (2014-06-04 21:11 by itozyun #73299)

ここしばらく AngularJS とか Knockout.js とか見ていましたが、html に直接制御情報を書いていく、という素敵なアプローチは、一方で、全ての web ブラウザで同じ html タグ構造で意図した画面が作れる、という楽天的観測を前提にしているように思います.(実際、最近のブラウザは、Opera, NetFront が独自開発を止めたり、して IE, Webkit, Gecko に収斂していくので、ますます差異は出難いのですが.仕様が巨大化しているので、新規参入は極めて難しいでしょうし.)

一方の X.UI フレームワークはというと.将来、支離滅裂な Web ブラウザが登場してもアプリケーション固有コードには手を加える必要がないようにする、を目標にしています.まずは、html に触るのはフレームワーク内のコードだけ、という作りになっています.支離滅裂なブラウザが現れて、異なる html タグの組み合わせで X.UI 要素を表現する必要が出てきた場合にも、X.UI フレームワーク開発者が分岐を書けばいい、ということになります.

さて、今回のコミットで、X.UI の酷く簡単なサンプル(ただし3つの box を描画するだけ)を確認できるようになりました。

js/main.js に書いてある、以下のコードを解釈して画面を描画します.

これは、Flex の mxml 的な完成画面の分かりやすさを、 js の記法を使って再現できないか?というアプローチでもあったり.

Box モデルが独自で html のそれとは異なります.おいおいドキュメントやらを用意します.
enjoy!

PageRoot(
VBox({
width : '30%',
height : 10,
left : '10%',
top : 12,
bgColor : 0xcccccc
}),
VBox({
width : '50%',
height : 10,
left : '30%',
bottom : 12,
bgColor : 0x999999
}),
VBox(
{
width : '50%',
left : '49%',
top : 5,
bottom : 5,
bgColor : 0x666666,
borderColor : 0x111111,
borderWidth : [ 0.5, 1, 5 ],
borderStyle : 'solid dotted',
sizing : 'border'
},
Text( 'Hello,world' )
)
);

http://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/d4a9a51a78712817a3a4bbfd9a09e9ddccc9aaf0
Reply to #72085

Re: X.UI について (2015-05-22 16:03 by itozyun #76190)

Version 0.6.154
https://osdn.jp/projects/pettanr/scm/git/clientJs/commits/e179079404973a959d1806464b7b6881b5510f2a

今回のコミットでX.UIのレイアウトエンジンのバグを修正し、デモファイルもカッコイイものに差し替えました。以下がそのキャプチャです。

https://osdn.jp/projects/pettanr/images/#id4544

画面を作るためのコードは以下になります。js の構文で flex の mxml 風に画面を記述していく、という狙い通り描画結果とソースコードの対応が見て取りやすいです。

https://osdn.jp/projects/pettanr/scm/git/clientJs/blobs/master/0.6.x/js/main.js

X.UI フレームワーク上に記述されるソースコードは、あたかも js で書かれた仕様書、とでもいうような美しい開発を行うことが可能です。
Reply to #73299

X.Net と X.Util の追加 (2014-09-11 21:04 by itozyun #74363)

今回のコミットで、XHR と JSONP のラッパーをまとめた、X.Net を追加しました。
また、X.Util に追加した、隠し iframe 用の関数、 X.Util.NinjaIframe は JSONP 時にズルズルとメモリがなくなっていく問題の対策のために、X.Net.JSONP から利用されています。

このようなハック的なコードのために使ってしまいがちなクロージャですが、大規模開発のためにクロージャを徹底排除した、X.Callback + X.EventDispatcher によるコーディングは必見です。enjoy!

http://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/05d60a7e55a635b3948204a577d9dcf2961e344b

参考:iframe のページ遷移を利用したメモリの解放
https://sourceforge.jp/projects/pettanr/forums/27899/35158/74234/
Reply to #61445

MouseEvent, TouchEvent の PointerEvent への変換 (2014-09-30 22:33 by itozyun #74489)

ポインティングデバイスには、マウス、ペン(消しゴム)、タッチ と様々なものがあり、今後もキネクトなど増えていくことでしょう。これら様々なデバイスによるポインターイベントを一貫して扱うことのできる、MS 提案の PointerEvent が、 MouseEvent, TouchEvent に替わって主流になっていくと思われます。

pettanR ライブラリは、MouseEvent や TouchEvent をPointerEvent に変換するコードを追加しました。(すでに同様のライブラリとしては Hand.js があります)

これにより、ジェスチャーイベントを扱う X.UI.Gesture (Hammer.js がベース)や、慣性スクロール(試験実装済)などのコードから、MouseEvent や TouchEvent 用の分岐を外すことができます。

(ポインターイベントの抽象化は、X.UI フレームワークレイヤーで行おうと考えていましたが、X.Dom 抽象化レイヤーでやってしまって構わないことに気付いたのでした)

Enjoy!

https://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/ee1651f04c1539d15db006d6285a4ff77c546613
Reply to #61445

Audio 機能の追加 (2014-10-03 20:20 by itozyun #74518)

今回の commit で pettanR ライブラリに待望の Audio サポート(一部)が追加されました。pettanR にはあまり関係のない機能ですが、コンテンツ制作中にノリノリの BGM が聴けるとかネ♪、、、

この少し前から、期間きびしめ、機能複雑め、な job にも pettanR ライブラリの一部を導入させて貰っていて、Audio 周りを急遽コミットしたのでした。enjoy!

https://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/4b82d2a46f12aa76005075e3f7e53ec24c390ed4
Reply to #61445

job にも pettanR ライブラリの一部を導入してみて (2014-10-18 15:21 by itozyun #74624)

job に実績の無いオレオレライブラリを導入するのは躊躇もあったけど、this コンテキストを維持しやすいつくりのおかげで、複雑なフローも難なく実装できる。

案件はすでに実装を終えた Flash(Flex) 版の移植なのだけど、Flex のときより複雑な処理を盛り込めそう。3G回線やそれ以下の回線を想定し、コンテンツがダウンロードされる前から、すでにダウンロードできた分だけで、動作を開始するとか。

クロージャが多段化するコールバック地獄、と言われる状況が一切生まれない。どうしても不可避なクロージャとしてイベントターゲットのリスナに使用するものは、不要になるとライブラリ内部で回収されて再利用されるので、メモリリークを知らない。

js で複雑なアプリケーションを記述するのに、pettanR ライブラリはかなりいけてると思います。少なくとも、僕が使ってる分には。

ところで、普通に最新の Firefox と IE11 でチェックして開発していただけなのに、IE11 の IE10 モードから初めて、5モードでも動いてしまい、ほんわかできた (^-^

ちなみに、少し前に読んで、フフン ってなった記事に以下がありました。

■ JSフレームワークはもうこりごり
http://postd.cc/zero_framework_manifesto/

> イベントの伝達方法やサポートされるタグの種類等、ブラウザ間における基礎的な要素に関してでさえ仕様が合致していなかったのです。
> そのためフレームワークとは、欠点をカバーするだけではなく、ブラウザの動作仕様を規定する独自モデルを構築するものでした。

> ブラウザは自動的にアップデートされ、バージョンがあがるごとにより機能的になり、更なる標準化が進みます。

> 結局皆さんは、プログラムが思ったようにうまく動かず原因を解明しなければならない時には、フレームワークの全てのレイヤーからHTML+CSS+JSに至るまですっかり掘り下げていかなければならないのです。
Reply to #74518

Re: Audio 機能の追加 (2014-11-17 22:26 by itozyun #74857)

少し前の commit で、Audio 関連のコードを整理アップデートし、Audio スプライトを実現する基盤を整えました。Audio スプライトはスマホ用ブラウザの Audio 機能の制限を克服する手法でスマホ用ブラウザゲームなどで効果を発揮します。pettanR にはほぼ関係ないといえます。Enjoy!

https://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/4afbf1b687e035eaf2c6b8bbf14e3c443d843d4e
Reply to #74518

Re: Audio 機能の追加 (2015-01-15 19:41 by itozyun #75254)

HTMLAudio の挙動はモバイル含め各ブラウザでずっと見渡していくと結構個性的で、バグ的な挙動やモバイル制限をかなり苦労して調教して、機能を引き出すことができた。
この過程で WebAudio, Silverlight 等のイベント周りを HTMLAudio に寄せていこうと考えていたのもあきらめた、、、

必要、クロスバックエンドで足並みを揃えられる、を基準に整理・定義した。
Reply to #74857

X.Node.Anime の追加 (2014-10-23 21:19 by itozyun #74655)

コミットログには書き忘れましたが、今回のコミットで 10_XNodeAnime.js を追加しました。
xnode.animate( start, end, duration, easing ) として要素の x, y, 透明度 についてアニメーションが可能です。

http://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/7911fddcbb190b99ad11412d283776ddbf77b479

0.5 以前にもアニメーションを実装したことがあり、これは、数値で与えられるあらゆるプロパティをアニメーション可能でした。(但しbackgroundImage の position は、背景画像のサイズが不明だと難しくなったりと例外あり)

これに対して、x, y, opacity しかアニメーションできない、というのはあまりに簡素です。このような開発を行った動機は、以下の記事を参考にしたため、というのも理由のひとつです。

■ ハイパフォーマンス・アニメーション
http://www.html5rocks.com/ja/tutorials/speed/high-performance-animations/
> モダンブラウザは4つの項目を手軽にアニメーションすることができます。
> 位置(position)、大きさ(scale)、回転(rotation)、透明度(opacity)です。
> もし、それ以外のものをアニメーションするなら、それはご自分の頑張り次第ですが、
> 絹のようになめらかな60fpsの動画を実現できる可能性は少ないでしょう。

現在では Web サイトのアニメーション効果に GPU のサポートを利かせて、滑らかなアニメーションを実現することが出来るようになりました。

しかし、この GPU レイヤーには様々な弱点があり、GPU レイヤーの特性をよく抑えておく必要があります。さもないと GPU サポートのパワーを引き出す以前に様々な副作用に悩まされることになります。

このたびは、初代 iPod touch で iScroll ライブラリを走らせた場合に遭遇していた 連続スクロール時の(恐らく再 GPU 転送に伴う)ちらつきを抑えるために、GPU レイヤーの遅延解除を実装しました。さらに、新たに GPU アニメーションする要素に親子関係の アニメーション要素があった場合に、子の GPU の解除する機能、などをえいやっと付けてみました。

これにより、初代 iPod touch でもちらつきの無い慣性スクロールを実現することができました。ちなみに、iPod touch も第四世代になると、稚拙な実装を行ってもなかなか、ちらつきが発生することはなくなります。ですので、すぐに馬脚を現す初代機を使ってパフォーマンスを磨くのがよいです。
Reply to #61445

Re: X.Node.Anime の追加 (2015-01-16 22:22 by itozyun #75259)

Version 0.6.121
https://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/dc5a75639232882249108b4f708916e9690e42b3

今回の更新で iOS3.1(初代 iPod touch)と iOS4(iPod touch 2G)で遭遇していた(iOS5は持っていないので未確認、iOS6では遭遇せず)、たまに(10回に1回程度、2G の方が頻度は少なめ) GPU アニメが更新されないときがある問題を解決。css からアニメーション指定を外すタイミングを transitionend 直後から、もっと後にずらしたら解決したみたい。

デバッグでは、スペックの低い iOS3 がすぐに馬脚を現すため便利。
これで自信を持って、GPU を利かせながらヌルヌル動く UI を作っていける自信が持てた。

GPU の効いた慣性スクロールは、position:fixed の使えない mobile webkit で UI を作りこんでいくのに要となる技術。

縦スクロールだけのレスポンシブデザインとユーザーによる文字サイズの変更を両立する Web デザインにアプローチしつつ玉砕してきたけど、ついにスキルが揃った!

関連ポスト
UIデータバインドとGPUレイヤー
https://sourceforge.jp/projects/pettanr/forums/27899/31275/75222/
Reply to #74655

X.UI.ScrillBox の追加 (2015-04-16 22:38 by itozyun #75956)

http://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/eedd028ba64be2ea0828cf686f1d0ec3bb4010d5

今回の更新で、スクロール機能をUIフレームワークに組み込むことができました。UI関連の作りをコードを読んで理解し直すところから始めるという、大変な作業でした、、、

しかも画面更新周りにバグがあったのは、延々時間を奪われました、、、

スクロールは画面作りに際して、基礎になる部分です。大抵のシステムはスクロールを持ちますからね!ここを疎かにするとガタガタと諸々崩れてしまいますから、粘った甲斐のあった、というものです。

enjoy!
Reply to #75259

Re: X.UI.ScrillBox の追加 (2015-04-18 15:51 by itozyun #75961)

今回の更新で IE8- でも動作するようになりました。

https://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/d836e6243878426d4cfd7a14ceb9b77db9f92b57

ie では body {font-size:16px} などと明示しておかないと <div style=height:2em> が 32px にならず( しかし font-size を計測すると 16px ) 43px となってしまう問題がありました。

ie はじゃじゃ馬で調教のし甲斐があります。
Reply to #75956

無限スクロールについて (2015-07-01 09:44 by itozyun #76444)

Version 0.6.168, fix X.UI.Repeater.

https://osdn.jp/projects/pettanr/scm/git/clientJs/commits/7973f3ff61f1ef5bd9732f527b175010d0c0971b

今回の更新で Repeater から、スクロール位置から画面外になった要素を回収して再利用する仕組みを外しました。

これは、巨大なアイテム配列が与えられた場合に、その全てを HTML 要素にしてしまう、ということで、つまり、無限スクロールが不可能になりました。

無限スクロールを Repeater で行おうと考えましたが、アイデアに無理があったみたいで画面がガタガタしたため一旦あきらめました。

無限スクロールは、描画要素を画面に表示される分+αに限定し、描画要素を使いまわすテクニックです。(pettanR でも 0.5 のときに一度実装していたと思います)

すでに一般的なテクニックですが、これに GPU レイヤーを組み合わせようとすると、途端に難易度が上がります。

無限スクロールを GPU レイヤーを使いながら行う、のがこの数ヶ月ほどのテーマです。
仕切りなおして腰を据えて取り組んでいく、ということで、他にも進めなくちゃいけないものに取り組みます。

ファイラーの実装が始まったら、マストなんですけどね。
Reply to #75956

Opera モバイル12 対応メモ (2014-11-27 14:42 by itozyun #74932)

久しぶりに、Android の Opera で動作させたところ、動かなくなっていたので修正しました。
Opera Mobile 12.10 Android1.6 IS01

・ インスタンスのメンバーがいつの間にか消えている。
インスタンスにメソッドが無くエラーになっていました。try-chatch も働かず、ようやく問題個所にたどり着くと for in 文で列挙できたメンバーが意図したものの半分(60->30)でした。
X.Class の __proto__ を使った継承コードが原因で、OperMobile, Opera Tablet については、 Sub.prototype = new Super の方を走るようにしました。

・ js の構文解析のミスっぽいが、実行結果がおかしい。
ありえないタイミングで、not = true になっていた。この直前にアラートを入れたが、このアラートは表示されていない。while if break continue が組み合わさっていて、ややこしかったものを、クリーンアップすると症状が治まった。
http://sourceforge.jp/projects/pettanr/scm/git/clientJs/blobs/c50ad9ff1e8d6e9be2089ba554813564bd24a7c8/0.6.x/js/02_dom/08_XNodeSelector.js
Reply to #61445

<a>タグの下に<div>が現れるとエラーになっていた対策 (2014-12-18 22:12 by itozyun #75069)

カスペルスキーの Firefox アドオンが作るタグ構造に、<a><div></div></a>というものがありました。こいつは、HTML4的に不正な階層ですが、HTML5ではvalidです。
pettanR ライブラリのHTMLパーサーがHTML4用のため、ツリー構造を仮想DOMツリーに写し取るフェイズで<a></a><div></div>と書き直した上でリアルツリーと一致しないためエラーになっていました。
とりあえずエラーの出ないように、すでにあるツリーを読み込むフェイズでは、body.innerHTML で取得した構造を尊重するようにしました。
コレに際して調べてみましたが、HTML5に対応しない ie8 以下でも、寛容なつくりのためか、上記階層で要素を作ることが出来ました。
そういえば、<a>タグを使った不正なタグ構造を駆使してクロスブラウザするハックがありました。:hover が a:link にしか働かないie6以下の問題に手当てするアレとか。
この辺りの扱いをどうするか?悩ましいですね。あと実はまだ未確認です。

http://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/4f345667eeb8d229766fbcd5097d733b7c26ef41
Reply to #61445

UIデータバインドとGPUレイヤー (2015-01-12 19:26 by itozyun #75222)

リアルジョブで pettanR ライブラリをベースに backborne.js ライクなデータバインディングコードを書いた経験から。

昨今のWebアプリ開発では、GPUレイヤーのサポートを効かせたアニメーションが重要。アニメーションの際にGPUサポートを効かせなくてはいけない理由として。

・js で逐次にアニメーションするより遥かに滑らか。特に非力なモバイルで差が大きい。
・GPUに処理をふるので、CPU・メモリ・バッテリー資源を節約できるかも。

欠点としては、

・GPU 転送コストが掛かり、大きな HTML 要素を、低速な端末でアニメーションさせるとアニメ開始時に画面がちらつく。(連続でアニメが起こる可能性がある場合は、すぐに GPU レイヤーを解除しないで次のアニメーションに備えると軽減できる)
・開始値の設定 -> requestAnimationFrame を待って、目標値の設定 を行う必要がある。
・親子関係にある要素を GPU レイヤーに転送する場合に、子の GPU レイヤーの解除を行ってから親を GPU レイヤーに転送する。()必要があるかも)
・GPUレイヤーにある HTML 要素に対して変更を行うと、画面の更新が止まる。(但し css をいじったアニメーション解除は可能)

などの制約があり、アニメーションライブラリなどにカプセル化しようとすると、途端に嵌る、、、
特に、最後のGPU レイヤーに転送された HTML 要素を触れない については、UI データバインディングが自動で HTML 要素を書き換えてくれるタイミングと、アニメーションが被ってしまうと描画が止まりエラーも出たかも、、、

以上の問題は、ブラウザを問わず、MacOS と iOS でよく起こるようで、Windows 機でばかり開発していると、最後の最後で Mac でランダムに落ちる事態に遭遇、という痛い目に遭うことに、、、(あった、、、)

以上の問題を、各 UI データバインディングライブラリを使った開発でどう解決しているか?見ていきたいけど、情報が出てこない、、、
Reply to #61445

要素への更新を GPU レイヤーが解放されるまで待機する (2015-01-30 18:30 by itozyun #75349)

このたびの更新で、xnode.animate() 経由のアニメーションについて、要素が GPU レイヤーに飛んでいる場合、要素への更新を GPU レイヤーが解放されるまで待機する処理を追加しました。(但し要素が GPU に飛ぶ条件はブラウザ毎にまちまちで明示されていなく、経験に頼ったものです)

http://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/d46b3c051de91e296153c953c17d3ac5032ef1b7

この変更のおかげで、リアルジョブのアプリでは、アプリレイヤーのコードに一切手を加えることなく OSX でまともに動作するようになりました。

また、上記問題について思い出しつつもっとはっきり書くなら、

・ GPU レイヤーにある要素に対してコンテンツの追加や css の変更があると、transitionend イベントが起きなくなり、アニメーションの終了を検知できない。
・ 現象は、OSX の Safari と Firefox で遭遇した。Windows の Firefox と IE では遭遇しなかったように思う。

---------------------------------------------

ところで要素への更新ができないと、テキストのサイズを測る、といったことも難しくなってしまう。むきになるなら、GPU を切った透明なクローンのツリーを用意して測る、という手が思いつく。親だけ辿ったツリーがあれば良さそうだけど、最近の CSS は、兄弟セレクタとかパワフルなので、完全なツリーのクローンを用意しないといけないことにならないか、、、?

以上の方法もどうかと思うので、縛りを強くすることで、サイズ取得コストを上がりにくくした UI フレームワークを設計する、というのを少しづつ進めている。

すでにちょっとは動いているけど、 慣性スクロールに GPU 周りもクリアできたので、一挙に歩を進められそう。
Reply to #75222

セレクタの修正 (2015-04-10 12:24 by itozyun #75909)

SlickSpeed2 というテストフレームワークを使って pettanR のセレクタ周りをテストし、セレクタにあった誤りの一部を修正しました。

https://sourceforge.jp/projects/pettanr/scm/git/clientJs/commits/0231a4fe0d679b2959968193b0fbeebc44531aaf

また、このテストによって Virtual DOM にセレクタを独自に実装する場合、Real DOM に対するセレクタに比べてとても遅いことが判明しました。これは IE5 以上から使える getElementsByTagName 等が使えないため、Array と ハッシュからなるツリーを全て探索するからです。

Virtual DOM にとって、巨大な文書ツリーに対して探索を掛けるような( Web アプリケーション・スクリプトに対して ) Web ページ・スクリプト的使い方は明らかな誤用です。それでも、ピュア js オブジェクトに対する操作だから速いはず、と思い込んでいたため少なからずショックです。。。
Reply to #61445

pettanR フレームワーク API ドキュメント (2015-05-25 22:27 by itozyun #76222)

お待たせしました。あまりにもバッドパーツを外したりしていままで時間が掛かってしまいました。
http://pettanr.osdn.jp/jsdoc/
Reply to #61445

Re: pettanR フレームワーク API ドキュメント (2015-06-06 15:47 by yasushiito #76282)

反応遅くなりました。
とても汎用的なので、ぺったんR frameworkと呼ぶのは名前的に惜しいと思います。おそらくこの上のレイヤーにMVC的なフレームワークが乗ることになるのでしょう。さらにその上に、ぺったんのマニフェストに準拠するようなアプリケーションレイヤが乗っかっていきそうですね。これくらいの上位レイヤが、ぺったんR frameworkとなるんじゃなかろうか。
こちらは上位レイヤの方から実装している(だいぶノウハウが溜まってきた)ので、いずれはどこかで合流するでしょう。
Reply to #76222

Re: pettanR フレームワーク API ドキュメント (2015-06-06 20:12 by itozyun #76283)

ご笑覧、あざ~す。

Reply to #76282