Windows 8.1 で加わった Per-Monitor DPI と WPF での対応方法

先日の めとべや東京勉強会 #2 にて WPF での Per-Monitor DPI 対応アプリのデモをしましたが、アプリが完成したので公開します。

XamClaudia
https://github.com/Grabacr07/XamClaudia

間もなく Windows 8.1 公開ですね!
ということで、Windows 8.1 の新機能である Per-Monitor DPI の解説と対応方法の紹介をします。

High DPI と WPF

昨今のタブレット PC などは、本体の小型化と同時にモニターの高精細化が進んでおり、1 ドットの物理的なサイズがどんどん小さくなっています。たとえば、Surface Pro (10.6”, Full-HD) の 1 ドットのサイズは約 0.12 mm です。

そのため、Windows の High DPI 設定が既定で 125 % や 150 % になっている PC も増え、必然的にアプリ側も High DPI 対応は必須と言える状況になりました。
スクリーンショット (7)

DPI 仮想化

この High DPI に対応していないアプリは High DPI 環境でどうなるかというと、DPI 仮想化と呼ばれる Windows の機能により、自動的にスケーリングされます。いわゆる救済策のようなもの。

ただし、ピクセル単位でのスケーリングになるため、単純に画像を拡大縮小したのと同じで、ボケた表示になってしまうのが残念なところ。所詮は救済策です。
dpi-virtualization

WPF は気にしない!

以前の投稿にも書いたとおり、WPF アプリは DPI 設定と一致するよう自動的にスケーリングされます。DPI 仮想化とは違い、しっかりスケーリング後のサイズに合わせてキレイに描画されます。

そのため、Windows デスクトップ アプリは、WPF で開発していれば基本的には自前で High DPI 対応する必要がなく、とても楽です。
wpf

Windows 8.1 の新機能 “Per-Monitor DPI”

Windows 8.1 では、新たに “Per-Monitor DPI” という機能が追加され、モニターごとに異なる DPI を使用できるようになりました。
per-monitor dpi

High DPI 設定されたタブレットと一般的なサブ モニターを接続したとき、その必要がないサブ モニターまで High DPI 設定となり、非常に使いづらかった… のですが、Windows 8.1 からその悩みが解消されます。待ち望んでいた機能です。

Per-Monitor DPI に対応したアプリは、モニターをまたいだタイミング (= DPI 設定が変わったタイミング) でウィンドウをスケーリングし、そのモニターの DPI 設定にマッチしたサイズで表示することができるようになり、可視性が大幅に向上します。

この Per-Monitor DPI に対応したアプリを開発する方法は後述します。

Per-Monitor DPI 環境での各アプリの挙動

Per-Monitor DPI に対応していないアプリは、前述の DPI 仮想化により、モニターをまたいだタイミングで Windows が自動的にスケーリングします。ただし、High DPI のときと同じで、ボケた表示となってしまいます。

High DPI および Per-Monitor DPI に対応したアプリと、対応していないアプリが、それぞれどのような挙動になるか、例を 2 パターンほど挙げてみました。

プライマリ モニターが 200 %、セカンダリ モニターが 100 % の環境

割とよくありそうな環境です。タブレット PC 本体をプライマリ モニターとし、デスク据え置きのディスプレイをセカンダリ モニターとして接続した場合など。

プライマリ モニター (DPI 200 %) で起動したとき セカンダリ モニター (DPI 100 %) へウィンドウを移動したとき
High DPI 非対応 DPI 仮想化により、200 % のサイズに拡大されて表示 (ボケる) DPI 仮想化により 100 % のサイズに縮小されて表示 (ちょうど 100 % なのでボケない)
High DPI 対応
Per-Monitor DPI 非対応
(WPF など)
自身の High DPI 対応処理で、200 % のサイズで表示 DPI 仮想化により 100 % のサイズに縮小されて表示 (元が 200 % に合わせたサイズなのでボケる)
High DPI および
Per-Monitor DPI 対応
自身の High DPI 対応処理で、200 % のサイズで表示 自身の Per-Monitor DPI 対応処理で、100 % のサイズで表示

プライマリ モニターが 100 %、セカンダリ モニターが 200 % の環境

上記の逆。あんまりないかも?

プライマリ モニター (DPI 100 %) で起動したとき セカンダリ モニター (DPI 200 %) へウィンドウを移動したとき
High DPI 非対応 そのまま表示 DPI 仮想化により 200 % のサイズに拡大されて表示 (ボケる)
High DPI 対応
Per-Monitor DPI 非対応
(WPF など)
そのまま表示 DPI 仮想化により 200 % のサイズに拡大されて表示 (ボケる)
High DPI および
Per-Monitor DPI 対応
そのまま表示 自身の Per-Monitor DPI 対応処理で、200 % のサイズで表示


赤字部分
が、DPI 仮想化によりボケて表示される部分です。

ここで問題なのは、explorer.exe をはじめとした Windows 本体の一部のアプリケーションや WPF アプリすべてが、2 番目の「High DPI 対応、Per-Monitor DPI 非対応」に分類されることです。

High DPI 環境では DPI 設定に合わせて自動的にスケーリングしてくれて楽だった WPF アプリも、Per-Monitor DPI 環境では DPI 仮想化によりボケて表示されてしまうのです。なんで High DPI 環境はキレイにスケーリングできるのに Per-Monitor DPI には対応してくれないんだと文句を言いたい。非常に残念。

Per-Monitor DPI 対応方法

ということで、Per-Monitor DPI 対応方法です。
コードは C# + WPF ですが、C++ でもやることは変わらない、はず。

モニターの DPI を取得する

まず、ウィンドウがどのモニターに属しているかを判別します。

MonitorFromWindow function
http://msdn.microsoft.com/en-us/library/windows/desktop/dd145064(v=vs.85).aspx

次に、モニターの DPI 設定値を取得します。
Windows 8.1 で、モニターの DPI 設定を取得する関数が追加されました。MonitorFromWindow 関数で得た hmonitor (IntPtr) を指定し、そのモニターの DPI 設定値 (96, 120, 144, 192, など) を取得できます。

GetDpiForMonitor function
http://msdn.microsoft.com/library/windows/desktop/dn280510.aspx

MONITOR_DPI_TYPE enumeration
http://msdn.microsoft.com/ja-JP/library/windows/desktop/dn280511.aspx

WPF で実装する場合は P/Invoke 祭りですね。。。

GetDpiForMonitor 関数の MonitorDpiType の意味は、次のとおり。

MonitorDpiType 値 GetDpiForMonitor 関数で取得される DPI 値の意味
MDT_Effective_DPI DWM が使用する DPI 値。
96, 120, 144 など。Per-Monitor DPI でスケーリングするときは、これを使用する。
MDT_Angular_DPI よくわからん。どなたか教えてください (´・_・`)
MDT_Raw_DPI Windows の DPI 設定に依らない、デバイスの物理的な DPI (たぶん)。
たとえば、Acer ICONIA W7 は 11.6″ の 1920 x 1080 で 190 ppi になるが、MDT_Raw_DPI を指定したところ 190 が返ってきた。
MDT_Default = MDT_Effective_DPI

これらをふまえ、ウィンドウ (HwndSource) から DPI 設定値を取得するコードは、以下のようになります。

DPI の変更通知を受け取る

また、ウィンドウが使用すべき DPI 設定が変わったことを示すウィンドウ メッセージが飛んでくるようになりました (主にウィンドウがモニターをまたいだタイミングなど)。

WM_DPICHANGED
http://msdn.microsoft.com/en-us/library/windows/desktop/dn312083(v=vs.85).aspx

アプリケーションが Per-Monitor DPI 対応であることを宣言する

そして、忘れてはならないのが、マニフェストです。
アプリケーションが Per-Monitor DPI に対応していることを宣言します。

従来まで、dpiAware で指定できる値は True と False の 2 つでしたが、Windows 8.1 から更に 2 つ加わっています。それぞれの意味は下記のとおり。

dpiAware 値 意味
False High DPI 非対応。
High DPI 環境では DPI 仮想化により自動スケーリングされる。
True High DPI 対応。
Per-Monitor DPI には非対応なので、Windows 8.1 でモニターをまたぐと DPI 仮想化により自動スケーリングされる。
Per-Monitor
(新規追加)
Per-Monitor DPI 対応。
Windows Vista ~ 8 では、False を指定したときと同じ挙動。
True/PM
(新規追加)
Per-Monitor DPI 対応。
Windows Vista ~ 8 では、True を指定したときと同じ挙動。

マニフェストで Per-Monitor DPI に対応していることを宣言すると、DPI 仮想化による自動スケーリング (= 非対応アプリ向けの救済措置) が行われなくなります。

モニターの DPI 値に合わせて、ウィンドウとコンテンツをスケーリングさせれば完成です。
WPF の場合は、ウィンドウのリサイズと共に、ウィンドウのコンテンツを ScaleTransform でスケーリングさせてやればよいでしょう (ほかに良い感じの実装方法があったらご教示頂きたく)。

サンプル アプリ

というわけで、サンプルアプリを作りました。以前 XAML でクラウディアさんを描きました が、そのときのアプリを Per-Monitor DPI に対応させたものです。

XamClaudia
https://github.com/Grabacr07/XamClaudia

XamClaudia プロジェクトが XAML で描いたクラウディアさんを表示するだけのアプリ、PerMonitorDpi プロジェクトが、Per-Monitor DPI に対応するためのライブラリ、になります。

Per-Montor DPI に対応させたいウィンドウを、PerMonitorDpi.Views.PerMonitorDpiWindow クラスから継承させるだけです。

ちなみに XAML のクラウディアさんは XamClaudia.WPF/Views/Claudia.xaml にありますが、頂点数多めでかなり雑な仕上がりですので、あくまでネタと思ってください。。。

実行結果

そして、肝心の実行結果がこちら。プライマリ モニターが DPI 125 %、セカンダリ モニターが DPI 100 % の環境で (それしか手元になかった…)、ウィンドウをセカンダリー モニターに移動したときのスクリーンショットになります。

Per-Monitor DPI に対応せず、DPI 仮想化によってスケーリングされたもの (クリックで拡大)。
スクリーンショット (6)
(NT バージョンが 6.2 と出てるのは、マニフェストを埋め込まなかったので Environment.OSVersion が Windows 8 と同じ 6.2 を返しているためであり、実行環境はもちろん Windows 8.1 です)

そして、Per-Monitor DPI に対応し、スケーリング処理を行ったもの (クリックで拡大)。
スクリーンショット (5)

お わ か り 頂 け た だ ろ う か 。

上の方がボケてますよね? 下の方がくっきりですよね?
DPI 200 % のような環境を用意できればもっとわかりやすかったのでしょうが、手元にその環境を用意できなかったのでご容赦ください。。。

なお、お手元の環境で実行結果だけ見たいという方向けに、Per-Monitor DPI 対応版、非対応版の両方を同梱したサンプルを置いておきます。お試しください。

Per-Monitor DPI Aware / Unaware application sample
http://grabacr.net/wp-content/uploads/dpi-aware-unaware-sampleapps.zip

.NET Framework 4.5 があれば動きます。たぶん。
Windows 8.1 Pro 以外での動作確認は取ってません!

まとめ

というわけで、Windows 8.1 の便利機能 “Per-Monitor DPI” の解説と、なぜか対応していない WPF アプリで自前で対応する方法の紹介でした。

DPI 仮想化によるボケたスケーリング (救済措置) は、「画面解像度がディスプレイの適正解像度と合っていない状態で使っている」ような気持ち悪さがあり、私は到底我慢できない… ので、なら自分で対応してしまおう、という。

せっかくいい機能なので、もうちょっとちゃんと対応してほしかった…
Windows 8.2 (?) に期待。

記事の内容やサンプル コードに関するご指摘、ご質問等は、この記事のコメントか Twitter までお願いします。

それでは、よい P/Invoke ライフを。

Room metro Tokyo #2 で LT しました

ご無沙汰です (死 艦これにはまりすぎました。。。


10/12 に開催された めとべや東京勉強会 #2 にて LT させて頂きました。 内容は 前回 の続きで、Windows 8.1 RTM 版において Per-Monitor DPI がどうなったのかと、その WPF での対応方法のお話です。

残念ながら Windows 8.1 RTM でも WPF アプリケーションは Per-Monitor DPI 非対応 (というか explorer.exe ですら非対応) で、DPI 仮想化でボケます。

LT 中にも言いましたが、この DPI 仮想化でボケた状態というのは、画面解像度がディスプレイの適正解像度と合っていない状態で使っている (たとえば、1920 x 1080 のディスプレイを 1366 x 768 で使ってる) ような気持ち悪さがあるので、私は到底我慢ならないのです。

モニターごとに DPI が設定されるのは待ち望んでいた機能なだけに、かなり残念…


ということで、自前で対応してしまおうという試み。 P/Invoke 祭りですが、現在のモニターの DPI 値と、DPI が変わったタイミングは得られるので、ScaleTransform で Window の Content ごとスケーリングすればそれっぽく見えるでしょう、というものです。 LT でデモしたサンプルアプリは、バグを直したら公開します。 サンプル アプリ (と、ついでに Per-Monitor DPI の解説記事) を公開しました! Windows 8.1 で加わった Per-Monitor DPI と WPF での対応方法

他にうまい実装方法がありましたら、ぜひご教示いただきたく!

Visual Studio 2012 のような光るウィンドウを作る (再)、そして WPF での高 DPI 対応

以前、Zune ライクなウィンドウを作成する 投稿と Visual Studio 2012 のような光るウィンドウを作成する 投稿をしましたが、その内容のアップデートになります。先にこれらの記事を読んで頂けると嬉しいです。

今回は、主に WPF における DPI 対応のお話です (あまり需要がない)。
そもそも DPI って何ぞ? という方は、先日の勉強会の資料 もお読み頂けるといいかも。

何が足りなかった?

以前の投稿で足りていなかったもの、それはズバリ、高 DPI 対応です。
その他、GitHub 上で公開しているコードでは、スクリーン座標がマイナス値になったときに正しく表示されない不具合などもあったり。

ついでに、コードの見た目が非常によろしくない実装だったので、この辺も何とかしたいなぁと。
SS130721222737KD

WPF での高 DPI 対応

先日の勉強会 にて、今後デスクトップ アプリケーションにおける高 DPI 対応は必須だ~などとお話させて頂きましたが、自分のコードが対応していなかったという体たらく。

非対応でしたので、例えば DPI 125 % 環境で実行すると、こんな残念な結果になってしまいます (GlowWindow の位置がズレてる)。
SS130721192356KD

そもそも WPF は、デバイス非依存ピクセル (DIP) という単位で表現されており、この DIP はデバイスの DPI 設定に関わらず「1 DIP = 1/96 インチ」と定義されています。そのため、WPF では DPI を意識せずに UI を実装することができ、高 DPI 環境では DPI 設定と一致するように自動的にスケールされて表示されます。
wpf-dpi

この辺は、MSDN の WPF の概要ページ にも「解像度およびデバイスに依存しないグラフィックス」という記述がありますね。
このように、通常 WPF では自動的にスケールされるため、特に高 DPI 対応をする必要がありません。

しかし、それはデバイス非依存ピクセルによって表現される範囲であり、例えば Win32 API などを使用してデバイス非依存ピクセルと異なる単位の値を扱った場合、きちんと DPI 対応のための計算をする必要があります。

今回の「Visual Studio のような光るウィンドウ」もそれで、Win32 API を使用して SetWindowPos 関数などを使用しているため、デバイス非依存ピクセルから物理座標への変換をしなければなりませんでした。
上の画像で、四辺の光る効果がズレているのは、この変換における DPI 計算を怠ったためです。

対応方法 1

単純にスクリーン座標からクライアント座標に変換するだけなら、Visual クラスの PointFromScreen メソッドだけ大丈夫です (その逆も)。

Visual.PointFromScreen メソッド (System.Windows.Media)
Visual.PointToScreen メソッド (System.Windows.Media)

例えば、WPF でウィンドウ メッセージを処理するとき。HwndSource.AddHook メソッドに追加するウィンドウ プロシージャを実装すると思いますが、lParam で渡ってくるスクリーン座標 (物理ピクセル値) をコントロール内のローカル座標 (デバイス非依存ピクセル値) に変換するときは、上記のメソッドを使うだけで自動的に DPI 計算されます。

対応方法 2

上記以外で、Win32 API を叩くときなど、座標やサイズの DPI を自力で計算しなければならないときは、以下のようなコードで対応しましょう。

CompositionTarget クラスの TransformToDevice プロパティで、DPI 倍率を取得できます。DPI 100 % 環境なら 1.0、DPI 125 % 環境なら 1.25、のような倍精度浮動小数点数で返ってくるので、上記の GetDpiScaleFactor 拡張メソッドではそれを Point 構造体に格納して返しています。

DPI 対応に必要なコードは以上ですので、あとは必要な箇所で DPI 倍率を掛けてやれば OK です。

例えば、WPF (デバイス非依存ピクセル値) の数値から、Win32 API に座標とサイズ (物理ピクセル値)を投げるシーンなど。こんな感じで。

wpfXxx はデバイス非依存ピクセル (96 dpi 固定) の値です。そこに DPI 倍率を掛けて、deviceXxx (物理ピクセル値) に変換しています。P/Invoke で Win32 API を叩く場合は物理ピクセル値が必要ですので、上記のようなコードになります。

サンプルなど

というわけで、上記のような DPI 対応を実装した Visual Studio 2012 のようなウィンドウを、以前の投稿で公開したソースを修正する形で、GitHub で公開しています。

Grabacr07/MetroRadiance

ソリューション内の VS2012LikeWindow2 プロジェクトがそれです。

なお、実行する際はソリューションのコンテキスト メニューから [NuGet パッケージ復元の有効化] メニューを選択するのをお忘れなきよう。

DPI 125 % 環境で実行してもこの通り、ズレたりしません。
SS130722000640KD

ついでにその他いろいろ

おまけ的な。WPF の DPI 実装を見に来た方は読み飛ばして頂いて構いません。

修正ついでに、Visual Studio っぽいサイズ変更コントロール (ウィンドウ右下のやつ) を作ってみたり。もちろん Path です。 標準の ResizeGrip よりこっちのがかっこいいんですよね (※あくまで個人の感想です)。

SS130722012339KD

上記コードを App.xaml か Themes/Generic.xaml などに張り付け、

のように ContentControl を配置すれば Visual Studio の ResizeGrip の見た目ができます。なお、GitHub 上のコードでは ResizeGrip コントロールを作成し、実際にリサイズ操作とカーソル変更をしています。興味あればそちらも是非ご覧くだし。

あと、以前の「ポリモーフィズム? なにそれ美味しいの?」と言わんばかりのカオスな実装を改め、GlowWindowProcessor なる抽象クラスを作成し、その派生クラス (GlowWindowProcessorLeft, GlowWindowProcessorRight, …) で上下左右の GlowWindow の座標計算をさせるようにしたり。

などなど、細かい修正等も加えた Visual Studio 2012 のような光るウィンドウは以下に (再掲)。

Grabacr07/MetroLikeWindow

まとめ

というわけで、WPF における DPI 対応。方法は 2 つ。

  • Visual.PointFromScreen (または PointToScreen) メソッドを使用
    スクリーン座標 (物理ピクセル値) からコントロール内のローカル座標 (デバイス非依存ピクセル値) に変換するとき。
  • PresentationSource.CompositionTarget.TransformToDevice プロパティから DPI 倍率を取得
    Win32 API を叩く際、WPF (デバイス非依存ピクセル値) の数値から座標やサイズ (物理ピクセル値) を算出しなければならないとき。

でした。

ご活用ください。

投稿内容に間違い等ございましたらコメントや Twitter 等ご指摘ください ><

デバイスがデジタイザー入力に対応しているかどうかを調べる

またまた Windows デスクトップ (WPF) のお話です。

先日の めとべや東京勉強会 にて、デスクトップ アプリのタッチ エクスペリエンス的な話を少しだけさせて頂きましたが、タッチ デバイスでの操作のためにタッチ向けの UI を用意するのが理想です (Office のタッチ モードのようなやつ)。

そこで、実行中のデバイスがタッチ デバイスかどうかを調べたい場合があります。タッチ デバイスであれば、それ専用の UI に切り替える、といったことができたり。


デスクトップ アプリの場合は user32.dll の GetSystemMetrics 関数 で、引数に SM_DIGITIZER を指定すると取得できます。この関数の .NET ラッパーである SystemParameters クラス から取ってこられないものかと期待したのですが、現時点では SM_DIGITIZER にマップされるプロパティは提供されていないようです。

ちなみにストア アプリの場合は、TouchCapabilities クラス楽に取得 できるようなのですが、生憎デスクトップからは使用できない API ですのでこの方法も使えず。

つまり… P/Invoke です!
これ以外の取得方法をご存じの方いらっしゃいましたら教えて頂きたく。。。

というわけで、GetSystemMetrics 関数を C# から使用するためのコードを以下のように記述します。
SM_* 定数は他にもたくさんありますが、今回はこの 2 つしか使用しません。

MSDN より抜粋。

入力デジタイザーの機能を照会するには、GetSystemMetrics 関数を使用して、SM_DIGITIZER の nIndex 値を渡します。GetSystemMetrics は、デバイスの準備ができているかどうか、デバイスがペンまたはタッチをサポートしているかどうか、入力デバイスが統合デバイスと外付けデバイスのどちらであるか、およびデバイスが複数入力 (Windows タッチ) をサポートしているかどうかを示すビット フィールドを返します。

関数の戻り値としてデバイスのデジタイザー対応状況を表すビットフィールドを得られます。そこで、次のような列挙型を定義しました。

これらを利用し、以下のような Digitizer クラスを用意します。

GetDigitizer メソッドで、Digitizer クラスのインスタンスを生成すると共にデジタイザー対応状況を照会する感じ。nIndex に SM_DIGITIZER を指定してデジタイザーの対応状況を取得し、対応していれば更に SM_MAXIMUMTOUCHES を指定してタッチの点数を取得しています。

こんな感じで使えます。べんり! (熱い自画自賛)

なお、GetSystemMetrics 関数で SM_DIGITIZER と SM_MAXIMUMTOUCHES がサポートされているのは、Windows 7 または Windows Server 2008 R2 以降となります。それ以前の古の OS でこの API を叩いても 0 (NotSupported) しか返ってきませんのでご注意ください。当然 Windows 8 ではちゃんと動きました。

上記コードをコピペすればすぐにチェックできるようになると思いますが、WPF で サンプル アプリ も作りました (GitHub で公開済み)。

以下は、タッチ デバイスのないデスクトップ PC で実行したときのもの。 SS130710012903KD

そして、以下がタッチ デバイス (Acer ICONIA W7) で実行したときのもの。 SS130710012740KD  
10 点タッチの情報がしっかり取得できています。SS130710012923KD

Room metro Tokyo #1 資料公開

めとべや東京勉強会 にでセッションさせて頂きました。

「デスクトップ アプリがこの先生きのこるには」 ぎなた読み (弁慶読み) といわれる由緒あるネタです。すみません。

これまでデスクトップ アプリ中心に開発していたので、Windows 8 + タブレット (+ ストアアプリ開発) 全盛というこの時代において、デスクトップ アプリを作るときに何を気を付けたらいいか、という話をする …つもりでした。

DPI について掘り下げて調べていたら (といっても Micorosoft の英語ドキュメント泣きながら読んでいただけですが) いろいろ深かったのと、Windows 8.1 で DPI 周りの新機能が追加されたのもあり、今回はほとんど DPI のお話で終わってしまいました (挙句時間オーバーして申し訳ございませんでした)。

次はもうちょっとタッチ エクスペリエンスとそのノウハウに寄った話したいなぁ。

途中で Blend で Path を使ったベクター画像作成のデモをさせて頂きましたが、そちらに関する詳しい情報は 以前の記事 をご覧いただければと思います。

ありがとうございました。


今回はいつもより緊張しました。。。 Microsoft 大西さん + 7 月受賞&更新の MVP の方々 4 名 (皆さんおでとうございます) の後に出るという罰ゲーム試練的なものが。

大変勉強させて頂きました!

Windows 8.1 Preview きた!

きました。

サンフランシスコで Build 2013 が開幕しましたが、同時に Windows 8.1 Preview や Visual Studio 2013 Preview などが公開されています。

Windows 8.1 Preview – Microsoft Windows
Visual Studio 2013 Preview Downloads | Microsoft Visual Studio

というわけで、さっそく Windows 8.1 Preview を ICONIA W7 にインストールしましたので、ざっと触ってみた感じなどをレポート。

ダウンロードとインストール

Windows 8、Windows 8 Pro、Windows RT、すべて 8.1 へアップデートできます。
ただし、いくつかの PC ではサポートされていない ようですので、ご注意ください。

上記のリンクから [今すぐ入手] –> [更新プログラムの入手] を辿り、まず更新プログラム (KB2849636) をダウンロードしインストールします。
SS130627061525KD  SS130627061532KD

これで、Windows ストアから 8.1 Preview をダウンロードできるようになります。ストアにアクセスし、アップデートしましょう。
SS130627013249KD  SS130627022936KD

なお、この後の再起動を含め、結構時間がかかります。
この段階で失敗する方は、@daruyanagi さんの記事を確認してみるとよいかも。

Surface RT に Windows RT 8.1 Preview をインストール…できなかった → 解決 – だるろぐ

ISO イメージは?

上記の方法はアップデートによるインストールですが、ISO からのインストールもできます。現時点 (2013/06/27 06:20) では、MSDN Subscription / TechNet 契約者のみが ISO イメージをダウンロードできるっぽい?

ちなみにですが、 

  • Windows 8 は Windows 8.1 Preview
  • Windows 8 Pro は Windows 8.1 Pro Preview
  • Windows RT は Windows RT 8.1 Preview

…という名称のようですね。ややこしー

2013/06/28 18:00 追記

以下の URL から ISO イメージがダウンロードできるようになっています。

Windows 8.1 Preview ISO ファイル – Microsoft Windows

まずはスタート画面

Windows 8.1 Preview のスタート画面。
SS130627032038KD

タイルの設定

まず、タイル サイズのバリエーションが増えました。

  • 大 (新規追加。上の画像の天気アプリ。設定できるアプリとできないアプリがある)
  • 広い (Windows 8 での「大きくする」のサイズ。上の画像のデスクトップなど (この邦訳はどうなの?))
  • 中 (Windows 8 での通常のサイズ。上の画像の Internet Explorer など)
  • 小 (新規追加。中の 1/4 のサイズ。見たところ全アプリで設定できる?)

タイルを下にスワイプするのではなく、タイルをホールド (普通に右クリックメニュー出す感覚) でタイルの設定ができます。タイル サイズは上記の通りですが、タイル群のグループ名なども編集しやすくなっています。また、(これは実際に触ってみて頂きたいですが) タイルの移動もしやすくなってます。複数選択してまとめて移動したりとか。
また、デスクトップ アプリのタイルは Windows 8 はグレーなタイルでしたが、8.1 ではアイコンの色に応じてカラフルになりました。右端の Visual Studio や Office 2013 のアイコンがそれです。
SS130627042224KD
SS130627061542KD

背景やアクセント カラー

スタート画面の背景や、チャームの背景、アクセントの色を細かく変えられます。スタート画面から設定チャームを開き、[パーソナル設定] を開きましょう。 従来のような背景のほか、デスクトップの壁紙と同じ画像を指定することもできるようになっています。
SS130627042234KD
SS130627042244KD

すべてのアプリ

すべてのアプリへアクセスするには、画面を上にスワイプします。スタート画面の下からアプリ画面が出現します。これは便利。
SS130627034351KD

プリンストール アプリ

プリインストールされているアプリがいくつか増えています。

 

このほかにも新しいアプリがいくつか。
新規アプリ (おそらくインストールされて 1 度も起動されていないもの。昔で言う「強調表示」?) は [新規] という表示が出ますね。
SS130627045465KD

50:50 スナップ

事前の情報どおり、画面の真ん中で分けてスナップできるようになっています。
SS130627045475KD

どちらがフォーカス (?) を持っているのかわかるよう、グリップ部分に線が入りました。上の画像では天気アプリの方がフォーカス (?) を持ってます。

ある程度任意のサイズでスナップできるようになった感じが。
SS130627045495KD

スナップ中、アプリ側でどのように認識できるかなどの API 周りは未確認です。これから。。。

デスクトップ

続いてデスクトップ。NT カーネル バージョンは 6.3?
SS130627034341KD

はい、ご覧の通りスタート ボタンが復活しました。押すとスタート画面が表示されます (スタートメニューではない)。今のところ設定画面等から消す方法は見つけておりません… (ちなみに、Build 2013 の Keynote 中にスタート ボタンに言及したシーンでは拍手が起きました。みんな望んでるんですかね?)

サインイン時にスタート画面ではなくデスクトップに移動できるようにはなったようです。タスク バーで右クリック –> [プロパティ] から上の設定画面を出し、チェックを入れるだけ。

 

エクスプローラーの左側のペイン、[コンピューター] だったものは [PC] になり、[フォルダー] と [デバイスとドライブ] のふたつが出るように。謎。
なお、左側のペイン内で右クリックしたときのメニューも出ていますが、ご覧のとおりライブラリが既定で非表示になってます。結構使ってたんですが…
SS130627061552KD

また、インストール時にも有効にするかどうかを訊かれますが、SkyDrive との連携機能が組み込まれた模様。SkyDrive for Windows Desktop にあたるものが最初から入っており、左側のペインの [SkyDrive] からアクセスできるようになっています。

PC 設定の変更

他に気付いた点として、スタート画面から開く [PC 設定の変更] がだいぶ強化された模様。下にいくつかスクリーンショットを。いろいろ設定できるようになっており、好感度あっぷ。
まだ試していませんが、スタート画面のタイルやタイルのレイアウトも複数デバイス間で同期できるようになった?
SS130627045505KD  SS130627045515KD
SS130627045525KD  SS130627045535KD

そのほか、DPI スケーリングの指定方法が変わりました。
SS130627072025KD

なんと、外部ディスプレイを接続したとき、それぞれのディスプレイで最適な DPI となるように自動的に切り替えてくれます。ウィンドウを、タブレット本体 <–> 外部ディスプレイ と行き来させてみるとよくわかりますが、ウィンドウのサイズが勝手にスケーリングされます。いい感じ (Build 2013 の Keynote でもデモがありました)。

インストール容量

ICONIA W7 (64 GB) の Windows 8 (無印) に Office 2013 や Visual Studio 2012 をインストールした (= 8.1 アップデート前の) 状態で、空き容量が約 17 GB でした。
そこから Windows 8.1 Preview をストア経由でアップデート インストールしたところ、空き容量はなんと約 21 GB に。中身減った (Preview 版ですし?)。

    • *とりあえず、出勤前に気付いてまとめられたのは以上になります。

スタート画面や PC 設定の変更など、洗練されてきた感じがして好印象です。RTM 待ち遠しいですね。 このほか、Internet Explorer 11 や Visual Studio 2013 など目玉がたくさん。要チェックです!

イメチェンしました

ブログさっぱり更新しないのに、外観だけ変えて遊んでるという体たらく!

だいたい 1 年くらい前、WordPress を初めて触った頃ですが、テーマの CSS を直接編集して外観を弄っていました。その方法だとテーマ側でバージョンアップされる度に編集しなおしという何とも非効率的でお粗末な話で、何とかならないかと調べたところ子テーマなる機能の存在を知ります (それはずいぶん前)。 子テーマで外観作り直したいなー、と思いつつも暫く放置しておりましたが、最近ようやく作る時間を得たので、思い切ってイメチェンと相成りました。


子テーマは、元のテーマのファイルを変更せずに、任意のカスタマイズができる便利機能です。 元のテーマを直接編集すると、アップデートによりカスタマイズが失われますが、子テーマでカスタマイズすればアップデートの影響を受けません。よって、カスタマイズが失われるのを嫌ってアップデートを躊躇したりする必要はなくなります (バグ修正などの面から、できるだけアップデートしたいし)。

子テーマを作るのは簡単で、/wp-content/themes/{任意の子テーマ名}/style.css を作成し、以下のように記述します。

重要なのは Template の行です。ここで、元のテーマのディレクトリ名 (テーマ名ではなくディレクトリ名です。/wp-content/themes/{この部分がテーマのディレクトリ名}/) を指定します。 最後の行で元のテーマの CSS を読み込んでいますが、これをやらないとベースとなる元のテーマの外観が再現されないので、お忘れなきよう。

あとは、好みの外観になるように、任意のスタイルを書き加えていくだけ。例えば以下の例では、このサイト左上のタイトル “grabacr.nét” の部分を Segoe UI Light に変更し、色やサイズを調整しています。

作成した子テーマが正しく認識されれば、WordPress 管理画面のテーマ一覧に表示されるようになります。[有効化] をクリックし、子テーマを有効にしましょう。 なお、子テーマがテーマ一覧に出てこない場合、元のテーマの指定方法や子テーマの配置の間違い、(あるいは、文字コードの問題) などの原因が考えられます。

子テーマについての情報は Web 上でも充実しているので、これから導入を検討される方は Google 先生に訊いてみるといろいろな情報が得られると思います (丸投げ)。


サイトをご覧の通り、タイトルやウィジェットのヘッダーなど全体的に Segoe UI にしています。Segoe UI かっこいい。Segoe UI まじかっこいい。 (※あくまで個人の感想です) Windows 8 や Windows Phone の UI をよく目にするので、角丸な UI よりもエッジの鋭い UI の方がかっこよく映るんですよね。あと Segoe UI。 Segoe UI に合うかっこいい日本語フォントまだー?

というわけで、(まだ調整中ではありますが、) 英字も Meiryo ベースで角丸だった以前よりは、だいぶスタイリッシュになったのではないかなーと。

Before After
 grabacr.net ver.1  grabacr.net ver.2

そんなことよりコンテンツを充実させろって話ですね、わかります。

Room metro #15 資料公開

3/30 に開催された Room metro #15 で LT させて頂きました。

Room metro #15 告知ページ http://metrostyledev.net/index.php/event/20130330/
当日のツイートまとめ http://togetter.com/li/480098

開催 2 日前に何気なくこんなツイートをしたところ、

その日のうちにはこのようなご連絡を頂き、

あっと言う間に決まってしまいました。開催直前にも関わらず時間調整して頂き、本当にありがとうございました。。。

ネタは、このブログの前回の投稿 XAML でクラウディアさんを描いてみました の内容になります (といいますか、この LT に向けて書いた記事なのでした)。

デモで実際にお絵かきするのがメインでしたので、資料はお読みいただいても殆ど意味がありません!
デモの内容はこんな感じ。

  • XAML でクラウディアさんを描いてみました で使用した Twitter Bird のお絵かき実演
    -> 2 分くらいで描けました。うまくいった。
  • XAML クラウディアさんのデモプログラム (デスクトップ WPF)
    -> DynamicResource で色を差し替えたり、サイズ変更したり。

デモプログラムについては、後日 github などで公開しますん。もう少々お待ちください。

XAML でクラウディアさんを描いてみました

なにやらタイトルだけで既に出オチ感が。。。

もちろん、これら素晴らしい記事に触発されて書きました。

PowerPoint でクラウディアさんを書いてみました | SE の雑記
PowerPoint でクラウディアさんを私も描いてみました
PowerPointで初めてのお絵かきしてみた

実は、以前から私の Twitter アイコンも PowerPoint で作っていたりしたのですが。

最近の PowerPoint お絵かきの流れ、これは PowerPoint アイコン勢として何もしないわけにはいかない… などと思いつつも、同じ PowerPoint ネタで投稿してもおもしろくないなぁ、と。

で、なに使って描くの?

私は XAMLer (自称) です。
XAML で絵、描けないかな…

いや、Blend さえあれば…?

Path のススメ

System.Windows.Shapes 名前空間 には、XAML で使用できる図形クラス (直線、四角形、多角形、楕円、などなど) が定義されています。その中でも、Path クラス を使うと、自由曲線を描画できます。
もちろん、PowerPoint の場合と同様に、トレース元の画像があると楽に作れます。

※以降、この投稿では Expression Blend 4 を使用していますが、Blend for Visual Studio 2012 でも同じ操作が可能です。

Blend の [ペン ツール] を選択します。
PowerPoint の曲線ツールとは使い勝手が異なり、PowerPoint のフリーフォーム ツールと曲線ツールを組み合わせたような動きをします。ひとまず曲線にすることは考えず、頂点をトレースする形で点を打っていきましょう。
SS130328042446KD
SS130328052535KD

お題は Twitter Bird。頂点のみトレースするとこんな感じに。
SS130328054423KD

なお、Path オブジェクトを選択した状態で Path オブジェクトの線の上でクリックすると、新しい頂点を追加することができます。同様に、頂点の上でクリックすると、その頂点を削除することができます。
SS130328060929PT
SS130328060934PT
SS130328060940PT

ここから曲線を作ります。[個別選択ツール] の出番です。
Path オブジェクトに対しては、それぞれ下の表のような操作ができます。
SS130328061545KD

線をドラッグ 線と両端の頂点のみ移動
SS130328062219KD
頂点をドラッグ 頂点のみ移動
SS130328062229KD
Alt キーを押しながら
線をドラッグ
曲線の作成
SS130328062917KD
Alt キーを押しながら
頂点をドラッグ
曲線の作成
SS130328062905KD

個人的には、3 番目の「Alt キーを押しながら線をドラッグ」をよく使います。
トレース元の画像に重なるように、Alt キーを押しながら線をドラッグすることで、それっぽい曲線を作ることができます。
また、2 番目の「頂点をドラッグ」も、トレース元の画像との微妙なズレを修正したりするのによく使います。
SS130328063633KD

単純に曲線にしただけでは、頂点からの角度が合わない場合があります。その場合、頂点から伸びる接続ハンドルを調節し、好みの角度に合わせましょう。
SS130328064419KD  SS130328064510KD

というわけで、あっという間にできました Twitter Bird。手順をまとめると、次のような感じに。
この程度なら 10 分かかりません。
1. [ペン ツール] で頂点をトレース
2. [個別選択ツール] で頂点の位置を微調整しながら、Alt キーを使い直線から曲線を作成
3. 頂点の接続ハンドルを使い、曲線の角度を微調整
SS130328065158KD

個人的には、PowerPoint でお絵かきするより Blend でお絵かきする方が楽で、好きです。おすすめ。

Path の何がイイかというと

Path に限らず、System.Windows.Shapes 名前空間 で定義される図形オブジェクトはすべてベクター形式です。ラスター形式のビットマップ画像などと違い、拡大・縮小してもボケたりギザギザになったりしませんし、複数の Path オブジェクトから 1 つの複合 Path を作ったりもできたり。

Blend があれば、Path を使って簡単な図形を自前で用意できます。
例えば、私が今こっそり作っている Twitter クライアントでは、Retweet、Fav などのアイコンをすべて Path で作っているので、拡大して表示してもこのとおり。
SS130328071143KD SS130328071205KD

また、四角形や楕円を組み合わる程度の図形なら、[ペン ツール] で自分で描かずとも作れます。
PowerPoint でいう [図形合成] 機能と同じものです。

まず、適当な図形を 2 つ用意しましょう。今回は Ellipse クラスと Rectangle クラスで。
SS130328072405KD  SS130328072424KD
Ctrl キーを押しながら、これらの図形を 2 つ同時に選択します。選択したら、そのまま図形の上で右クリックし (もしくは [オブジェクト] メニューを開き)、[結合] メニューを開きます。それぞれの結果は、下の表のとおり (ちなみに、これで作成る新しい図形は Path オブジェクトです)。
SS130328072914KD

合算 SS130328073123PT
除算 SS130328073137PT
交差 SS130328073147PT
減算 SS130328073155PT
重複部分を除外 SS130328073255PT

クラウディアさん

上記 Twitter Bird を描いたときと同じ手順をひたすら繰り返し、クラウディアさんを描きました。単にオブジェクトの量が多いだけで別段特殊なことはやっていないので、細かい手順については省略します。

SS130328083346KD

先ほど Path の利点として「拡大縮小に強い」ことを述べましたが、このクラウディアさんも例外ではありません。複数の Path オブジェクトを 1 つの画像として扱うようなケースの場合、Viewbox クラス を使いましょう。以下のように使用します。

これで、クラウディアさんをキレイに拡大・縮小できます (= 拡大してボケたり、縮小してギザギザになったりしません)。

Silverlight 5 が動作するブラウザーで御覧の方は、以下に Path で描画されたクラウディアさんが表示されるはずです。拡大・縮小などしてみてください。

まとめ

クラウディアさんを描きたかったわけではなく、Path を使って絵を描くのは簡単なんですよ、ということが言いたかったわけです。自分で開発するアプリで使うちょっとしたアイコンなどは、Path でちょろっと描けば事足りてしまうことが多いですね。

ちなみに、PowerPoint で描いた図を XAML に変換する方法もあります。私の場合ですと、最終的に XAML を吐きたいというよりも Blend 使って XAML で描く方が好きだったりしますが。上記の例、メガネの On/Off のようなプログラマブルにする要件があるのならば、PowerPoint だけでなく Blend でこういった図を実装する選択肢もあるのではないでしょうか。