k本的に無料ソフト・フリーソフト管理人様からWindows XP SP3(32bit)での動作確認についてご報告頂きました。
次回アップデート時に動作環境を更新しようと思ってたのですが、取り急ぎこちらに記しておきます。
私のところにはXPの環境が無いので非常に助かります(^^
k本的に無料ソフト・フリーソフト様はakinoboardもご紹介下さっており、大変感謝しております。
2011年10月6日木曜日
2011年10月1日土曜日
Windows Phone SDK 7.1が公開されましたね
RCは何となく見送っていたけど、RTWが出たんだったら一応手を出してみたいと思っています。
#ダウンロード先はこちら
IMEを作ってみたいんだけど、シングルタスクっぽいし(ちゃんと調べてないので間違っている可能性大)コピペでのなんちゃってIMEになるのかなー。
まだ何も調べずに独りごちてるだけなので、世の中的にはAndroidでのWnnのようにオープンなIMEがWP7上でも公開されているのかも。
そろそろどっかのコミュニティにでも入ろうかなぁ。。。
#ダウンロード先はこちら
IMEを作ってみたいんだけど、シングルタスクっぽいし(ちゃんと調べてないので間違っている可能性大)コピペでのなんちゃってIMEになるのかなー。
まだ何も調べずに独りごちてるだけなので、世の中的にはAndroidでのWnnのようにオープンなIMEがWP7上でも公開されているのかも。
そろそろどっかのコミュニティにでも入ろうかなぁ。。。
2011年9月29日木曜日
[akinoboard] akinoboardの紹介
akinoboardは、日本語入力時に必要な作業量を軽減することで、手軽に文字を入力できることを特徴とするソフトウェアキーボード(スクリーンキーボード)です。
(ダウンロードはこちら(Vector)からどうぞ)
特に、ウェブサーフィン中に検索キーワードを入力するなど、短文や単語をたまに入力しては元の作業に戻るような作業に最適です。
同時に、背景に画像ファイルを指定できるなど、外観的にも楽しめるように設計しています。
具体的には以下の特徴的な機能を持ちます。
また、文字入力以外の部分では以下のような特徴があります。
『利用シナリオ例(どちらもIMEオン時を前提)』
----------
私は適当にウェブサーフィンをしている時には、椅子に背もたれながら肘置きにトラックボールを置いて操作するという、ぐーたら全開スタイルな人間です。
その中でたまーに検索などで文字を打たなければならない場合に、いちいち体を起こしてわざわざキーボードを打たなければならいのが、本当に面倒なんですよねw
Windows付属や他のソフトウェアキーボードも使ってみたのですが、マウスの移動が多いのが面倒だったり、ソフトウェアキーボードのウィンドウがいちいち邪魔だったり、どうも私には合いそうにありませんでした。
そこで、一層のこと欲しい機能を盛り込んでしまえと開発したのがakinoboardになります。
そのため、ここに書いたのと同じような作業の仕方をしている方にはとても利便性の高いソフトウェアキーボードになったのではないかと思っています。
ぶっちゃけ文書作成時以外は文字入力は検索がほとんどなので、Ctrl-Fのショートカットキーなども搭載しようと思いましたが、要望があればまた次回以降にでも…。
(ダウンロードはこちら(Vector)からどうぞ)
特に、ウェブサーフィン中に検索キーワードを入力するなど、短文や単語をたまに入力しては元の作業に戻るような作業に最適です。
同時に、背景に画像ファイルを指定できるなど、外観的にも楽しめるように設計しています。
具体的には以下の特徴的な機能を持ちます。
- マウス右クリックで漢字変換候補を選択
- マウスホイールで予測変換候補を選択
- 候補選択後にマウス左クリックで変換候補を確定
- 候補確定後にマウス左クリックでエンター入力(例えば検索ボックス入力時には検索開始)
また、文字入力以外の部分では以下のような特徴があります。
- マウスが離れている間はakinoboardを自動で透明・非表示化
- マウス左ホールド(押しっぱなし)位置にakinoboardを表示・移動
- サイズは自由に変更可能(縦横比は固定)
- 任意の色、画像ファイルを背景に指定可能(画像ファイルは各自で用意して下さい)
![]() |
| 風景写真にしても良し |
![]() |
| お気に入りのキャラにしても良し |
![]() |
| 背景とキー部分は個別に透明度を設定することが可能 |
![]() |
| ちびっと萌え系にしても良し |
『利用シナリオ例(どちらもIMEオン時を前提)』
- フォルダ名を「フリーウェア」から「ソフトウェア」に変更したい
- フォルダから名前の変更を選択
- "フリー"の部分を選択(文字選択)してそのまま左ホールド(ver.1.1以降はスイングしながら選択 or ホールドして3.後に文字選択)
- akinoboardが付近に移動・表示
- "s" "o" "f" "u" "t" "o"を入力
- "o"からマウスを動かさずそのまま右クリックで漢字変換候補を選択
- 左クリックで「ソフト」を確定
- 続けて左クリックで名前の変更を確定
- ウェブサーフィン中に「京都御所」を検索したい
- ブラウザの検索ボックスを左ホールド
- 検索ボックスにキャレットが移動&akinoboardが付近に移動・表示
- "k" "y" "o" "u" "t" "o" "g"を入力
- IMEの予測候補の2番目に「京都御所」が表示されたならば…
- "g"からマウスを動かさずそのままマウスホイールで予測候補から「京都御所」を選択
- 左クリックで「京都御所」を確定
- 続けて左クリックで「京都御所」で検索開始
----------
私は適当にウェブサーフィンをしている時には、椅子に背もたれながら肘置きにトラックボールを置いて操作するという、ぐーたら全開スタイルな人間です。
その中でたまーに検索などで文字を打たなければならない場合に、いちいち体を起こしてわざわざキーボードを打たなければならいのが、本当に面倒なんですよねw
Windows付属や他のソフトウェアキーボードも使ってみたのですが、マウスの移動が多いのが面倒だったり、ソフトウェアキーボードのウィンドウがいちいち邪魔だったり、どうも私には合いそうにありませんでした。
そこで、一層のこと欲しい機能を盛り込んでしまえと開発したのがakinoboardになります。
そのため、ここに書いたのと同じような作業の仕方をしている方にはとても利便性の高いソフトウェアキーボードになったのではないかと思っています。
ぶっちゃけ文書作成時以外は文字入力は検索がほとんどなので、Ctrl-Fのショートカットキーなども搭載しようと思いましたが、要望があればまた次回以降にでも…。
ラベル:
[公開ソフト]akinoboard
2011年9月22日木曜日
[akinoboard] akinoboardを公開しました
このブログでも当初から述べていたソフトウェアキーボードをやっと公開できました。
これから入力手法も含めて色々と新しい手法を提案、実装していくつもりですが、まず原型としてのソフトウェアキーボードをakinoboardと名付けて公開しています。
ダウンロードはVectorのページからどうぞ。
ご感想などございましたらコメントをいただけると励みになります。
ついでに興味があれば広告もぽちっとしていただけると…w
要望があれば、ブログの方でもっと詳しい使い方と言うか、私が想定している利用シナリオ例のようなものも紹介していくつもりです。
なお、WindowsPhoneにも手を出したいんだけど勉強する時間があまりないので、暫くは通常のWindows向けに進めていくつもりです(予定は未定)。
これから入力手法も含めて色々と新しい手法を提案、実装していくつもりですが、まず原型としてのソフトウェアキーボードをakinoboardと名付けて公開しています。
ダウンロードはVectorのページからどうぞ。
ご感想などございましたらコメントをいただけると励みになります。
ついでに興味があれば広告もぽちっとしていただけると…w
要望があれば、ブログの方でもっと詳しい使い方と言うか、私が想定している利用シナリオ例のようなものも紹介していくつもりです。
なお、WindowsPhoneにも手を出したいんだけど勉強する時間があまりないので、暫くは通常のWindows向けに進めていくつもりです(予定は未定)。
ラベル:
[公開ソフト]akinoboard
2011年9月11日日曜日
デバイス非依存ピクセル
最近はまった事例を少し。
コンピュータ上でのピクセル表現には、ハードウェアピクセルとデバイス非依存ピクセルの2種類がある。
詳しいことは書かないけど(そもそも厳密に分かってはいない…)、OSの設定でDPI(dot per inch)を変更するとデザインに狂いが生じる可能性があるため、DPIに影響されないピクセル表現としてデバイス非依存ピクセルがあるみたい。
#間違っていたらご指摘下さい
で、Win32API等一昔前のAPIだとハードウェアピクセル、WPF等最近のAPIだとデバイス非依存ピクセルが基本となっている。
それぞれ単独で使う分には問題ないんだけど、相互運用時には少し注意しなければならない。
例えば、Win32APIで座標(100,100)とWPFでの座標(100,100)では結果としてデスクトップ上の異なる座標を指すことがある。
WPFでも96DPIの場合(Windows7では「テキストやその他の項目の大きさの変更」で「小–100% (既定)」を選んでいる場合)には同じ座標を指すことになるけど、その他の設定(96DPI以外)にしている場合には一致しなくなる。
そのため、両者間で橋渡しするためには座標変換が必要になる。
私が利用している基本コードは以下の通り。
ただし、SourceInitialized以降でないときちんと動かないのでご注意を。
参照を増やしたくないからこのような手法を取ってるけど、そうでないならこちらで紹介されている手法の方が理解しやすいかも知れないなぁ。
コンピュータ上でのピクセル表現には、ハードウェアピクセルとデバイス非依存ピクセルの2種類がある。
詳しいことは書かないけど(そもそも厳密に分かってはいない…)、OSの設定でDPI(dot per inch)を変更するとデザインに狂いが生じる可能性があるため、DPIに影響されないピクセル表現としてデバイス非依存ピクセルがあるみたい。
#間違っていたらご指摘下さい
で、Win32API等一昔前のAPIだとハードウェアピクセル、WPF等最近のAPIだとデバイス非依存ピクセルが基本となっている。
それぞれ単独で使う分には問題ないんだけど、相互運用時には少し注意しなければならない。
例えば、Win32APIで座標(100,100)とWPFでの座標(100,100)では結果としてデスクトップ上の異なる座標を指すことがある。
WPFでも96DPIの場合(Windows7では「テキストやその他の項目の大きさの変更」で「小–100% (既定)」を選んでいる場合)には同じ座標を指すことになるけど、その他の設定(96DPI以外)にしている場合には一致しなくなる。
そのため、両者間で橋渡しするためには座標変換が必要になる。
私が利用している基本コードは以下の通り。
// hardwarePointはハードウェアピクセル
Point HardwareToWpf(Point hardwarePoint)
{
PresentationSource pSource = PresentationSource.FromVisual(Visualオブジェクト);
CompositionTarget cTarget = pSource.CompositionTarget;
Matrix hardwareToWpfMatrix = cTarget.TransformFromDevice;
return hardwareToWpfMatrix.Transform(Point hardwarePoint);
}
ただし、SourceInitialized以降でないときちんと動かないのでご注意を。
参照を増やしたくないからこのような手法を取ってるけど、そうでないならこちらで紹介されている手法の方が理解しやすいかも知れないなぁ。
2011年9月5日月曜日
備忘録:WPFレイアウト関係
WPFのレイアウトについて、基礎的なところだけどきちんと確認していなかったので、改めて調べた結果を備忘録として記入。
・HorizontalAlignment, VerticalAlignment.Stretch
コントロールのWidth, Heightが設定されていた場合そちらが優先される。その場合は親の中央に配置される。Stretchを有効にするためにはこれらのプロパティにはDouble.NaN(自動サイズ)を設定すること。
・自動サイズ変更
Stretch以外のAlignmentを設定している場合には、そのコントロール全体(子を含む)が表示される最小限のサイズを上限として自動変更が実行される。たとえば、BのルートがAとして、Bが含む子の中で一番右に配置される子の右端=80の場合、A.Width=60ではB.Width=60となるが、A.Width=100ではB.Width=80となり、残りの20は余白となる。
・配置位置とマージン
マージン以下の座標にコントロールが配置される場合には表示されない。たとえば、左マージンが50の場合に、幅100のコントロールの右座標が120に設定されると、コントロール右部分30~100の部分のみ描画される。
ここに書いてあることは完全に私的な備忘録レベルで文章的にも書き散らしているので、信頼性は申し訳ありませんが保証できません。。。
厳密にリファレンスを読み込んだ結果ではないので、あくまでも一個人意見の参考だと思っていて下さい。
話は変わりますが、現在ソフトウェアキーボードの開発をやっとのことで進めております。
まずは機能をあまり詰め込まずに素直なキーボードを作っています。
完全に普通のキーボードだとつまらないので、少しだけ他のソフトとは異なる機能を盛り込んでいます。
完成したらベクターあたりでの公開を考えていますので、もし興味がありましたら使っていただけると幸いです。
・HorizontalAlignment, VerticalAlignment.Stretch
コントロールのWidth, Heightが設定されていた場合そちらが優先される。その場合は親の中央に配置される。Stretchを有効にするためにはこれらのプロパティにはDouble.NaN(自動サイズ)を設定すること。
・自動サイズ変更
Stretch以外のAlignmentを設定している場合には、そのコントロール全体(子を含む)が表示される最小限のサイズを上限として自動変更が実行される。たとえば、BのルートがAとして、Bが含む子の中で一番右に配置される子の右端=80の場合、A.Width=60ではB.Width=60となるが、A.Width=100ではB.Width=80となり、残りの20は余白となる。
・配置位置とマージン
マージン以下の座標にコントロールが配置される場合には表示されない。たとえば、左マージンが50の場合に、幅100のコントロールの右座標が120に設定されると、コントロール右部分30~100の部分のみ描画される。
ここに書いてあることは完全に私的な備忘録レベルで文章的にも書き散らしているので、信頼性は申し訳ありませんが保証できません。。。
厳密にリファレンスを読み込んだ結果ではないので、あくまでも一個人意見の参考だと思っていて下さい。
話は変わりますが、現在ソフトウェアキーボードの開発をやっとのことで進めております。
まずは機能をあまり詰め込まずに素直なキーボードを作っています。
完全に普通のキーボードだとつまらないので、少しだけ他のソフトとは異なる機能を盛り込んでいます。
完成したらベクターあたりでの公開を考えていますので、もし興味がありましたら使っていただけると幸いです。
2011年7月27日水曜日
登録:
投稿 (Atom)



