うりゃ!Carbonアプリについて情報交換しませんか?
OSXからは、OS9アプリをエミュして使ってるでしょ?
OS8.1以降からは、OSXにインストールしたCarbonアプリをネイティブに
使えるよね?
Ahyazilla CarbonやGraphicConverter Carbon,etc...のように。
(参考:
http://pc.2ch.net/test/read.cgi/jobs/1012738145/86)
で、OSXとClassicの両刀ユーザにとっては、両方で動作する
Carbonアプリ一つあれば十分だ。(OSXネイティブCabonは使えない)
さあ、これは使えるCarbonアプリ、バグやエラーの対処法、あったら
告白しろ。
2かな?
7 :
隠せば見たい人の性:02/03/14 23:26
かぼーん
MSって・・・
Windows Media Player for Macをダウンロードしたが、4.5MB。
解凍してできたインストーラが、3.3MB。もう阿呆かとバカかと。
OSXバージョンはかなりましになったんだから、OS9のCorbon Libでも動作するように作れよ。
天下のMSだろう〜
OSXユーザが各々コンパイルしろってか。セルフはやってるし。
>>9セルフはやってるし。?
WMPで一番悲しいのは、推奨メモリがQTPlayerの約4倍も必要なこと。それでもコマ切れ音切れするしょぼさか。
ポストRealPlayerを狙ってるように見える。
音楽だけならiTune最強。Win版はよ出せ。
OSX版WMPはOS9で動かなかったか・・・
バージョン8はまだか?7は使いもんならん。メモリ倍あてがってもすぐいっぱいまで喰う。
.wmaファイル開けるのって他に何あるの?
ハァハァファイルがイパーイあって困ってる。
>>10 確かにバックグラウンドになってもボタンなどのインターフェイスも何も変わらないので、あれっ?て思う。
IEのようにマックっぽくならないのは、開発チームが違うからのようだね。
wmaファイルを変換するのに何を使ってますか?
????
Carbonって、過渡期のためのアーキテクチャなの?
貴重な開発資源を過渡期のために割り当てる事は後ろ向きだと思うなあ。
>>14 古典アプリの移植が簡単、というのが売りだったはずなんです。
でも、CarbonLibのバグが多かったりなんだりして、結局その
絵に描いた餅は食えなかった、ということのようです。
当初の予定はどうだったのか知らないけど、
今はMac OS XのAPIのひとつってことになってると思う。
実際、Carbonになってからいろいろ拡張されてってるし、
CocoaにはObjective-CでCarbonをラッピングしたのもある。
Cocoa == .NET
Carbon == Windows APIの一部
ぐらいに考えたほうが近いかもしれない。
# .NETについてはよくわかってないんで間違ってるかも。
つーか、もともとCarbonなものをわざわざ別の方法で実装
し直すほうが開発資源の無駄遣いだと思うなぁ。
でも結局、将来的にCarbonがCocoaに統合しなければいけなくて、
いつかは開発の主力をCocoaに移さなければいけないなら、
結局延命措置に過ぎないんでないの?
まあ、一刻も早くアプリを移行させなければならないから、
賢明な判断といえばそうなのかも知れないけどさ。
# それにしてはOSX対応遅すぎだと思うけどね。。。
>>17 ごめん、よく知らないで書いたオレが悪いんだけど、.NETって
> 将来的にCarbonがCocoaに統合しなければいけなくて、
> いつかは開発の主力をCocoaに移さなければいけないなら、
こういうものなの?
Mac OS Xに関していえばCarbonがCocoaに統合されることも、
開発の主力をCocoaに移すこともないよ。
CarbonだろうがJavaだろうがlibcだろうが好きなの使えばいい。
わざわざ選択肢を減らす必要ないでしょ。
>>18 MSのやる事だから、現行のVS6は淘汰されていくのは自明。
CarbonとCocoaのあくまで感覚的な違いって、
VSで言うところのVBとVC++の関係に近いんだろうか?
重要な部分には、よりきめ細かい措置を用いるという意味で。
しっかし、選択肢が多いってのも面倒なもんだなあ。。。.
20 :
名無しさん@Emacs:02/04/02 18:52
Carbonが低レベルなAPIで
Cocoaがちょっと高級なクラスライブラリってとこかな。
比較するならCarbon+PowerPlant or MacAppでしたほうがいいかも。
選択肢は多ければ多いほどいいと思うけどなぁ。
Delphiとかの存在は邪魔?
QtやgtkをMac OS Xに移植しようって動きがあるのはなぜ?
# ちなみに、QtはCarbonベースだったと思う。
面倒だと思う理由を教えてほしい。
>>20 > 面倒だと思う理由を教えてほしい。
移植の仕事を手がけると、愚痴りたくなるよw
個人的には、VBとVCが同じライブラリで動くようになった、という、
VS.NETの試みは高く評価している(と言いつつ導入してないんだけど
あっちの言語やっててもこっちの言語やってても通じる、
プログラマの共通語みたいな物が欲しいなぁと常々思うよ。
「Cで言うこれこれみたいなやつ」とかじゃなくてさ。
# もっとデザインパターンでも勉強してくるか。。。
>>21 移植の手間を省くためのCarbonには批判的なのに、
移植がどうとか愚痴るのがわからないなぁ。
無理矢理Cocoaに一本化されるほうが愚痴りたくなるよ。
それに、最初から移植性を考えてたらあまり問題ないだろうし、
そのときに選択肢のあることはマイナスにはならないと思うけど。
そういう点からもGNUstepには期待してるんだけど…。
そういや、当初の予定だとCarbonがなくてCocoaだけで、
Cocoa for Windowsもあったんだよねぇ。
>>22 いや、Carbonが「やっつけ仕事」に見えて仕方ないだけ。
恒久的にサポートしてくれて、
移植したソフトの拡張まで問題なく出来るってーなら、それでいいです。
CarbonアプリをCocoaに移植するって事は普通はありえない事なのね?
漏れは移植すべき資源も無いから、Carbonは興味ないです。
24 :
名無しさん@Emacs:02/04/03 00:55
>>23 これからも使うためにちゃんと拡張されてるし、バグも潰していってる。
現状ではまだまだバグがあるけど…。
当然これからもサポートされるでしょう。
# あのMac OS X Programming GuidelinesですらCarbon使うなとは書いてないし。
Cocoaに移植といえば、つい最近公開されたPixelCatが
今までのコードを捨ててCocoaだけで書いてたみたいなんで、
ありえないことはないけど、その必要はない。
でも、Mac OS Xの新しい機能を使おうと思ったら、
今までのコードに追加とかが必要なんで、
特に何も考えずに使えるCocoaのほうが楽かも。
実際、面倒だからか単に実装してないだけなのに、
Carbonじゃできないと思われてるのがあったりする。
CoreGraphics(Quartz)の利用やServices使用とか。
そういうこともあってか、ユーザ側にはCocoa > Carbonな意識があるみたいで、
そういう層にアピールするためのCocoa移植はあるかも。
エルゴソフトはそうなのかな。
あと、バグに嫌気さしてとか。
ってダメじゃん。
>>24 漏れはOSXで開発やってないんで「ユーザ側」です。w
Carbon、個人的には結構印象悪いよ。
Cocoaにさほど劣らないと言うならそうして欲しいもんだ。
「マカー用。」も、Carbon版が出てたけど、明らかに挙動変だしな。
やっぱりもうちょっと待ち、みたいなイメージが強いよ。OSXには。
10.1.5出たのでもう一度語って下さい。
Carbonアプリでも文字が綺麗になるんだっけ?
現在深度532を航行中
異常なし
某スレ読んでたら、
高校時代の友人の悩んでた顔思い出して、
無性に悲しくなったよ。
31 :
国境警備隊員:02/06/26 19:34
現在深度534を航行中
鮒発見
異常あり
急浮上します
ありゃ?