Mozilla 1.7αリリース 36
ストーリー by Oliver
正式版での-enable-svgに期待 部門より
正式版での-enable-svgに期待 部門より
orangeobject 曰く、 "Mozilla.orgからMozilla 1.7αがリリースされた。新機能としては、ブラウザではポップアップブロックの機能向上、Chatzillaは0.9.59となった。また、1.6に比べてバイナリファイルサイズも2%減少し、ページのロードタイムは4%向上したという。"
orangeobject 曰く、 "Mozilla.orgからMozilla 1.7αがリリースされた。新機能としては、ブラウザではポップアップブロックの機能向上、Chatzillaは0.9.59となった。また、1.6に比べてバイナリファイルサイズも2%減少し、ページのロードタイムは4%向上したという。"
計算機科学者とは、壊れていないものを修理する人々のことである
部門名:正式版での-enable-svgに期待 部門より (スコア:3, 参考になる)
MathML [mozilla.gr.jp]は既に Mozilla Firefox でも有効なのですが。
実は、順番としてはIE/Safariよりも遅れている [oersted.co.jp] ようですです。その品質それぞれどのようなものか、ということはまた別の問題ですが。
ちなみに、今年は SVG Open 2004 [google.co.jp] なんてのも2004年9月7日~10日に東京の慶應義塾大学三田キャンパスにおいて開かれるようです [takesato.com] 。
SVGが Mozilla でいつ有効になるかは、Bug ID 122092 [mozilla.org]をウォッチしていればわかると思いますが、最後につけられた有効なコメント [mozilla.org]によると「まだ基本的なSVGの機能が一通り実装されていないため」ということらしいです。
- Ryuzi Kambe -
Re:部門名:正式版での-enable-svgに期待 部門より (スコア:2, 参考になる)
Bug 122092 comment 11 [mozilla.org]は当時HEADに入っていたソースとSVG_20020806_BRANCHのどちらを受けたものか分かりませんが、とりあえず現在のソースに入っているSVG実装を試用し、「基本的なSVGの機能が一通り実装されていない」のであれば、足りない部分を要望としてbugzillaに登録するとよいのではないでしょうか。
正式版で--enable-svgして欲しいという期待が入っている部門名はごもっとも。テストのためにも、そうして欲しい。
参考記事 (スコア:2, 参考になる)
# firefox 使いでいまのところ試すつもりないので AC
スムーズでない... (スコア:2, 興味深い)
G5/2Ghzくらいだと奇麗に動くんですかね?
ウインドウズ版はIEみたいにさらさらとスクロールするんですけどね…
Re:スムーズでない... (スコア:1, 参考になる)
Re:スムーズでない... (スコア:2, 興味深い)
それ入れても悲しいことにそんなにかわらんです。
(それもホイールをぐるんぐるん回さないとスクロールしなくなるような…)
つまり、もっとハードウエア寄りのところを直接叩く描画方法にしないと、
多分解決できない問題なんだと思います。
システム環境設定で、スムーズスクロール設定が有るんですが、
それを入れて、safariを起動すると、Win並とはいかずとも
safari上ではけっこうきれいにサラサラとスクロールします。
ゆーっくりとホイールまわすぶんには、スムーズなんですよ。Mozillaも。
さっと回すと、とたんに「がっくん」となるわけです。処理が追いつかず。
VRAMに先行描画したデータを蓄積させて、OpenGLとか使えば…とか
素人考えしたりするわけですが… OSXのためにそこまではやってくれなそうですな。
ああ、やっぱG5買えということか…
Re:スムーズでない... (スコア:1, 興味深い)
Re:スムーズでない... (スコア:0)
ゲームのために5万円のビデオカードかい?
WinnyのためにデュアルCPUかい?
Re:スムーズでない... (スコア:0)
広帯域とでかいHDD。
Re:スムーズでない... (スコア:0, すばらしい洞察)
> 素人考えしたりするわけですが… OSXのためにそこまではやってくれなそうですな。
うん。自分でやってみればいいんだよ。
文句だけ言っても、発展はないからね。
Re:スムーズでない...(オフトピ) (スコア:1, 参考になる)
僕はあるオープンソースプロジェクトにMLとかで参加しているけど、そこの人がいっていたのが「自分でやれ、やめよう」ということでした。で、それに甘えさせてもらって、要望やらバグ報告を流しているし、それにともなってマニュアルも書いたりしています。それも、そこの人達のおかげだと思っています。
ヒステリックなクレームは間違いだけど、「自分でやれ」で全てのクレームを圧迫しているほうが、よっぽど発展しないと思うよ。
落ち着いて読んで欲しいです。 (スコア:1, すばらしい洞察)
反対に「なんでも人頼み厨」って一言でまとめられちゃうよ。
それはイヤなんだよね? だってそういうバカげた話こそ
発展になにも寄与しないんだから。
「全て」なんて簡単にいっちゃうのもダメ。本当に全てを
そう扱っているのでなければ、それこそ訳判らないバカげた
話になっちゃうから。
そういう方向に話を持っていくのはやめようね。
で、まず自分の手をうごかせ、と言われるのは仕方ないよ。
Mozilla だけじゃなくて世の中の多くのフリーソフトやオープン
ソースのソフトウェアって、余暇を使って自分の楽しみで
ハックするにしては、あまりにユーザからの期待と要求が
広くて大きくて強いんだ。
開発集団や個々の開発者が(色々な意味で)興味を持っている
ポイントならば話の進み具合も楽だろうけど、そうでない
場合には「ちょっと自分で頑張ってくれないなぁ...」と
思うのはしばしばある事なんです。
もちろんコメントや要望をいただけるのはとてもありがたい
事です。 でも、実力成果主義の世界なので、コメントや
要望だけでなく「なにかチャレンジして成果があった」事が
示されていると、開発者に対するアピールは強いです。
その辺り、もしかすると同意できないかもしれませんが
ご理解ください。
Re:落ち着いて読んで欲しいです。 (スコア:1)
「制作上、力を貸せないユーザーに発言権はない」
ってことですか。そうですか。
もうなにもいいません
脆弱性を見つけても黙ってます。直し方わからんから。
Re:落ち着いて読んで欲しいです。 (スコア:1)
まぁ、実際フリーソフトウェアを自分で作れない人が
フリーソフトウェアを使い続けたいと思うなら、
金払うとか何とかして貢献すべきではありますが。
勝手にソフトの湧いてくる不思議な泉が有るんじゃないんだから。
#かく言う私は何もしてないけどID
gy0
Re:落ち着いて読んで欲しいです。 (スコア:2, 参考になる)
こういった「重さの解消」っていうのは、それ自体は障害ではない上に、解決が困難な問題ですから、どうしても後回しにされてしまう部分です。
GSoneさんは#502217で「ハードウエア寄りのところを直接叩く描画方法に」とおっしゃってますが、それを行ってしまったらAquaの存在意義が薄れてしまいます。
OSXの画面描画は、一旦バッファに描画されてからVRAMに転送されます。
(例えばこちらの説明 [cocolog-nifty.com])
直接VRAMに描画されるWindowsと比較すると、頻繁に画面が書き直されるアプリケーションでは明らかに不利になるわけですよ。
(Windowsのばやいでも、半透明ウィンドウ等では同様の処理が入りますけど)
OSXはその速度低下よりも、バッファリングすることによる利点を取ったわけですから、「同じMozillaでもWindows版の方が早い」というのは仕方のないことかと。
実際、もし画面直接描画方式をMozillaが取ったら(取れるのかどうか知りませんが(^^;))、例えばExposeの恩恵にあずかれなくなってしまうのでは?
(バッファリング方式でないと、あれは難しいでしょう)
「Mozillaがsafariより重い」ってのは、まさにそのとおり。
ただ、そう簡単に直るものではないというのは察してあげてください。
そもそも、Mozillaを選ぶ利点は決して「速さ」ではないんですから。昔から「重い重い」って言われつづけてますからね。
もう少し、長い目で見てあげましょうよ。
Re:落ち着いて読んで欲しいです。 (スコア:0)
Re:落ち着いて読んで欲しいです。 (スコア:0)
どうか、そのようにゼロか1かという風に極端に考えないで欲しいです。
開発に関わっている人達もそんなに多くないし、フルタイムでない人もいるので、どうしても優先順位というものが発生するんです。 更に言えば Mac OS X 版の開発者は極端に少ないのです。
人材と時間が豊富にあるのなら、すべての問題に対して一気に取り組むこともできるのでしょうが、そうでない以上は全てを平等に同時には処理できないのです。
その優先順位を上げると
ALT+漢字問題 (スコア:2, 参考になる)
解消されたらしいのが朗報。
和ジラ1.5では独自に対応していた [mozilla.gr.jp]のですが、和ジラ1.6が出なかったので
私としては待望でした。
#自力buildすれば問題無い話だと突っ込まれそうなのでAC
Re:ALT+漢字問題 (スコア:0)
# 切なる願い
Re:ALT+漢字問題 (スコア:0, オフトピック) (スコア:1)
普段は漢字キーだけでon/off させているのもあるけど、
alt キーとの組み合わせで、しかもキーを離すタイミングにまで影響を受けるなんて・・・
まるで裏技探しみたい。と思ったのは私だけ?
Re:ALT+漢字問題 (スコア:0, オフトピック) (スコア:0)
はっ、英語キーボードだからか
# ごめんなさい
Re:ALT+漢字問題 (スコア:0, オフトピック) (スコア:1)
#別のキーに割り当てれば良いのだろうけど。
キーを話すタイミングが良いだけではないですか?
#単に「うちは ALT+` 問題だ」という話ならごめんなさい。
Re:ALT+漢字問題 (スコア:1, 興味深い)
ATOK問題 (スコア:2, 参考になる)
ATOKユーザとしては結構難儀なのです。
(ATOK16+FireFox0.8/Thunderbird0.5でも再現)
1年以上status変わってないし、半ばあきらめ気味ですが。
firebirdベースになるのはいつから? (スコア:1)
あれ、ちがう?
変なこといってたらすいません。
Re:firebirdベースになるのはいつから? (スコア:2, 興味深い)
当分ないと思います。開発の遅れとMozilla Foundationの設立による方向転換があるからです。
去年の7月にAOLから離れてMozilla Foundationを設立したこと、またAOLがNetscapeの開発から手を引いてしまったことから、エンドユーザのサポートが必要になったので、Suiteの開発を継続せざるを得ないじょうきょうになったのでしょう、その時点でのFirebird/Thunderbirdはメインに持ってこれるほど完成されていなかったですし。
そんなわけで、今年の初めににしばらくSuiteをメインとして続ける [mozillazine.org]なんていう発表がされています。Firefoxのブランディング戦略も始まったばかりですし、当分開発体制のスイッチは行われないでしょうね。
Re:firebirdベースになるのはいつから? (スコア:1)
早くてもFirefox(旧称:(Mozilla) Firebird)とThunderbirdが共に1.0になるまでは
現状(Seamonkeyベース)のままだった気がします。
Re:firebirdベースになるのはいつから? (スコア:1)
ComposerとかMessengerとか。
そこら辺が一通り揃うまで、置き換えはないんじゃないかな?
それと、最近のリリースペースを見て感じること。
「実はFirefoxベースに置き換える気なんてないんじゃない?気が変わった?」
どう見てもFirefoxよりもSeamonkeyに注力してるように思える。
Re:firebirdベースになるのはいつから? (スコア:3, 参考になる)
例
・アイコンをソースコードから抜く程のブランディング強化
・両者のデフォルトテーマへの注力
・書き直されたダウンロードマネージャ
・見た目にわかりやすい設定画面と、項目の配置
・メール一覧の「返信済み」アイコン
これらはすべて、Seamonkey にはないものです。
スタンドアロン化については、Chatzilla [hacksrus.com] の最新版は Firefox にもインストール出来ます。また、Calender のスタンドアローン版である Mozilla Sunbird [mozilla.org](について触れているBlog [gemal.dk]) は、こんな感じ [mozilla.org]になるようです。
Daniel Glazman によって開発中の Nvu(エヌビュー)は、standalone HTML editor になるようです [easyconnect.fr](Mozilla Developers Meeting in Europe 4.0 での講演スライドより [dyndns.org])
- Ryuzi Kambe -
DOM Inspector と JavaScript Debugger は (スコア:0)
Re:firebirdベースになるのはいつから? (スコア:0)
Nvuの位置づけはComposerの派生物で、Composerは他に作るよってことなのでしょうか?
Re:firebirdベースになるのはいつから? (スコア:0)
一生なりません。
ブラウザがデータベースをベースにしてどうするのでしょうか?
# 完全な "荒し" なので AC
んで結局Firefoxとどっちが早いの? (スコア:0)
Re:んで結局Firefoxとどっちが早いの? (スコア:2, 参考になる)
現状でも、どっちが速いってこともないぞ。
ページ表示速度 同じ
メモリ使用量 ほぼ同じ
で、違いはUIにあって
Mozillaの方が若干富豪的
そこがショボイCPUだと如実に重いと感じる事があって
簡素なfirefox(firebird)の方が軽い(速い)とかいう話が流れた。
ただ、それが問題になる事はあまりない。
mozillaの窓をshadeして元に戻すというのを延々繰替えすでもしない限りは。
Re:んで結局Firefoxとどっちが早いの? (スコア:0)
を表示させながら Mozilla Mail でメールを受信しつつ
Composer を使ってみるとレスポンスが結構重かったりします。
プロセス自体が分離されている Firefox + Thunderbird + スタンド
アロンComposer だとちょ
Re:んで結局Firefoxとどっちが早いの? (スコア:0)