約 949,184 件
https://w.atwiki.jp/javadsge/pages/8389.html
(1)表 (2)プログラム (3)グラフ 表検索 (4)出所 政府統計API (5)メモ (6)作業記録 8月11日データ構造追加 imageプラグインエラー 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。 imageプラグインエラー 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。 imageプラグインエラー 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。 -
https://w.atwiki.jp/aias-closurecompiler/pages/24.html
トップページ Closure Compiler Service API Closure Compiler Service API リファレンス このページでは、Closure Comiler Service APIのインターフェース仕様について詳細に説明します。APIの使用方法についてはこちらを参照してください。 コンパイルされたコードやAPIからの様々な情報を取得するためには、HTTP POSTリクエストを下記のURLに送る必要があります。 http //closure-compiler.appspot.com/compile リクエストボディは「必須リクエストパラメータ」に列挙されたパラメータを必ず含んでいなければなりません。また「省略可能なリクエストパラメータ」に列挙されたパラメータを含めることもできます。 もしサーバがリクエストの処理に失敗した場合には、サーバエラーメッセージが返却されます。それらのメッセージについては「サーバエラーメッセージ」で説明されています。 このページは公式サイトのこちらを元に作成しました。 目次 必須リクエストパラメータ js_code code_url compilation_level output_format output_info 省略可能なリクエストパラメータ js_externs externs_url exclude_default_externs output_file_name formatting use_closure_library warning_level サーバエラーメッセージ 必須リクエストパラメータ js_code コンパイルするJavaScriptコードをパラメータの値として直接指定します。リクエストにはこのパラメータかcode_urlパラメータを少なくとも1つ以上含んでいなければなりません。両方指定することも可能です。 js_code パラメータを複数指定することもできます。 code_url コンパイルするJavaScriptコードを内容にもつファイルのURLを指定します。リクエストにはこのパラメータかjs_codeパラメータを少なくとも1つ以上含んでいなければなりません。両方指定することも可能です。複数の入力ファイルを指定するため、リクエストには複数の code_url パラメータを含めることができます。 ファイルのURLはWEBからアクセス可能な場所でなければならない点に注意してください。 code_url パラメータの使用方法については、こちらでも詳しく説明しています。 compilation_level JavaScriptに適用する圧縮と最適化の度合い（コンパイルレベル）を指定します。以下の３つのレベルがあります： WHITESPACE_ONLY JavaScriptから空白・改行とコメントだけを削除します。 SIMPLE_OPTIMIZATIONS 圧縮と最適化を実行しますが、ローカル変数のみをリネームし、コンパイルされたコードとそれ以外のコードとの連携を妨げません。 ADVANCED_OPTIMIZATIONS グローバル領域を含むシンボルのリネームを行い、最高レベルの圧縮度を実現します。 ADVANCED_OPTIMIZATIONS レベルを使用する場合、外部のシンボルとの参照関係を維持するために追加の手順が必要となる可能性があります。詳しくはこちらを参照してください。 各コンパイルレベルで入力コードに求められるコーディングルールについては、こちらで詳しく説明されています。 output_format Closure Compilerサービスの出力フォーマットを指定します。指定可能なフォーマットは以下の３つです： xml 処理結果をXML形式で返却します。出力されるXMLは以下のような形式になります： compilationResult compiledCode var a="hello";alert(a); /compiledCode statistics originalSize 98 /originalSize compressedSize 35 /compressedSize compileTime 0 /compileTime /statistics /compilationResult compiledCode 要素の内容はClosure Compilerが生成した圧縮済みのJavaScriptコードです。この要素はoutput_infoパラメータの値に compiled_code が指定されたときのみ出力されます。同様に、 statistics 要素は output_info パラメータの値に statistics が指定されたときのみ出力されます。 output_info パラメータの値に warnings が指定されCompilerが警告を生成した場合、出力結果には warning 要素が含まれます： compilationResult ... warnings warning type="JSC_NO_SIDE_EFFECT" file="default.js" lineno="12" charno="3" line="delete 1;" warning 1 /warning warning type="JSC_UNUSED_VAR" file="default.js" lineno="13" charno="13" line="delete 1;" warning 2 /warning /warnings ... /compilationResult output_info パラメータの値に errors が指定され、入力コードが文法エラーやその他コンパイル処理を妨害するような問題を含んでいた場合、Closure Compilerは errors 要素を出力します。 errors 要素は以下のようなものです： compilationResult ... errors error type="JSC_NO_SIDE_EFFECT" file="default.js" lineno="12" charno="3" line="var x=- hello ;" error 1 /error error type="JSC_UNUSED_VAR" file="default.js" lineno="13" charno="13" line="var x=- hello " error 2 /error /errors ... /compilationResult error 要素と warning 要素の file 、 line 、 col 属性はClosure Compilerがそのエラーに遭遇した位置を示しています。 もしClosure Compilerが処理を停止させるようなエラーに見舞われた場合、以下のような出力結果が返却されます。このタイプのエラーは、JavaScriptコードの内容ではなくリクエストそのものに問題があることを示しています。詳しくはこちらを参照してください： compilationResult serverErrors error code="1" Over quota /error /serverErrors /compilationResult json 処理結果をJSON（JavaScript Object Notation）形式の文字列で返却します。この文字列をJavaScriptとして評価すると、1個のJavaScriptオブジェクトが得られます。出力されるJSONデータは以下のような形式です： { "compiledCode" /* raw code here */, "errors" [ {"charno" 4321, "error" "ERROR You failed.", "lineno" 1234, "file" "default.js", "type" "ERROR_TYPE", "line" "var x=- hello ;"} ], "warnings" [ {"charno" 4321, "lineno" 1234, "file" "default.js", "type" "ERROR_TYPE", "warning" "Warning You did something wrong!", "line" "delete 1;"} ], "serverErrors" [ {"code" 123,"error" "Over quota"} ], "statistics" { "originalSize" 10, "compressedSize" 3000, "compileTime" 10 } } JSON形式とXML形式はよく似ています：XMLの各タグはJSONオブジェクト内の同名のプロパティに相当します。 text text フォーマットを指定すると、タグやJSONブラケットを取り除いたシンプルなテキスト形式の出力結果が返却されます。 output_info Compilerから取得するデータの種類を指定します。指定できるのは以下の４種類です： compiled_code 入力されたJavaScriptコードを圧縮・最適化したものです。 warnings JavaScript内のバグの可能性を警告するメッセージです。 errors JavaScript内の文法エラーやその他のエラーを示すメッセージです。 statistics Closure Compilerが行った圧縮処理の達成度に関する情報です。出力形式がXMLの場合、以下のフォーマットの統計情報が返却されます： compilationResult ... statistics firstStatisticName 24 /firstStatisticName secondStatisticName 15 /secondStatisticName /statistics /compilationResult 省略可能なリクエストパラメータ js_externs js_externs パラメータはコンパイルされるコードが使用している外部プログラム内のシンボル名をリネームから保護するために使用します。このパラメータの値にはリネームされたくない関数やその他のシンボルを宣言するJavaScriptコードを指定します。このパラメータが効果をもつのはcompilation_levelパラメータの値が ADVANCED_OPTIMIZATIONS の場合のみです。詳しくは「extern宣言」を参照してください。 externs_url externs_url パラメータはコンパイルされるコードが使用している外部プログラム内のシンボル名をリネームから保護するために使用します。このパラメータにはリネームされたくない関数やその他のシンボルを宣言するJavaScriptコードが記述されたファイルのURLを指定します。ファイル内に宣言されたシンボルはjs_externsパラメータに直接列挙された場合と全く同じ方法で保護されます。このパラメータが効果をもつのはcompilation_levelパラメータの値が ADVANCED_OPTIMIZATIONS の場合のみです。詳しくは「extern宣言」を参照してください。 リクエスト内に複数の externs_url パラメータを定義できます。 exclude_default_externs Closure Compilerは document オブジェクトやそのメソッドのような標準的なシンボルを宣言した定義情報を持っており、デフォルトではそれを使用してシンボル名の保護を行います。もしこれらの標準的なextern宣言を使いたくない場合は、このパラメータにtrueを設定してリクエストに含めてください。デフォルトのextern宣言に関する詳細はこちらを参照してください。 output_file_name このパラメータを指定すると、Closure Compilerはコンパイルされたコードをサーバ上に1時間キャッシュし、特別なURLを通してそれを利用可能にします。ファイルがキャッシュされている間、このURLにアクセスしコンパイルされたコードをテストすることができます。URLは以下のような形式です： http //closure-compiler.appspot.com/code/bf067f356d510e1c7b81347eb84f65d2/[output_file_nameの値] formatting 出力されるコンパイル済みJavaScriptコードの整形方式を指定します。このパラメータは pretty_print または print_input_delimiter のどちらかの値をとりますが、同一のリクエスト内に２つの formatting パラメータを含めれば、これらを同時に指定することが可能です。 pretty_print と print_input_delimiter は整形方法のそれぞれ異なる側面に関する指示であるため、重複しても互いに影響しあうことがありません。 pretty_print リクエストが pretty_print を値にもつ formatting パラメータを含む場合、Closure Compilerは人間が読み易くなるよう出力コードに改行とインデントを付加します。以下にその例を示します： function hello(a) { alert("Hello, " + a) } hello("New user"); pretty_print がない場合は次のようになります。 function hello(a){alert("Hello, "+a)}hello("New user"); print_input_delimiter リクエストが print_input_delimiter を値にもつ formatting パラメータを含む場合、Closure Compilerは各入力ファイルの範囲を示す文字列を出力コード内に付加します。例えば2つのファイルを一緒にコンパイルした場合、出力は次のようになります。 // Input 0 alert("hi"); // Input 1 alert("bye"); ファイル間の境界を表す区切り文字としてClosure Compilerは「 // Input X 」を挿入します。これらの区切り文字はコメントであり、JavaScriptの動作を妨げない点に注意してください。 code_urlパラメータによって与えられた入力ファイルは、出力コード内で各ファイルに対応するセクションに区切られます。一方js_codeパラメータによって与えられた入力コードは、全ての js_code パラメータの値を結合したものが1つのセクションにまとめられます。入力ファイルの区切りには、例えば各ファイルのうちコードサイズの圧縮に最も貢献しているものの把握を助けるというような用途が考えられます。 use_closure_library use_closure_library パラメータを true に設定すると、compilerはソース内の goog.require() を探し出し、そのステートメントが要求しているClosure Libraryのコードを出力に追加します。また、Closure Libraryのコードのために特に設計された最適化を実行します。Closure Libraryに関する詳細はClosure Library documentationを参照してください。 goog.require() 関数に関する詳細はFinding Your Way around the Closure Libraryを参照してください。 use_closure_library パラメータのデフォルト値は false です。 warning_level コード内の問題になりそうな箇所に関する情報の出力量を指定します。 warning_level パラメータはoutput_infoパラメータの値に warning が一緒に指定されている場合のみ有効です。警告レベルには以下の３種類があります： QUIET 現在のコンパイルでのcompilation_levelに基づく最適化パスで生成された文法エラーと警告のみを出力します。 DEFAULT 最適化パスで生成された文法エラーと警告に加え、最終的に選択されたコードチェックパスで生成された警告を出力します。 warning_level パラメータのデフォルト値です。 VERBOSE 最適化パスで生成された文法エラーと警告に加え、実行された全てのコードチェックパスで生成された警告を出力します。 サーバエラーメッセージ サーバがリクエストの処理に失敗した場合、下表に示すサーバエラーメッセージのうちのいずれかが返却されます。これらのエラーはCompilerが生成するエラーや警告とは異なるものである点に注意してください。Compilerが生成するエラーや警告はJavaScript内で見つかった問題を表しますが、サーバエラーのメッセージはリクエストそのもののエラーによりCompilerがコードを全く処理出来ないことを示しています。 コードの内容が原因で発生するエラーと警告については、こちらを参照してください。 エラーコード メッセージ 意味 2 Unknown output mode. output_formatパラメータの値が xml 、 json 、 text 以外です。 4 Unknown compression level. compilation_levelパラメータの値が WHITESPACE_ONLY 、 SIMPLE_OPTIMIZATIONS 、 ADVANCED_OPTIMIZATIONS 以外です。 8 POST data too large. APIに送信されたデータのサイズが200,000バイトを超えています。Closure Compiler Service UIとAPIではサービスとの通信にHTTP-POSTリクエストを使用しますが、その際リクエストデータの合計が200,000バイトを超えてはなりません。APIでは、この制限はリクエストパラメータに設定された全てのテキストの合計サイズに適用されます。UIでは、この制限はソースコードと @code_url のようなコンパイルオプションを合わせたものに適用されます。もしリクエストが大きすぎた場合はソースコードをファイルに分離した上でそれをcode_urlパラメータで参照するようにするか、ローカルマシン上でClosure Compiler Applicationを使用してください。 9 File too large. コードの総量が1,024,000バイトを超えています。コードの総量とは、全てのcode_urlに指定されたファイル、全てのexterns_urlに指定されたファイル、全てのjs_codeとjs_externsに指定されたコードの合計を指します。 10 Cannot retrieve content from URL. このエラーはAPIがcode_urlパラメータで指定されたJavaScriptファイルまたはexterns_urlパラメータで指定されたexternファイルを取得できなかった場合に発生します。URLが正しいか、またファイルの参照を許可するように権限が設定されているかを確認してください。 12 URL is not formed properly. code_urlパラメータまたはexterns_urlパラメータに指定されたURLが不正な形式であることを表します。 13 No output information to produce, yet compilation was requested. output_infoパラメータが指定されていません。 14 Unknown output_info value output_infoパラメータの値が compiled_code 、 warnings 、 statistics 以外です。 16 Unknown warning level warning_levelパラメータの値が QUIET 、 DEFAULT 、 VERBOSE 以外です。 17 Unknown formatting option. formattingパラメータの値が pretty_print 、 print_input_delimiter 以外です。 18 Unknown parameter in HTTP request 定義されていないパラメータが含まれています。 19 Illegal value for output_file_name 出力ファイル名が1文字の数字、文字、ドット、アンダースコア、ダッシュだけからなっているか、または２つの連続したドット（..）を含んでいます。 22 Too many compiles performed recently. Try again later. このマシンから送信されているコンパイルリクエストが多すぎます。コンパイルの実行が可能になるには1時間必要です。 23 Compiler exception (with backtrace) Compilerがクラッシュしました。エラーテキストにはGoogleのデバッグ作業の助けになる情報が含まれています。 24 Unsupported input resource type リソースタイプが「http 」でなかったため、入力ファイルを取得できませんでした。
https://w.atwiki.jp/tohtawa/pages/16.html
helper GPoint と GLatLng の違い 引数？ div id="plugin_video" object param name="movie" value="http //www.youtube.com/v/kTV1CcS53JQ" /param param name="wmode" value="transparent" /param embed src="http //www.youtube.com/v/kTV1CcS53JQ" type="application/x-shockwave-flash" wmode="transparent" width="255" height="210" /embed /object /div
https://w.atwiki.jp/gametips/pages/18.html
更新日時 2013-06-15 23 05 49 (Sat)アクセス数 - glBindBuffer 目次 概要 エラー サンプルコード 参考文献 概要 void glBindBuffer(GLenum target, GLuint buffer); ハンドル buffer に関連付けられたバッファオブジェクトを target にバインドして利用できる状態にします。 あるバッファオブジェクトをバインドすると以前にバインドしていたバッファオブジェクトのバインドは自動的に解除されます。 第 1 引数では以下の定数を指定してバッファオブジェクトの種類を選択します。 定数 バッファオブジェクトの種類 GL_ARRAY_BUFFER 頂点バッファ GL_ELEMENT_ARRAY_BUFFER 頂点インデックス 第 2 引数 buffer には glGenBuffers で生成したバッファオブジェクトのハンドルを指定します。 ただし、0 を指定した場合には現在バインドされているバッファオブジェクトのバインドの解除だけを実行します。 エラー GL_INVALID_ENUM 第 1 引数 target が許可されている値でない場合に生成されます。 GL_INVALID_VALUE 第 2 引数 buffer が glGenBuffers で生成されたハンドルでないときに生成されます。 サンプルコード 以下に、バッファオブジェクトを生成して頂点属性を転送する C++ コードの例を示します。 ///**********************************************//** /// 頂点属性を頂点シェーダに渡します。 /// ここではシェーダのコンパイルとリンクは省略されています。 ///**********************************************//** // バッファオブジェクトへのハンドル GLuint position_buffer; GLuint color_buffer; // 頂点配列オブジェクトへのハンドル GLuint vao; // バッファオブジェクトの生成 void CreateBufferObject() { // 三角形ポリゴンの位置と色に対応する頂点属性の定義 float positions[] = { -0.5f, -0.5f, 0.0f, 0.5f, -0.5f, 0.0f, 0.5f, 0.5f, 0.0f }; float colors[] = { 1.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 1.0f }; // バッファオブジェクトの生成 GLuint vbo[2]; glGenBuffers(2, vbo); position_buffer = vbo[0]; color_buffer = vbo[1]; // 頂点位置をバッファオブジェクトに転送 glBindBuffer(GL_ARRAY_BUFFER, position_buffer); glBufferData(GL_ARRAY_BUFFER, sizeof(float) * 9, positions, GL_STATIC_DRAW); // 頂点色をバッファオブジェクトに転送 glBindBuffer(GL_ARRAY_BUFFER, color_buffer); glBufferData(GL_ARRAY_BUFFER, sizeof(float) * 9, colors, GL_STATIC_DRAW); } // 頂点シェーダの入力属性とバッファオブジェクトを対応付ける void BindVertexAttribute() { // 頂点シェーダの vertex_position と vertex_color に属性インデックス 0, 1 をマッピング glBindAttribLocation(program, 0, "vertex_position"); glBindAttribLocation(program, 1, "vertex_color"); // フラグメントシェーダの出力変数をマッピング glBindFragDataLocation(program, 0, "fragment_color"); // 頂点配列オブジェクトを 1 つ作成してバインド glGenVertexArrays(1, vao); glBindVertexArray(vao); // 頂点位置と頂点色のそれぞれについて頂点属性配列を有効化 glEnableVertexAttribArray(0); glEnableVertexAttribArray(1); // バッファオブジェクトに転送した頂点位置をインデックス 0 に関連付ける glBindBuffer(GL_ARRAY_BUFFER, position_buffer); glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte*)NULL); // バッファオブジェクトに転送した頂点色をインデックス 1 に関連付ける glBindBuffer(GL_ARRAY_BUFFER, color_buffer); glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte*)NULL); } // レンダリング void display() { glClear(GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glDrawArrays(GL_TRIANGLES, 0, 3); glFlush(); } 参考文献 OpenGLに関連するオススメの本や WEB サイトを紹介します． ページ右の画像をクリックすると Amazon で参考文献を購入できます． OpenGL策定委員会, 「OpenGLプログラミングガイド 原著第5版」, ピアソンエデュケーション OpenGLの赤本(Red Book)と呼ばれる定番の参考書の日本語版です。 少し値は張りますがOpenGLの基本的な使い方が丁寧にまとめられています。 初心者の方には敷居が高いかもしれませんがOpenGLを極めるつもりなら必須の教本だと思います。 Mark Segal, Kurt Akeley, Jon Leech, 「OpenGL4.0グラフィックスシステム」, カットシステム OpenGLの仕様書の日本語訳です。個人的には翻訳に違和感を覚えることはありませんでした。 英語が苦手な方は本書をAPIリファレンスの代わりに利用できます。 チュートリアルのような内容は含まれていませんので他の書籍との併用をオススメします。 床井 浩平, 「GLUTによるOpenGL入門」, 工学社 これから OpenGL を初めようとしている方にはこの本がオススメです。 おそらく OpenGL に関する文献の中では最も敷居が低く 3DCG に関する知識が全くなくても理解しやすいです。 少し内容は古いかもしれませんが導入という目的では最高の文献で、私もこの本から OpenGL に入門しました。 床井 浩平, 「GLUTによるOpenGL入門2 テクスチャマッピング」, 工学社 上の「GLUT によるOpenGL入門」の続編です。 前作の内容では物足りなかった方は本書を読むことで 3DCG の表現力が大幅に広がります。 引き続き平易な内容となっており、前作を読破した方であれば難なく理解できると思います。 David Wolff , 「OpenGL 4.0 シェーディング言語 -実例で覚えるGLSLプログラミング-」, ボーンデジタル 最近のゲームに見られるようなリアルな映像をつくりだすにはプログラマブル・シェーダという機能が欠かせません。 床井 浩平さんの「GLUTによるOpenGL入門2 テクスチャマッピング」でもシェーダに関しては少しだけ触れられていますが、書籍の後半で軽く紹介されているだけでいささか物足りない内容ではありますので、本格的に学ぶためにこの本の購入をオススメします。 OpenGL Reference Pages - glBindBuffer 公式の API リファレンス(英語)です。 質問・コメント欄 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/api_programming/pages/193.html
下位ページ Content ライブラリとサンプル（Libraries and samples） 必要条件（Prerequisites）Enable APIs for your project 認証証明書を作る（Create authorization credentials）Option 1 Custom URI scheme (Android, iOS, UWP)SHA-1 fingerprint Option 2 Loopback IP address (macOS, Linux, Windows desktop) Option 3 Manual copy/paste Option 4 Programmatic extraction アクセススコープを確認する（Identify access scopes） アクセストークンの受け取り方（Obtaining OAuth 2.0 access tokens）Step 1 Google OAuth 2.0 サーバーにリクエストを送るサンプル（Sample authorization URLs） パラメータ Step 2 Google prompts user for consent Step 3 Handle the OAuth 2.0 server response Step 4 認証コードとトークンを交換する (Exchange authorization code for refresh and access tokens)レスポンスサンプル Calling Google APIs AndroidでGoogle認証の準備をするProjectを作る *SHA-1 fingerprint を取得する OAuth 2.0 for Mobile Desktop Apps Note If you are new to OAuth 2.0, we recommend that you read the OAuth 2.0 overview before getting started. The overview summarizes OAuth 2.0 flows that Google supports, which can help you to ensure that you've selected the right flow for your application. This document explains how applications installed on devices like phones, tablets, and computers use Google's OAuth 2.0 endpoints to authorize access to Google APIs. OAuth 2.0 allows users to share specific data with an application while keeping their usernames, passwords, and other information private. For example, an application can use OAuth 2.0 to obtain permission from users to store files in their Google Drives. Installed apps are distributed to individual devices, and it is assumed that these apps cannot keep secrets. They can access Google APIs while the user is present at the app or when the app is running in the background. This authorization flow is similar to the one used for web server applications. The main difference is that installed apps must open the system browser and supply a local redirect URI to handle responses from Google's authorization server. Alternatives For mobile apps, you may prefer to use Google Sign-in for Android or iOS. The Google Sign-in client libraries handle authentication and user authorization, and they may be simpler to implement than the lower-level protocol described here. For apps running on devices that do not support a system browser or that have limited input capabilities, such as TVs, game consoles, cameras, or printers, see OAuth 2.0 for TVs Devices or Google Sign-in for devices. ライブラリとサンプル（Libraries and samples） ライブラリと、ここで書いている Oauth 2.0 flow の実装サンプル AppAuth for Android library and codelab AppAuth for iOS library OAuth for Apps Windows Samples 必要条件（Prerequisites） Enable APIs for your project Any application that calls Google APIs needs to enable those APIs in the API Console. To enable the appropriate APIs for your project Open the Library page in the API Console. Select the project associated with your application. Create a project if you do not have one already. Use the Library page to find each API that your application will use. Click on each API and enable it for your project. 認証証明書を作る（Create authorization credentials） OAuth2.0 を使って Google APIs にアクセスするアプリケーションはアプリ特定するための認証証明書が必要。プロジェクトに証明書を作成するステップを説明（すでにプロジェクトがある前提） API Console の認証情報ページを開き 「認証情報を作成」 「Oauth クライアント ID」 フォームを埋める。この部分は、Google の認証がサポートするリダイレクト方法を記述する。アプリケーションに対し推奨される方法を一つ選び、適切な内容を記述する。 Option 1 Custom URI scheme (Android, iOS, UWP) 推奨適用先 Android apps, iOS apps, Universal Windows Platform (UWP) apps Form values アプリケーションの種類に Android, iOS, その他を選択する。 また、パッケージ名 もしくは bundle ID （アプリケーションの種類に依るが、リダイレクトに使うカスタム URI（例えば com.example.app））を入力する。 SHA-1 fingerprint JDKのbinフォルダに移動する（か、環境変数のパスを仕込んでおく） keytool -list -v -keystore "/Users/{ユーザー名}/.android/debug.keystore" -alias androiddebugkey -storepass android -keypass android UWPアプリでは、スキーム名は39文字以下にする Note redirect_uri は com.example.app redirect_uri_path で構成。path は /（バックスラッシュ）で始まること。加えて、the libraries and samples demonstrate some platform-specific implementations of custom URI scheme redirects. Option 2 Loopback IP address (macOS, Linux, Windows desktop) ローカルウェブサーバを立てることができる場合は、これができる。 推奨適用先 macOS, Linux, and Windows デスクトップアプリ (UWP以外) Form values Other Note See the redirect_uri parameter definition for more information about the loopback IP address. It is also possible to use localhost in place of the loopback IP, but this may cause issues with client firewalls. Most, but not all, firewalls allow loopback communication. Option 3 Manual copy/paste Important カスタムURI と ルーブバック IP アドレスのほうが信頼性が高く、セキュアであるし、ユーザーフレンドリな方法になる。この方法は将来的にサポートしないかもしれない。 この方法では、HTMLページの title フィールドに認証コードを載せる。ユーザーがマニュアルでコピーをする。 Traditionally, apps that used this option programmatically extracted the authorization code from the HTML page. The copy/paste option served as a fallback in case the value could not be parsed. 推奨適用先 自動リダイレクトなどを備えていないプラットフォームのもの。テレビとか。 Form values Other Option 4 Programmatic extraction Important 手動コピー・ペーストだが、認証コードのコピー・ペーストを指示できないもの。代わりに、認証ページ側で、ユーザーにウィンドウを閉じるように指示する。 ※非推奨、組込ブラウザや web-view 用。 ▸See programmatic extraction details アクセススコープを確認する（Identify access scopes） Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there may be an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent. Before you start implementing OAuth 2.0 authorization, we recommend that you identify the scopes that your app will need permission to access. The OAuth 2.0 API Scopes document contains a full list of scopes that you might use to access Google APIs. Note Incremental authorization is not supported for installed apps or devices. アクセストークンの受け取り方（Obtaining OAuth 2.0 access tokens） The following steps show how your application interacts with Google's OAuth 2.0 server to obtain a user's consent to perform an API request on the user's behalf. Your application must have that consent before it can execute a Google API request that requires user authorization. Step 1 Google OAuth 2.0 サーバーにリクエストを送る Step 1 Google OAuth 2.0 サーバーにリクエストを送る（Send a request to Google's OAuth 2.0 server） Google's authorization server にリクエストを送るhttps //accounts.google.com/o/oauth2/v2/auth. This endpoint handles active session lookup, authenticates the user, and obtains user consent. The endpoint is only accessible over SSL, and it refuses HTTP (non-SSL) connections. サンプル（Sample authorization URLs） The URLs are identical except for the value of the redirect_uri parameter. The URLs also contain the required response_type and client_id parameters as well as the optional state parameter. Each URL contains line breaks and spaces for readability. CUSTOM URI SCHEMEの場合 https //accounts.google.com/o/oauth2/v2/auth ?scope=email%20profile response_type=code state=security_token%3D138r5719ru3e1%26url%3Dhttps //oauth2.example.com/token redirect_uri=com.example.app /oauth2redirect client_id=client_id パラメータ 認証では、組込アプリに対して、以下のクエリ文字列パラメータを扱う パラメータ client_id 必須 アプリケーションの client ID。API コンソールで見られる。 redirect_uri 必須 認証後のリダイレクト先 The table below shows the appropriate redirect_uri parameter value for each method redirect_uri values Custom URI scheme com.example.app redirect_uri_pathcom.example.app は管理下にあるドメインの DNS 表記の逆順。The custom scheme must contain a period to be valid.redirect_uri_path は /oauth2redirect のような任意のパス。パスはシングルスラッシュ "/" で始めること。 Loopback IP address http //127.0.0.1 port or http //[ 1] port -Query your platform for the relevant loopback IP address and start an HTTP listener on a random available port. Substitute port with the -actual port number your app is listening on. Manual copy/paste urn ietf wg oauth 2.0 oob Programmatic extraction urn ietf wg oauth 2.0 oob auto response_type 必須 code にする。Google OAuth 2.0 endpoint が認証コードを返すかどうか、を決定している scope 必須 アプリケーションがアクセスするユーザー情報。Google の確認画面で表示される。半角スペースで区切られたリストで指定する。The OAuth 2.0 API Scopes に scope の種類情報あり。 state 推奨 Specifies any string value that your application uses to maintain state between your authorization request and the authorization server's response. The server returns the exact value that you send as a name=value pair in the hash (#) fragment of the redirect_uri after the user consents to or denies your application's access request.You can use this parameter for several purposes, such as directing the user to the correct resource in your application, sending nonces, and mitigating cross-site request forgery. Since your redirect_uri can be guessed, using a state value can increase your assurance that an incoming connection is the result of an authentication request. If you generate a random string or encode the hash of a cookie or another value that captures the client's state, you can validate the response to additionally ensure that the request and response originated in the same browser, providing protection against attacks such as cross-site request forgery. See the OpenID Connect documentation for an example of how to create and confirm a state token. login_hint 任意 If your application knows which user is trying to authenticate, it can use this parameter to provide a hint to the Google Authentication Server. The server uses the hint to simplify the login flow either by prefilling the email field in the sign-in form or by selecting the appropriate multi-login session. Set the parameter value to an email address or sub identifier. Note Due to the fact that the client cannot keep the client_secret confidential, you cannot do incremental authorization with installed apps. Step 2 Google prompts user for consent このステップで、ユーザーがアプリケーションのアクセス要求を受け入れるかどうか決める。このステージで、 Google は確認ウィンドウを表示し、 Google API はユーザーの認証証明書とともにアクセスする権限を提供する。ユーザーはアプリケーションのアクセスを承認するか拒否するか決める。 Your application doesn't need to do anything at this stage as it waits for the response from Google's OAuth 2.0 server indicating whether the access was granted. That response is explained in the following step. Step 3 Handle the OAuth 2.0 server response アプリケーションが認証レスポンスを受ける方法は、これを扱うリダイレクトURIスキームに依存する。スキームによらず、レスポンスは認証コードかエラーを含む。たとえば、 error=access_denied なら要求が拒否されたことを示す。もし、ユーザーがアクセスを許可したら、認証コードをアクセストークンと交換し、リフレッシュトークン（後述）を受け取る。 Step 4 認証コードとトークンを交換する (Exchange authorization code for refresh and access tokens) 認証コードとアクセストークンを交換するために https //www.googleapis.com/oauth2/v4/token に次のパラメタをセットし送る。 Fields code 最初に受け取った code client_id API Console で確認したクライアントID client_secret API Console で受け取った Client Secred。ただし、Android, iOS, Chrome applications では不要。 redirect_uri One of the redirect URIs listed for your project in the API Console. grant_type authorization_code. The following snippet shows a sample request POST /oauth2/v4/token HTTP/1.1 Host www.googleapis.com Content-Type application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 client_id=your_client_id client_secret=your_client_secret redirect_uri=https //oauth2.example.com/code grant_type=authorization_code Google responds to this request by returning a JSON object that contains a short-lived access token and a refresh token. The response contains the following fields Fields access_tokenThe token that your application sends to authorize a Google API request. id_tokenNote This property is only returned if your request included an identity scope, such as openid, profile, or email. The value is a JSON Web Token (JWT) that contains digitally signed identity information about the user. refresh_tokenA token that you can use to obtain a new access token. Refresh tokens are valid until the user revokes access. Note that refresh tokens are always returned for installed applications. expires_inThe remaining lifetime of the access token in seconds. token_typeThe type of token returned. At this time, this field's value is always set to Bearer. Important Your application should store both tokens in a secure, long-lived location that is accessible between different invocations of your application. The refresh token enables your application to obtain a new access token if the one that you have expires. As such, if your application loses the refresh token, the user will need to repeat the OAuth 2.0 consent flow so that your application can obtain a new refresh token. レスポンスサンプル { "access_token" "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in" 3920, "token_type" "Bearer", "refresh_token" "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" } 関係ないレスポンスは無視してよし Calling Google APIs After your application obtains an access token, you can use the token to make calls to a Google API on behalf of a given user account or service account. To do this, include the access token in a request to the API by including either an access_token query parameter or an Authorization Bearer HTTP header. When possible, the HTTP header is preferable, because query strings tend to be visible in server logs. In most cases you can use a client library to set up your calls to Google APIs (for example, when calling the Drive API). You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground. HTTP GET examples A call to the drive.files endpoint (the Drive API) using the Authorization Bearer HTTP header might look like the following. Note that you need to specify your own access token GET /drive/v2/files HTTP/1.1 Authorization Bearer access_token Host www.googleapis.com/ Here is a call to the same API for the authenticated user using the access_token query string parameter GET https //www.googleapis.com/drive/v2/files?access_token= access_token curl examples You can test these commands with the curl command-line application. Here's an example that uses the HTTP header option (preferred) curl -H "Authorization Bearer access_token " https //www.googleapis.com/drive/v2/files Or, alternatively, the query string parameter option curl https //www.googleapis.com/drive/v2/files?access_token= access_token Refreshing an access token Access tokens periodically expire. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token. To refresh an access token, your application sends an HTTPS POST request to Google's authorization server (https //www.googleapis.com/oauth2/v4/token) that includes the following parameters Fields refresh_tokenThe refresh token returned from the authorization code exchange. client_idThe client ID obtained from the API Console. client_secretThe client secret obtained from the API Console. (The client_secret is not applicable to requests from clients registered as Android, iOS, or Chrome applications.) grant_typeAs defined in the OAuth 2.0 specification, this field must contain a value of refresh_token. The following snippet shows a sample request POST /oauth2/v4/token HTTP/1.1 Host www.googleapis.com Content-Type application/x-www-form-urlencoded client_id= your_client_id client_secret= your_client_secret refresh_token= refresh_token grant_type=refresh_token As long as the user has not revoked the access granted to the application, the token server returns a JSON object that contains a new access token. The following snippet shows a sample response { "access_token" "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in" 3920, "token_type" "Bearer" } Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working. Revoking a token In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings. It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes or removes an application. In other words, part of the removal process can include an API request to ensure the permissions granted to the application are removed. To programmatically revoke a token, your application makes a request to https //accounts.google.com/o/oauth2/revoke and includes the token as a parameter curl -H "Content-type application/x-www-form-urlencoded" \ https //accounts.google.com/o/oauth2/revoke?token={token} The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked. If the revocation is successfully processed, then the status code of the response is 200. For error conditions, a status code 400 is returned along with an error code. Note Following a successful revocation response, it might take some time before the revocation has full effect. Further Reading The Internet-Draft Best Current Practice OAuth 2.0 for Native Apps establishes many of the best practices documented here. Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates. AndroidでGoogle認証の準備をする プロジェクトを作る Projectを作る どのAPIを使うのか（とりあえず） * OAuth2.0 を使って Google APIs にアクセスするアプリケーションはアプリ特定するための認証証明書が必要。プロジェクトに証明書を作成するステップを説明（すでにプロジェクトがある前提） API Console の認証情報ページを開き 「認証情報を作成」 「Oauth クライアント ID」 フォームを埋める。この部分は、Google の認証がサポートするリダイレクト方法を記述する。アプリケーションに対し推奨される方法を一つ選び、適切な内容を記述する。 SHA-1 fingerprint を取得する Projectで、認証キーの発行に必要になる SHA-1 fingerprint を取得する debug.keystoreの場所を確認する通常は /Users/{ユーザー名}/.android/debug.keystore JDKのbinフォルダに移動する（か、環境変数のパスを仕込んでおく） keytool -list -v -keystore "/Users/{ユーザー名}/.android/debug.keystore" -alias androiddebugkey -storepass android -keypass androidパスワードを求められたら android を入力
https://w.atwiki.jp/api_programming/pages/236.html
IFTTTでトリガを掛ける IFTTT で webhooks を用い、ここで指定された URL にアクセスすると、トリガをかけられる。 Webhooks の使い方 ここで登録すると、"code" が割り当てられる https //maker.ifttt.com/trigger/{event}/with/key/.... .... が "code"。{event} になにか文字列（多分英数半角に限定？）を入れてアクセスすると、これを引数として使うことができる。 同様に、POST をつかって、JSON で値を渡すと、３つまで値を渡すことができる。 {"value1" value1 , "value2" value2 , "value3" value3 } https //ifttt.com/maker_webhooks AutomateからIFTTTにアクセスするやつ https //llamalab.com/automate/community/flows/20172*大見出し Because the internet is an amazing place, you can trigger your IFTTT applets with this automate flow. To make this work, follow these steps STEP 1 Get your maker API. IFTTTアカウントを取る ifttt.comへ行く。 Applets pageへ行く Services page で "Webhooks" を検索 card が見つかったらクリック Webhook の documentation page で API URL をコピーする。 コピーしたら、"Setup API" flow を実行する API URL を貼り付ける {event} code を "EVENTHERE" (All uppercase, no quotes) で置き換える Confirm it. STEP 2 Make an applet. There are loads of services on IFTTT to play with. applets page で"New applet" をクリック トリガとしてSelect the Webhooks service を選ぶ event name の入力を要求されるので、適用な何かを入れる アクションを選ぶ。 STEP 3 Make a button Setup Buttons flow を走らせる Click add new. ウィンドウが開いたらボタンタイトルを入れる。 次のダイアログでは、２番めのステップで選んだイベント名を入れる。 あとでボタンを消したい場合は、同じflowでボタンをクリックすると消える。 STEP 4 Profit. "Flow" のショートカットを作り、好きなときに走らせよう。 Tap the desired button to execute the applet. v1.1 Now you can integrate this flow into your flows by adding a flow start block. Place flow start anywhere in your flow and set the payload argument to the action name.
https://w.atwiki.jp/gametips/pages/37.html
更新日時 2013-06-15 23 53 54 (Sat)アクセス数 - glDrawElements 目次 概要 エラー サンプルコード 参考文献 概要 void glDrawElements(GLenum mode, GLsizei count, GLenum type, const GLvoid *indices); 属性配列からプリミティブのレンダリングを行います。 glDrawArrays によく似ていますが、この API では頂点インデックスを指定することができる点が異なります。 第 1 引数 mode では以下の定数を利用してプリミティブの種類を指定します。 定数 注釈 GL_POINTS GL_LINE_STRIP GL_LINE_LOOP GL_LINE_LINES GL_LINE_STRIP_ADJACENCY OpenGL 3.2 以上で利用できます GL_LINE_ADJACENCY OpenGL 3.2 以上で利用できます GL_TRIANGLE_STRIP GL_TRIANGLE_FAN GL_TRIANGLES GL_TRIANGLE_STRIP_ADJACENCY OpenGL 3.2 以上で利用できます GL_TRIANGLES_ADJACENCY OpenGL 3.2 以上で利用できます GL_PATCHES 第 2 引数 count には要素数を指定します。 第 3 引数 type では第 4 引数 indices の型を指定します。 GL_UNSIGNED_BYTE, GL_UNSIGNED_SHORT, GL_UNSIGNED_INT のいずれかを指定しなければなりません。 第 4 引数 indices では頂点インデックスを格納した配列を指定します。 エラー GL_INVALID_ENUM 第 1 引数 mode が許可されている値でない場合に生成されます。 GL_INVALID_VALUE 第 2 引数 count が負である場合に生成されます。 GL_INVALID_OPERATION ジオメトリシェーダが有効で現在のプログラムが入力されたプリミティブタイプに互換性が無い場合に発生します generated if a non-zero buffer object name is bound to an enabled array and the buffer object s data store is currently mapped. サンプルコード 以下に、頂点インデックスを指定してレンダリングするコードの例を示します。 より実用的には、8 頂点だけから立方体をレンダリングする例が考えられます。 ///**********************************************//** /// 頂点インデックスを指定して四角形をレンダリングします。 /// ここではシェーダのコンパイルとリンクは省略されています。 ///**********************************************//** // バッファオブジェクトへのハンドル GLuint position_buffer; GLuint color_buffer; // 頂点配列オブジェクトへのハンドル GLuint vao; // 四角形ポリゴンの位置・色・頂点インデックスの定義 float positions[] = { -0.5f, -0.5f, -0.5f, +0.5f, -0.5f, -0.5f, +0.5f, +0.5f, -0.5f, -0.5f, +0.5f, -0.5f }; float colors[] = { 1.0f, 0.0f, 0.0f, 1.0f, 1.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 1.0f, 1.0f, }; unsigned int indices[] = { 1,2,0,3 }; // バッファオブジェクトの生成 void CreateBufferObject() { // バッファオブジェクトの生成 GLuint vbo[2]; glGenBuffers(2, vbo); position_buffer = vbo[0]; color_buffer = vbo[1]; // 頂点位置をバッファオブジェクトに転送 glBindBuffer(GL_ARRAY_BUFFER, position_buffer); glBufferData(GL_ARRAY_BUFFER, sizeof(float) * 24, positions, GL_STATIC_DRAW); // 頂点色をバッファオブジェクトに転送 glBindBuffer(GL_ARRAY_BUFFER, color_buffer); glBufferData(GL_ARRAY_BUFFER, sizeof(float) * 24, colors, GL_STATIC_DRAW); } // 頂点シェーダの入力属性とバッファオブジェクトを対応付ける void BindVertexAttribute() { // 頂点シェーダの vertex_position と vertex_color に属性インデックス 0, 1 をマッピング glBindAttribLocation(program, 0, "vertex_position"); glBindAttribLocation(program, 1, "vertex_color"); // フラグメントシェーダの出力変数をマッピング glBindFragDataLocation(program, 0, "fragment_color"); // 頂点配列オブジェクトを 1 つ作成してバインド glGenVertexArrays(1, vao); glBindVertexArray(vao); // 頂点位置と頂点色のそれぞれについて頂点属性配列を有効化 glEnableVertexAttribArray(0); glEnableVertexAttribArray(1); // バッファオブジェクトに転送した頂点位置をインデックス 0 に関連付ける glBindBuffer(GL_ARRAY_BUFFER, position_buffer); glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte*)NULL); // バッファオブジェクトに転送した頂点色をインデックス 1 に関連付ける glBindBuffer(GL_ARRAY_BUFFER, color_buffer); glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte*)NULL); } // レンダリング void display() { glClear(GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glDrawElements(GL_TRIANGLE_STRIP, sizeof(indices)/sizeof(indices[0]), GL_UNSIGNED_INT, indices); glFlush(); } 参考文献 OpenGLに関連するオススメの本や WEB サイトを紹介します． ページ右の画像をクリックすると Amazon で参考文献を購入できます． OpenGL策定委員会, 「OpenGLプログラミングガイド 原著第5版」, ピアソンエデュケーション OpenGLの赤本(Red Book)と呼ばれる定番の参考書の日本語版です。 少し値は張りますがOpenGLの基本的な使い方が丁寧にまとめられています。 初心者の方には敷居が高いかもしれませんがOpenGLを極めるつもりなら必須の教本だと思います。 Mark Segal, Kurt Akeley, Jon Leech, 「OpenGL4.0グラフィックスシステム」, カットシステム OpenGLの仕様書の日本語訳です。個人的には翻訳に違和感を覚えることはありませんでした。 英語が苦手な方は本書をAPIリファレンスの代わりに利用できます。 チュートリアルのような内容は含まれていませんので他の書籍との併用をオススメします。 床井 浩平, 「GLUTによるOpenGL入門」, 工学社 これから OpenGL を初めようとしている方にはこの本がオススメです。 おそらく OpenGL に関する文献の中では最も敷居が低く 3DCG に関する知識が全くなくても理解しやすいです。 少し内容は古いかもしれませんが導入という目的では最高の文献で、私もこの本から OpenGL に入門しました。 床井 浩平, 「GLUTによるOpenGL入門2 テクスチャマッピング」, 工学社 上の「GLUT によるOpenGL入門」の続編です。 前作の内容では物足りなかった方は本書を読むことで 3DCG の表現力が大幅に広がります。 引き続き平易な内容となっており、前作を読破した方であれば難なく理解できると思います。 David Wolff , 「OpenGL 4.0 シェーディング言語 -実例で覚えるGLSLプログラミング-」, ボーンデジタル 最近のゲームに見られるようなリアルな映像をつくりだすにはプログラマブル・シェーダという機能が欠かせません。 床井 浩平さんの「GLUTによるOpenGL入門2 テクスチャマッピング」でもシェーダに関しては少しだけ触れられていますが、書籍の後半で軽く紹介されているだけでいささか物足りない内容ではありますので、本格的に学ぶためにこの本の購入をオススメします。 OpenGL Reference Pages - glDrawElements 公式の API リファレンス(英語)です。 質問・コメント欄 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/pspprogram/pages/52.html
機能 コントローラーの押されてるボタンを調べます。 API int sceCtrlReadBufferPositive(SceCtrlData *pad_data, int count); pspctrl.hより 第一引数 pspctrl.h内で定義されてるSceCtrlDataのポインタを わたす。 /** Returned controller data */ typedef struct SceCtrlData { /** The current read frame. */ unsigned int TimeStamp; /** 押されてるボタンのデータPspCtrlButtonsのフラグを使う */ unsigned int Buttons; /** アナログスティックの X 軸. */ unsigned char Lx; /** アナログスティックの Y 軸. */ unsigned char Ly; /** 予約してある つかうなこのやろー */ unsigned char Rsrv[6]; } SceCtrlData; 第二引数 たぶん第一引数の個数 普通は１でつかうよね
https://w.atwiki.jp/api_programming/pages/102.html
認証 (for non-public checklists) ベーシックHTTP認証を扱えるなら、それが使える。パスワードは実際のもの。ユーザープロファイルページから取得した Remote APIキーもつかえる。 Tokenを使った認証 tokenを取得する そのtokenを使って、通信。 tokenには有効期限がある。通信の有効期限：1日（デフォルトで？変えられる？） tokenを更新する：90日 refresh_token tokenの取得 To obtain the token, you should use the following API call URL Method HTTP parameters Response /auth/login.json get/post username - ログイン名(email)remote_key - User s remote API Key （プロファイルページで取得 or パスワード）callback - Optional javascript callback function (will get token as a parameter) Returns quoted token string in the body, unless callback parameter is passed. If authentication failed, will return HTTP status 403 Forbidden. Ahd here is the refresh_token call, which allows to get the new token without providing username/remote_key. URL Method HTTP parameters Response /auth/refresh_token.json get/post old_token - Previously obtained tokencallback - Optional javascript callback function (will get token as a parameter)
https://w.atwiki.jp/wximsupport/pages/31.html
Mozillaの、日本語入力を司っている部分 Mozillaはクロスプラットフォームにするための自前のツールキットを持っている。それには当然日本語入力に関連する部分も含まれる。 mozilla/widget/publicnsIWidget.h nsGUIEvent.h mozilla/widget/src/windowsnsIMM32Handler.h/cppnsIMEContext nsIMM32Handler nsWindow.cppnsWindow mozilla/widget/src/cocoansChildView.h/mmnsChildView nsCocoaTextInputHandler.h/mmnsTISInputSource nsCocoaIMEHandler nsCocoaTextInputHandler nsIWidgetSetIMEOpenState GetIMEOpenState SetIMEEnabled GetIMEEnabled CancelIMEComposition OnIMEFocusChange OnIMETextChange OnIMESelectionChange