Firefox 5 の新機能が明らかに 56
ストーリー by reo
差別化はかくも難しい 部門より
差別化はかくも難しい 部門より
10 日ほど前に Firefox 4 がリリースされたばかりだが、Firefox 5 がすでに Mozilla プロジェクトによって準備されつつある (ConceivablyTech の記事、本家 /. 記事より) 。
Firefox 5 で導入される新機能としては 9 つほど挙げられているが、タブの複数選択や PDF ビューア 機能などは Chrome の機能をパク…もとい参考にしているようだ。Firefox 独自の新機能としてはタブからメニューが表示される tab web apps 機能、Facebook や Twitter との連携を強めた identity manager などがあるという。でも後者は RockMelt のアイディアっぽいんですが。
よそから取り入れた機能 (スコア:2)
Taskbar web appsもIE9のピン止めしたときのジャンプリストですな。
http://blogs.msdn.com/b/ttanaka/archive/2011/02/16/internet-explorer-9... [msdn.com]
Fx5のスクリーンショットのFacebookのタブのメニューがIE9でFacebokをピン止めしたときと同じなのは、
Fx5もMETAタグのmsapplication-taskのプロパティを参照してるんでしょうか。
ソースのパクリは許さないけど (スコア:1, おもしろおかしい)
Re:ソースのパクリは許さないけど (スコア:2, すばらしい洞察)
> ソースのパクリは許さないけど
いやいや。ソースだって、パクり推奨ですよ。
1を聞いて0を知れ!
Re:ソースのパクリは許さないけど (スコア:2)
特許や著作権など、法で守られない範囲のアイデアはコピー自由なのが社会常識だと思うけど。倫理的にはいろいろあるだろうが。
むかしのWindowsは「Macの劣化コピー」などと揶揄されたけど、それをいいだせばLisaやMacはXEROXから数々のアイデアを得て、人材を引き抜いて開発されていた。
Unixから階層ディレクトリやリダイレクトなどのアイデアを導入した商用システムは枚挙に暇がないが、そのアイデアが特許などになっていないければ、それは自由。
それが許されないなら、産業や文化の向上は極端に困難になるだろうね。
そういえば、昨年のノーベル化学賞を受賞した根岸・鈴木の両氏は、クロスカップリング技術は特許を取得していないから自由に使ってくれと度々、発言していた。
Re:ソースのパクリは許さないけど (スコア:3, おもしろおかしい)
> クロスカップリング技術は特許を取得していないから自由に使ってくれと度々、発言していた。
BL業界大喜び。
Re: (スコア:0)
Firefox X PDFとか、かなり難しい気が。
Re:ソースのパクリは許さないけど (スコア:3, 興味深い)
> Firefox X PDFとか、かなり難しい気が。
当然ですね。
受けと攻めが逆ですから。
Re:ソースのパクリは許さないけど (スコア:2, 興味深い)
そりゃそうですよ。
だってPDFのプラグインがFirefoxを不安定にさせるわけですから、
PDF×Firefox
でないと。
Re: (スコア:0)
「（プラグインを）挿れちゃらめぇぇぇ」ですか
Re: (スコア:0)
ブラウザ総受けなんですね。
Re:ソースのパクリは許さないけど (スコア:1)
せっかくだから codec もパクッてほしい。
video タグが有効に機能しだしたら flash プラグインは不要になるだろう。
Re: (スコア:0)
ビルゲイツ曰く、今日使われているアイデアを考案した人々が、特許はどう与えられるかを理解していて、もし特許を取得していたとしたら、今頃この産業は完全に行き詰まっていたに違いない。
Re:ソースのパクリは許さないけど (スコア:2, すばらしい洞察)
アイデアのパクリは、フリー(GPL)な実装がなければ独自に実装しちゃいましょうという文化では？
許さないってのはどこだろう？たぶんライセンス条文の決まりを守らないことだろうけど
Re:ソースのパクリは許さないけど (スコア:1)
難しいところでありますが。
Re: (スコア:0)
古き時代のMACOSとWindowsとかね
Re: (スコア:0)
デスクトップもスマートフォンみたいな新境地も。
Re: (スコア:0)
スラドの人間は素直になれないんだな
Re: (スコア:0)
RockMeltの発表は2010年11月8日 [atmarkit.co.jp]
あれ?
Re: (スコア:0)
ソーシャルブラウザならRockMelt以前にもFlockがありましたけどね。あっちはWebKitベースに代わっちゃったけど。
多機能は高性能ではないのだが (スコア:0)
Firefox自体がPDF表示機能を持つなんて愚の骨頂。
将来的にODFも読めるようになるんでしょうね。
その先にはメールの送受信、スケジューラもアドレス帳も・・・
だんだん増えていくと思われます。
Re:多機能は高性能ではないのだが (スコア:3, すばらしい洞察)
Re:多機能は高性能ではないのだが (スコア:2)
高性能よりも多機能の方が一般的には喜ばれるのでは？
ソフトウェアの性能はハードウェアでいくらかカバーできますし。
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re:多機能は高性能ではないのだが (スコア:1)
Firefox 4をNetbookで走らせると、すげー重たかったりするんですよね。3.6に比べても。（具合から言ってUIがネック）
ハード性能は右肩上がりで、今、多少重たいソフト処理など...ってのは事実です。しかしウェブブラウザってそれで済まされるソフトなのかな? と思います。
Re:多機能は高性能ではないのだが (スコア:5, 参考になる)
環境の問題かも。
Re: (スコア:0)
素でも十分重いしアドオンに責任転嫁すんなよと言いたいが。
Re:多機能は高性能ではないのだが (スコア:1)
と思うのです。
Windows 7/VAIO Xの上で試しています。3.6からのアップグレードなので、そこに何かあるかも知れませんが。
普通のPC（Core 2 Duo世代）では全く問題ありません。
Re:多機能は高性能ではないのだが (スコア:1, 参考になる)
Re: (スコア:0)
VAIO typeP店頭モデル＋Kubuntuでも同時期のChromeと較べても遜色ありませんねぇ。
AdBlock以外拡張してないからかもしれませんが。
Re:多機能は高性能ではないのだが (スコア:1, 興味深い)
まあ今じゃHTMLの表示自体が大きくリソースを食う処理になった感があるけどね。メモリ管理一つとってもC++とDOMツリーとJava Scriptが絡んで（Mozillaの場合は更にXPCOMもある）ややこしいし。
Re:多機能は高性能ではないのだが (スコア:1)
少なくともOperaと比べて大きく差が出るところを見るに、「Mozillaの場合は」がバカにならないんでしょうね。
...今に始まったことでもないんでしょうが。
Re: (スコア:0)
> 多機能
そうするとセキュリティホールが増えるという経験則が……。
Re: (スコア:0)
「多機能」は結構微妙なところもある気がします。
ユーザーが欲しいものは、そのユーザーが必要とする機能のみであって、
そのユーザーが必要としない機能は、搭載されていない方がより望ましい状態なのではないかと。
OfficeもWindowsも、バージョンアップしたくないって人は大勢いますし。
自分が最初にFirefoxに惹かれたのは、このブラウザがその欲求を満たすブラウザだったからで。
インストール直後のFirefoxは非常に無機能な、数分で全貌が見通せるシンプルなものでした。
「欲しい機能だけインストールする」という思想は、なにか環境を清潔なまま保っておけるような
快感があったのではないかと。
最初から非常に多機能そうに見えたOperaは、結局自分には馴染まなくて。使おうとした事は何度もあるんですが。
Re: (スコア:0)
> 高性能よりも多機能の方が一般的には喜ばれるのでは？
多機能を求めるならば、アドオンに任せればいい。
本体は身軽に。じゃないですかね?
> ソフトウェアの性能はハードウェアでいくらかカバーできますし。
Suiteが鈍重になったので身軽にするために、機能を分離したはず。
ハードウエアに依存した軽快な動作というのは、windowsをみれば愚かなことは明らか。
Re: (スコア:0)
「忍び寄る多機能主義」
Re: (スコア:0)
Re: (スコア:0)
Google Chromeが自前のPDFビューアーを実装したのはAdobe Readerの出来を信用していないというのもあるんだろうけど、実際に使ってみると可能な限りHTMLを見るときと同じような操作体系にしたいという意図も感じられるのね。異なる操作体系は極力排除した方が使いやすいし（もっとも、そういう意味で一番邪魔なのはFlash Playerだったりするがｗ）、ちゃんとメンテナンスができるのであれば作ってもいいのではないかな。少なくとも愚の骨頂とまでは思わないな。
たった3週間しかチェックイン可能期間がないのに (スコア:0)
PDFビューアーとか、「言ってみただけ」以外の何ものでもない気がするんだけど。ChromeのPDFビューアーはFoxitのOEMでソース公開されてないから参考にできないし、ゼロから作って3週間で完成するとかありえない。
あるいは例によってずるずる開発が長引いて、3ヵ月でリリースするはずが気が付いたら1年経ってました、みたいな。
Re:たった3週間しかチェックイン可能期間がないのに (スコア:4, 興味深い)
Geckoが使ってるグラフィックライブラリCairoは、もともとPDFの読み書きができるんだよ。だから、すでにFirefox 3.0(Mozilla 1.9)から隠し機能としてPDF出力が実装されている。そもそも、ブラウザはHTMLを印刷できるんだから、レンダリングエンジンがPSやPDFを出力できないほうがおかしい。
だから、Gecko側としてはDocShellまわりをきちんと整備すれば済む話で、他のソフトのソースを参考にするとかいう方向は見当違い。
LinuxのPDFビューアで最も普及しているのはEvinceだと思うけど、Evinceが使っているPDFライブラリのPopplerは描画にCairoを使っている。PopplerはGPL2だからMozillaが直接取り込むわけにはいかないけど、実際、Linuxのデスクトップユーザーの大多数はCairoが描いているPDFを見ているわけで、それがブラウザの枠に入るかどうかってだけの違いに過ぎない。
要は印刷のプレビュー画面だよ。
問題は、ユーザーがPDFを(ますます)平気でウェブ上に置くようになるっていう点に絞られる。Chromeがこの引き金を引いてしまった以上、Mozilla側が自主規制する意味がなくなってしまったんだろうな。
Re:たった3週間しかチェックイン可能期間がないのに (スコア:1)
あれ、cairoってPDFの読み込みができましたっけ？
最近はいじってないので事情が変わっているのかもしれませんけど、3年ぐらい前に使ったときには書き出ししかサポートされていなかったような……。
（読み込みにはPoppler等のPDFレンダリングライブラリが別途必要だったはず）
Re: (スコア:0)
＞ブラウザはHTMLを印刷できるんだから、レンダリングエンジンがPSやPDFを出力できないほうがおかしい。
この理屈はおかしい。
PSやPDFに変換するのはあくまでもプリンタドライバの仕事だろ。
描画モデルにPDFを採用してるMacOSXに関しても、ブラウザはあくまでも画面に対して描画命令を
出してるだけであって、PDFに落とす(?)のはOSの仕事じゃないのか？
Re: (スコア:0)
＞この理屈はおかしい。
＞PSやPDFに変換するのはあくまでもプリンタドライバの仕事だろ。
いいや、むしろ君の理屈がおかしい。電気屋で売ってるものの大半はPostScript対応プリンタじゃないから、Windows用のプリンタドライバはそもそもPSやPDFへの変換を伴わない。UNIXの場合だと今は知らんけど昔は統一された印刷APIがなかったから、アプリ側でPSを出力して、非PSプリンタの場合はGhostScriptインタプリタを使って印刷する形をとっていた。
ていうか、
＞描画モデルにPDFを採用してるMacOSXに関しても、ブラウザはあくまでも画面に対して描画命令を
＞出してるだけであって、PDFに落とす(?)のはOSの仕事じゃないのか？
こっちではプリンタドライバじゃなくてOSって言ってるし、もう話が最初と食い違っているねｗ ちなみにCairoに関してはX11バックエンド以外にもPostScriotやPDFのバックエンドも持ってるから、画面描画と同じようにPSやPDF出力ができるんだよ。
Re: (スコア:0)
知識の偏りを感じますねぇ。
変換用の(ダミーのとはいいすぎか)プリンタドライバ経由でファイルに出力するという意味でしょ。
FAX送信用のプリンタドライバとかそういったモノもある(あった)わけで。
Re: (スコア:0)
あくまでもコンバータがプリンタドライバとして実装されているという例があるというだけで、プリンタドライバの仕事というのは言い過ぎでしょう。
そんなのないというか捨ててますよ。というかPSじゃなくてPDFですね。
まあ#1930452の「ブラウザはHTMLを印刷できるんだから、レンダリングエンジンがPSやPDFを出力できないほうがおかしい。」というのが一体どういう理屈で言っているのかよくわかりませんが、#1930775のツッコミも適切とは言い難いですね。どっちも正解じゃないということでよいのではないでしょうか？ｗ
Re: (スコア:0)
＞電気屋で売ってるものの大半はPostScript対応プリンタじゃないから
うんそうだね。だからアプリが直接PSを吐く必要もないんだよ。
アプリは描画命令や印刷命令を出すだけで、そこから先はOSやらドライバやらの仕事だから。
＞UNIXの場合だと今は知らんけど昔は統一された印刷APIがなかったから、アプリ側でPSを出力して、
うんそうだね。面倒臭かったね。Xの描画命令叩いて画面にグラフ出したり、CSVデータをグラフに
するためにPS吐くプログラム作ったことあるよ。出来たファイルをPSプリンタに流して印刷してたわ。
出来上がったPSファイル(テキスト)をただ流し込むだけでグラフが印刷できる
Re: (スコア:0)
なんか無駄に長くて要点がわかりにくい文章ですね。
Re: (スコア:0)
OSの印刷サービスを使ってるなら、アプリがPSやPDFを出力できる必要はないって言ってんだよ。
PSなどのプリンタの制御命令に変換するのは下請け(ドライバ)の仕事だって言ってんだよ。
どんだけ読解力ないんだ。
＞＞そもそも、ブラウザはHTMLを印刷できるんだから、レンダリングエンジンがPSやPDFを出力できないほうがおかしい。
上記の一文の理屈がおかしいって言ってるだけで、CairoとやらがPSやPDFを扱えるかどうかは知らんよ。
Re: (スコア:0)
知らないで講釈垂れてもなあ。
元コメントのこの部分なんだけど、ブラウザがcairoベースで作られているから理屈の上では画面描画と同じ結果をPDF（あるいはSVG）にも出力できる（Mac OS Xみたいにね）ってことが念頭にある発言だと思うのよね。こんなことも言っているし。
そこを無視すると木を見て森を見ずみたいな話になる。
Re: (スコア:0)
おそらくは実験的実装は既にやっているんだと思うよ。
ソース追いかけている人はわかっていると思うけど。
Re: (スコア:0)
>おそらくは実験的実装は既にやっているんだと思うよ。
>ソース追いかけている人はわかっていると思うけど。
2行とも憶測ですか？
Re: (スコア:0)
うん。ソース追いかけてないから。