Opera 8.02 を入れてみた 2005-08-31 (水) 20:29:52+09:00

日記
広告無し版の登録コードを1日間だけ提供するというニュースを、鯖缶さんの記事で運良くみれたので入れてみた。

当サイトはいちおう問題なく閲覧できるようだ。動作確認UAにアイコンを追加した。

ちょっと使ってみた感想:

ページを読み込んでから表示までにタイムラグがある。全体を表示できるように裏で書き込んでから表示しているようだ。ITなどのやり方(順番に表示していく)とは対照的。

当サイトにテストで設置してあるお絵かきBBSについてだが、書き込まれたアニメーションを表示させたあと、 FireFox は固まってしまう。この問題と同じであろう問題についての2年近く前のバグレポートを読んだことがあるが、 Sun の Java エンジン側の問題だろう、ということで放置になっていた。今もなおっていないのでそのままなのだろう。ところが、ためしに Opera 8.02 でやってみたら固まらずに正常動作する。同じく Sun の Java エンジンを使っているので、 Opera はこの問題を解決できているようだ。 FireFox ( Mozilla も同様 ) の方でも Java のせいにしていないで解決してほしいなぁ…メインで使っているのでこういうところはなおして欲しい。ちなみに IE でも当然ながら正常動作している。

音声で操作する機能がついている。標準で使えるのは英語だ。発音が悪いと反応しない。ネタ的機能か。中国語、ドイツ語、ロシア語など、他の言語にも対応しているかはまだ調べていない。ドイツ語とかロシア語で操作してみたい気もする。(笑)

ドラッグしてタブの位置をいれかえることができるのがうれしい。

バナーとか、サイトの絵が全身タイツのアメコミヒーローの全身タイツ&マントを着た男性の実写(笑)。ものすごくヲタクぽい。せっかく Opera という名前なのだから、歌劇のオペラ関連のなにかをシンボルにするとかしたらよいのになぁ…。(^-^;

とりあえずは、そんなとこか。
[コメントの受付は終了しています ]
1: 鯖缶 (08/31 20:42)
ども、今晩は。
Trackback有難う御座います。
registration codeを無事にGetできたみたいで何よりです。
閑話休題
お絵かきBBSでFirefoxが固まる件ですが、JREのVersionの所為じゃないでしょうか?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050831 Firefox/1.6a1 ID:2005083101 + JRE 1.5.0_02の組合わせで確認しましたが、アニメーション表示後も固まることなくリピートも出来ました。
以上、御参考までに。
2: 冬星 (08/31 22:12)
うーんバージョンですか。うちのは↓が今の版なんですが、やっぱり再現します。
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
JRE:バージョン 1.5.0 (ビルド 1.5.0_04-b05)←最新らしい。
---
再現方法は、「★アニメーション」を押すと2個目のfirefoxが立ち上がる。アニメーションが終わったら1度巻き戻しボタンを押してリピートしてそのfirefoxの窓を閉じる。それから、1つ目のfirefoxで「←(ページを戻る)」を押すと固まります。
3: 冬星 (08/31 22:15)
また、firefoxが終了したようにみえても、タスクマネージャを開くとfirefoxプロセスが残ったままになってます。気づかずに新しく起動しようとしたら見慣れない窓が開いて、気が付きます。
この記事のリンク元 | 1 | 1 |

討論上達術 2005-08-31 (水) 00:40:00+09:00

日記
自分は討論が下手だ。練習するたび思う。

マッキンゼー式の問題解決方法の本を薦められた。討論に参加するとき問題解決の視点が有効らしい。

あとは頭の回転数が上がってくれれば…。(^-^;

キーワード: 集団討論 問題解決


BlogWrite と mt_convert_breaks 2005-08-27 (土) 00:00:00+09:00

ソフトウェア

しばらく静かといいつつナニなんだが、一件やっておかないといけなかった修正をした。

metaWeblog.newPost, editPost で mt_convert_breaks が 1/convert_breaks だった場合に、改行コードを p タグの組み合わせに変換するようにした。

それで気づいたが BlogWrite で本文を入力し自動改行にチェックを入れてみたところ色々と不思議な動作をする。

  1. 本文を手入力して、新規投稿のときチェックを入れて送信→「投稿&公開」ボタンを押した瞬間にチェックが自動で外れ、 mt_convert_breaks == '0' で送られる。
  2. 本文をテキストエディタからペーストして新規投稿として送信→ mt_convert_breaks == '1' で送られるが、 <br /> が付加された本文のままで送信するので、結果的に br タグの上に更に p タグが付いてしまう。
  3. 編集して再投稿するときチェックを入れて送信→ mt_convert_breaks == '1' で送られるが、 <p></p> が付加された本文のままで送信するので、結果的に p タグが重ねがけされてしまう。

1.に関しては、かならず自動改行OFFでしか送られないようにブロックしているようだ。本文入力中に既に p タグが入力されているから自動改行する必要なしとの判断をしているのだと思う。

2.に関しては、テキストエディタから本文に貼り付けたとき、連続して何か書かれている行末には <br /> が自動挿入され、段落間は p タグが自動挿入される(賢い!)のだが、その状態で自動改行オンにして新規投稿すると、こちらはなぜか強制OFFしないでそのまま送ってしまうので、結果的に改行が二重に効いてしまい間延びした文書になってしまう。既に改行のための処理をしてあるのだから、1.と仕様を合わせて自動改行をOFFにすべきではないか?

3.に関しては、既に投稿済みの文書なので、改行の処理は済んでいると思われるのに、自動改行ONのままで送信するので確実に二重に改行処理がほどこされてしまう。

検証して思ったが BlogWrite のように WYSIWYG 処理の都合上、編集画面上改行されているところは改行用のタグが挿入されているツールの場合、1.から3.いずれの場合も、自動改行は強制的にOFFのはずだ。「自動改行=改行コードを改行に相当するタグに置き換える」処理の意味が成立しないからだ。

もし自動改行ONのモードをもたせるとしたら、手入力で改行した位置と、エディタなどから貼り付けたテキストの改行の位置を内部で保持しておき、送信時にそれらを改行コードとして送信する必要がある。ただそれだと、 html とかを貼り付けられた場合には、タグを解析してどこが改行や段落なのかを把握する必要が生じる。解析して改行を管理するか、常に自動改行OFFか、どちらかに統一が必要な気がする。

[コメントの受付は終了しています ]
この記事のリンク元 | 1 | 1 | 1 |

キーワード: BlogWrite mt_convert_breaks