That Cocoa Thing

back to index 戻る

    2002.5.17
      マウスカーソルに影がつくの?
    2002.5.16
      WWDC に行ったわけではないので、Web で流れているものを読んだ以上のことは分かりません。思いっきり大雑把に要約すると、「9 と同じ、9 とは違う、9 にはなかったでしょ」というところでしょうか。「9 と同じ」は Spring-loaded folders 見たいなやつ。「9 とは違う」は Finder ウィンドウの意味付け。「9 にはなかったでしょ」は Rendezvous と Ink かな。
    2002.5.15
      Jaguar はどーなんでしょ。
    2002.5.2
      Cocoa か Carbon かという議論はおいといて、Apple は両者ともずっと継続してサポートしていくつもりなのだろうか?
    2002.5.1
      アプリケーション作成時にちょっとしたペイント機能、ドロー機能、アニメーション機能、画像処理などを付け加えたいとき、ちょっとした機能でいいのに、いざ作るとなると結構大変だったりする。コードを書かないプログラミングがいいと言うなら、そういう機能をちょこちょこっと作れる、昨日まで書いてきたようなクラスを提供してほしい。でも、Cocoa でやると Carbon もやらなきゃいけないのかな。
    2002.4.30
      NSSVGView。ここまでくると、Photoshop もどきや Illustrator もどきができてしまう。いや、もちろん、それがねらいだったりする。(^^;
    2002.4.29
      NSBasicShape は正三角形、正方形、星形、矢印などいくつかの作成済みパスを返してくれるようなクラス。NSShapePanel はその形状をユーザに選択させる際に使用するパネル。
    2002.4.28
      NSGraphView で円グラフ、折れ線グラフ、棒グラフなどなどが簡単に描画できれば便利です。
    2002.4.27
      NSEffect と NSEffectPanel。NSEffect は NSImage に画像エフェクトを適用する。ぼかし、シャープネスはもちろん、セピアカラーにしたり、モノクロにしたり、その他、回転、反転、ズーム、切り抜きなど色々。NSEffectPanel はその Effect をユーザに選択させる場合に使用するパネル。
    2002.4.26
      NSAlias。っていうか、Cocoa でエイリアスはどうなっているの?
    2002.4.25
      NSLayeredView。View を階層化できる View。階層ごとに、表示/非表示ができ、もちろん合成方法、透明度も指定できる。
    2002.4.24
      NSBezierPath にペンと言うかブラシというか、欲しいです。色と線幅と線種だけではちょっと... NSPen や NSBrush みたいな...
    2002.4.23
      NSIconControl と NSIconView。Finder でアイコンを扱うのと同じ操作性(マスク外のクリックは無視するなど)を持ったクラスが欲しい。
    2002.4.22
      角度、方向を指定するコントロール。NSAngle。
    2002.4.21
      もちろん、日付があれば時刻も必要。表示形式は文字列形式と時計形式。これは NSClock かな。
    2002.4.20
      日付を表示、設定するコントロールが欲しい。表示形式は、文字列形式とカレンダー形式の2種類で、文字列形式は、2002年4月20日のように文字列で表示、設定する方法を提供し、カレンダー形式はシステム環境設定に見られるようなひと月分のカレンダーを表示し、そこで日付を表示、選択する方式を提供する。NSCalendar とでも呼ぶのでしょうか。
    2002.4.19
      More Controls ! More Classes !
    2002.4.18
      Chasing Arrow はどこ?
    2002.4.17
      ソフトウェアにバージョンはつきものですが、Project Builder でバージョン番号を設定する場合、あちこちに記述する必要があります。これは面倒だし、間違いのもと。1か所に記入したバージョンを全てに反映させるような何らかの方法を提供してほしい。
    2002.4.16
      Project Builder ってビルド中、Command-ピリオドが効かないのはなぜ。っていうか、Command-ピリオドでビルドを中止してほしい。
    2002.4.15
      Pop-up Menu 付き Group Box も見苦しいからやめたんだね。
    2002.4.14
      Check Box 付き Group Box は見苦しいからやめたんだね。
    2002.4.13
      Window Header はなくなったんだね。
    2002.4.12
      Relevance はないの?
    2002.4.11
      Placard はないの?
    2002.4.10
      Cocoa に Disclosure Triangle はないの?
    2002.4.9
      NSTextField は文字列の末端までしか選択状態になりません。コントロールの末端までにして下さい。
    2002.4.8
      NSCalendarDate は 1900年2月29日を認めます。1700年も1800年も同様です。この結果、それ以前の日にちの曜日が正確ではありません。ほとんどの人は関係ないかもね。でも日付に関するような重要なクラスは、しっかりとインプリメントされていないといけないよね。Apple に Bug Report を出そうと考えましたが、英語でうざったかったので、やめました。日本語で受け付けてね > アップル > Apple
    2002.4.7
      だからといって、プロジェクトウィンドウをフロントに持ってくると、そのウィンドウの大きさが災いし、コードやドキュメントが見えなくなってしまいます。これはいただけません。Finder でファイルコピーするときに表示されるウィンドウのように独立した小さなウィンドウで表示すべきではないでしょうか。
    2002.4.6
      Project Builder はシングルウィンドウベースではありますが、ファイル毎に独立したウィンドウを開けます。しかし、ビルドを行っているときにプログレスバーがプロジェクトウィンドウ下のステータスバーに表示されるので、ビルド中にコードやドキュメントを眺めようとするとそれらのウィンドウに隠れて見えなくなってしまいます。
    2002.4.5
      Project Builder に限らず、TextEdit でもそうだけど、カーソル移動でスクロールの必要があるとき、スクロールせず、ジャンプするのは絶対にやめてほしい。
    2002.4.4
      CodeWarrior IDE の方が使いやすいと思うのは、たんに、今まで使い続けてきたから?それとも、まだ Project Builder の奥の深さを知らないから?ソフトウェアは奥が深いのも結構なんですが、懐が深い方が良いような気がします。
    2002.4.3
      いわゆる「i-アプリケーション」のようなソフトウェアはそれで良いと思うけど、Project Builder はシングルウィンドウでなければならないソフトウェアなんだろうか。
    2002.4.2
      どうもいまだに Project Builder に馴染めない。っていうか、シングルウィンドウが馴染めない。
    2002.4.1
      クラス、定数、関数などすべて NS〜というネーミングルールはやり過ぎでは?
    2002.3.31
      「このメッセージの使用例はこちら」というふうにメッセージごとにサンプルがあれば、いうことありません。現在の Cocoa のヘルプにはどちらかと言うと What の説明が多いので、もっと How の部分を増やしてもらいたいのですが、とりあえず、メッセージの毎のサンプルがあれば個人的には OK です。ある程度の経験を積んだプログラマには十分な情報源になるのではないでしょうか。もちろん、初心者の人にとっても貴重な情報源でしょう。新しい iMac がたくさん売れたら考えてね > Steve
    2002.3.30
      ヘルプからサンプルが辿れるようにしてくれればもっと嬉しいです。
    2002.3.29
      Cocoa のクラスごとにサンプルを書いてくれれば嬉しいです。
    2002.3.28
      で、Cocoa のコードは公開してくれないの? > Avie
    2002.3.27
      Cocoa はソースコードが公開されていないので、コードをハックしてフレームワークのお勉強ができません。仕方がないので、私は、GNUstep をダウンロードして調べています。もちろん、現在の Cocoa と同じであるという保証はないのですが、源流は同じ(?)ですので、方向性や以前からあるようなクラスやメソッドはさほど違っていないのではないかと考えております。まあ、お勉強目的ですので、違いはさほど気になりません。フレームワーク設計者(達)の考えと言うか、思いみたいなものの雰囲気が分かるだけでも良いかと思っています。
    2002.3.26
      サブクラスを作る場合、元になるクラスの内容が分からないと苦しいです。
    2002.3.25
      Metrowerks CodeWarrior に付属の PowerPlant はソースコードが公開されているので、何をしているのかを調べたり、新たにクラスを派生させるときなど非常に有益な情報を提供してくれます。このコードは、たくさんのことを教えてくれました。感謝 > Metrowerks
    2002.3.24
      ある程度ドキュメントに不備があっても、プログラミングサンプルがあれば、それを十分カバーしてくれる。コードには日本語、英語も関係ないし (^^;
    2002.3.23
      More Sample Code !
    2002.3.22
      Cocoa のサンプルが少なすぎる。それとも、サンプルが公開できない? 仕様を決めかねている? 作る気がない? やる気がない? NeXT 時代のパートナーを大事にしたいために(彼等は知っているだろう)、大手サードパーティーを大事にしたいために(彼等は聞くことができるだろう)、そうしている?
    2002.3.21
      ところで、Mac プログラムにとって重要なクリエータコード。日本の ADC から登録しようとするとうまくいかないのは私だけ? かなり前からそうだったような気がするのですが、もし直っていないのなら誰も使っていないって言うこと?
    2002.3.20
      アップルの ADC に行くと、あたかも開発者向け日本語サイトって感じになっていますよね。確かにいくつかの日本語情報はあるのですが、かなりの部分が本家 Apple の ADC にリンクされています。この切り分け、つまり日本語にする部分としない部分って、何を基準にそうしているのでしょうか? 確かにないよりはましかもしれませんが、日本語部分の存在意義が分からない。だって、その部分の情報だけでプログラムは作れないでしょ。いえいえ、決して「不要」と言っているわけではありません。
    2002.3.19
      既に市販されている翻訳ソフトをバンドルすることになるかもしれないが、そのままでは変な訳が生成されるだろうから、プログラミング用語、Mac 用語などでカスタマイズする必要があるのかもしれない。翻訳ソフトを作っているソフトハウスさん。さあ、アップルに営業に行きましょう (^^;
    2002.3.18
      翻訳ドキュメントがオリジナルドキュメントのアップデート時に同時にアップデートされないと、せっかく翻訳ドキュメントがあっても意味がないので、Developer Tools に翻訳ソフトをバンドルするのも1つの方法かも。
    2002.3.17
      Mac なプログラマは英語ができなければいけないのでしょうか。でなければ、日本で Mac プログラマはいらないのでしょうか。もともとマイノリティーな OS だから、Mac プログラマはそもそも絶滅危惧種?
    2002.3.16
      せっかく Cocoa で(ある程度)素早く、(ある程度)簡単にプログラミングできるのに、ドキュメントのところで時間がかかってしまう。
    2002.3.15
      ドキュメントをすべて翻訳しろとは言わないですが、「このクラスは〜するクラスで、こんなふうに使います」といった概要レベルの日本語訳ドキュメントがあればとっても嬉しい。
    2002.3.14
      「このメソッドなんだっけ?」の場合は探すところがすぐ見つかるので、必要な英文だけ読めばいいのですが、「これをするにはどうするの?」みたいな場合は、広範囲を探す必要があります。日本語なら斜め読みして必要な箇所を探せるのですが、英語ではそうはなかなかいきません。はじめから順に読むしかないのですが、そんなことをしていたら時間がいくらあっても足りません。
    2002.3.13
      私、英語のドキュメントがすらすらと読めないので、結構ストレス (>.<) がたまります。もちろん、コンピュータ用語、プログラミング用語が多いので、(読むことはないですが)英語の小説読むのとは違い、それなりに、なんとか、分かります。
    2002.3.12
      Apple のサイトを覗いても Cocoa に関する情報は決して完備されているとは言えないと思う。
    2002.3.11
      Cocoa というか Mac におけるプログラミングに関する日本語の情報は某OSと比べるとやはり少ないですね。アップルのサイトも (;_;) ってな感じ。
    2002.3.10
      標準画像はフォトグラフィックな画像だけでなくイラストレイティブなのも欲しいな。それと、Mac OS X のフォルダアイコンは好きではないので、これもいくつかのバリエーションが欲しいな。私はフォルダのアイコンを付け替えることで、重要なフォルダやよくアクセスするフォルダを識別しています。
    2002.3.9
      あまりにも統一された OS やアプリは 1984 ぽくって退屈かもしれない。やっぱり、ユーザの自由が一番だと思う。並べる自由。散らかす自由。変える自由。そのままにする自由。あるがままで、その状態を見守る自由。勝手にかえちゃイヤ! (;_;)
    2002.3.8
      いろいろな画像があって、ある程度混沌としている方がそれぞれの作者の人間味や個性があっていいのかもしれない。でも、標準画像はあったらいいと思う。だって、使う使わないは、こっちの勝手だもん。
    2002.3.7
      プロトタイプアプリのようなものでも、デモやプレゼンでは見た目がそれっぽい方がインパクトがあるでしょ。せっかく Cocoa でアプリが素早く作成できても、画像作成に時間がかかるのでは意味がないし、Aqua がどちらかと言うと主張する GUI デザインであるため、適当なボタン画像ではアプリが貧相に見えてしまう。 ということで、"Aqua Image Standard Suite" どうでしょか? > Apple
    2002.3.6
      GUI のレイアウト面から言えば、Interface Builder でボタンなどを配置する際に表れるライン。あれは結構いい仕事。
    2002.3.5
      GUI のデザイン面に関しては、モノクロからフルカラー+アルファ、アイコンも 32x32 から 128x128 となるにつれ敷き居は高くなっているよね。作るにしろ、デザインするにしろ。そう思いません?決してモノクロ、32x32 が簡単であると言う意味ではないけど。それはそれで大変だと思う。Apple は敷居が高くなった分、鴨居を下げてくれればいいのに...(意味不明 (^^;
    2002.3.4
      ツールバーのボタン画像やアイコンの作成にお金が出せる人や、デザインセンスのいいプログラマばかりではないと思う。確かに、パッケージソフトでもおいおいって言いたくなるのもあるけどね。
    2002.3.3
      標準画像っていうのは、ツールバーのボタンで使ったり、アイコンのベースになるような画像。どのアプリにでもありそうな出現頻度の高いコマンドの画像が用意されていれば非常に助かると思いません?新規、開く、削除、戻る、進むなど、そのまま利用できるものや、組み合わせて画像が作成できるようなパーツ画像など。アプリのユーザサイドに立ってみても同じ意味を持つボタンがそれぞれのアプリで共通なら認識しやすいのでは?もちろん、全てそれを使用しなければいけないというような縛りはナンセンスですけど。
    2002.3.2
      Mac OS X アプリの見た目が Aqua っぽくあるべきことを Apple が望むなら、フリーで使用できる標準画像みたいなものを Apple が提供しても良いのでは。> Apple
    2002.3.1
      Mac OS X プログラミングに関する、愚痴、愚問、疑問みたいなことを書いてみるつもり。


back to index 戻る

>>> e'daisy <<<
mail button edaisy@mars.dti.ne.jp

Copyright © 2002 e'daisy. All rights reserved.