アカウント名:
パスワード:
え、違うの? Win32デスクトップアプリに一本化されるの?
せっかく、全画面だけじゃなく、ウィンドウ表示も出来るようになって、High-DPI環境でも文字が汚くなく・・・って思ってたのに逆方向に行ってビックリですね。
いつものMicrosoftだろう。毎回グダグダで部署ごとに好き勝手やる。んでブラウザ版はどーなんの?
ブラウザ版があるからモダンUI版を廃止するんじゃないかな?EdgeはモダンUIだからそれでブラウザ版を使えと。
IEが消えた段階でブラウザ版に統一されるかも。
遊ぶときだけ使えればいいゲームのようなアプリならともかく、Skypeのようなリアルタイムコミュニケーションツールは、常時起動して待ち受け状態にしておく必要があり、ブラウザアプリにするには最も不適切な類のアプリだ。
着信待ち受け状態を続けるには、ブラウザで常にそのページを開いていなければいけないなんて、使いにくすぎるだろ。ブラウザのタブなんて、沢山開きすぎて重くなったときに一気に閉じたり、ブラウザ毎再起動するなんてことはしょっちゅうやるもんだ。その度に再度Skypeサイトにアクセスしてログインしなければならなかったり、あるいはうっかりしてブラウザでサイトにアクセスしておくのを忘れてしまったりと面倒くさいことこの上ない。
そこでWeb Platform API [it.srad.jp]の出番です。
グーグルChromeはウインドウを閉じても裏で動くようになってますね。この方法を使えば何の問題もないでしょう。
> Skypeのようなリアルタイムコミュニケーションツールは、常時起動して待ち受け状態にしておく必要があり、
だったらConnected Standbyが使えるモダンアプリの廃止はなおさら退化じゃないですかねえ。http://itpro.nikkeibp.co.jp/article/COLUMN/20121130/441221/ [nikkeibp.co.jp]
ん?taskmanager見ても、Chromeの全ウィンドウを閉じると、タスクリストからきれいさっぱり消えるけど。なんか変なもの入れてない?
>グーグルChromeはウインドウを閉じても裏で動くようになってますね。
ただし一度は立ち上げる必要がある。
Chromeのバックグラウンドページで動くアプリってChromeのAPIを使って作られるアプリだよね。そういう特定のブラウザでしか動かないものになるなら、わざわざWebアプリにする意味が無くない?
わざわざIEでしか動かないWebアプリがどれだけ作られたと思ってるの?最近は社内アプリでもサポート対象がChromeという案件が増えてきた。Firefoxという案件すらあった。古いIEで動かすようなノウハウを持った技術者の確保が難しくなってるのかな。
で、MicrosoftはわざわざChromeでしか動かないSkypeを作りたいってか?w
それを言ったらそもそもMSは今後も絶賛Win32アプリを作っていきたいと?
ではMSはやりたくないことをやっていると?
> High-DPI環境でも文字が汚くなく
それは基本的にアプリの手抜きのせいだがSkypeのデスクトップアプリですらそうならWin32でのHigh DPI対応ってよっぽど面倒なんだな
そんな簡単じゃないです。HiDPIにはnot DPI aware/system DPI aware/Per-Display DPI awareの3種類があります。後に書いた方が、よりHiDPI対応の度合いが高いといえます。
簡単にPer-Display DPI awareにするには、現状ではストアアプリ(win10からはUWP)しかありません。system DPI awareならWPFにすることで可能ですが、.NETでもWindows Formsの対応は微妙な段階です。Win32では、関連するwindows messageへの対応とマニフェストへの記述が必要です。詳しくは「MDD DPI」とかで検索してみてください。
また、画像リソースがある場合は、DPIに(ある程度)あわせた画像を用意しないと悲しいことになりやすいのが現実です。
これら全てを行うのは負担が高いので、ぶっちゃけnot DPI awareにしてwindowsの自動調整に頼る方が楽です。まあ、それが「フォントが汚い」になるんですが。
メニューとかのサイズが常にプライマリモニタのDPIでスケールされるというWindows側の問題もある。GetSystemMetricsにモニタを識別できるような引数が存在しない(そして当然ながらすべてのWin32アプリはシステムメトリックがモニタによって変化することなど想定していない)という根本的な問題のせいだから解決の見込みがない。Windows 10でGetSystemMetricsForMonitorが追加されたという話も聞かないからWin32アプリのPer-monitor DPI対応はあまり現実的じゃない。
GetSystemMetrics()は16bit時代からの古いAPIですし将来の拡張も無いでしょう。GetDPIForMonitor()というAPIが追加されたようです。MSDNライブラリをHigh DPIで検索すると出てくると思います。
ただ、いずれにせよ自前でスケーリングするのは面倒くさいとは思います。
これからは高密度もサポートしなきゃって思った時に、きっちり設計してたらこんな複数段階のキモい API にならんかったのでは。。
互換性の為に残されている位置付けのAPIにそう言われましても
既存のSkypeで両方できるようになるかたちになります
今回廃止されるメトロスタイルのってできることほんと簡易版で使い物にならなかったので
> 既存のSkypeで両方できるようになるかたちになります
それはデスクトップ版がUWPアプリとしても動くと言うこと?
僕の場合はアカウント統合必須だった時点で使い物にならんかったです。
いや、ユニバーサルアプリ版Skypeが今後の主力だよ。Win10より古いOSには既存のデスクトップ版Skypeがあてがわれただけで。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
はいはいUWPアプリUWPアプリ (スコア:0)
え、違うの? Win32デスクトップアプリに一本化されるの?
Re: (スコア:0)
せっかく、全画面だけじゃなく、ウィンドウ表示も出来るようになって、High-DPI環境でも文字が汚くなく・・・って思ってたのに逆方向に行ってビックリですね。
Re: (スコア:0)
いつものMicrosoftだろう。毎回グダグダで部署ごとに好き勝手やる。
んでブラウザ版はどーなんの?
Re: (スコア:0)
ブラウザ版があるからモダンUI版を廃止するんじゃないかな?
EdgeはモダンUIだからそれでブラウザ版を使えと。
Re: (スコア:0)
IEが消えた段階でブラウザ版に統一されるかも。
Re:はいはいUWPアプリUWPアプリ (スコア:1)
遊ぶときだけ使えればいいゲームのようなアプリならともかく、
Skypeのようなリアルタイムコミュニケーションツールは、常時起動して待ち受け状態にしておく必要があり、
ブラウザアプリにするには最も不適切な類のアプリだ。
着信待ち受け状態を続けるには、ブラウザで常にそのページを開いていなければいけないなんて、使いにくすぎるだろ。
ブラウザのタブなんて、沢山開きすぎて重くなったときに一気に閉じたり、ブラウザ毎再起動するなんてことは
しょっちゅうやるもんだ。
その度に再度Skypeサイトにアクセスしてログインしなければならなかったり、あるいはうっかりしてブラウザで
サイトにアクセスしておくのを忘れてしまったりと面倒くさいことこの上ない。
Re: (スコア:0)
そこでWeb Platform API [it.srad.jp]の出番です。
Re: (スコア:0)
グーグルChromeはウインドウを閉じても裏で動くようになってますね。
この方法を使えば何の問題もないでしょう。
Re: (スコア:0)
> Skypeのようなリアルタイムコミュニケーションツールは、常時起動して待ち受け状態にしておく必要があり、
だったらConnected Standbyが使えるモダンアプリの廃止はなおさら退化じゃないですかねえ。
http://itpro.nikkeibp.co.jp/article/COLUMN/20121130/441221/ [nikkeibp.co.jp]
Re: (スコア:0)
ん?taskmanager見ても、Chromeの全ウィンドウを閉じると、タスクリストからきれいさっぱり消えるけど。
なんか変なもの入れてない?
Re: (スコア:0)
>グーグルChromeはウインドウを閉じても裏で動くようになってますね。
ただし一度は立ち上げる必要がある。
Re: (スコア:0)
Chromeのバックグラウンドページで動くアプリってChromeのAPIを使って作られるアプリだよね。
そういう特定のブラウザでしか動かないものになるなら、わざわざWebアプリにする意味が無くない?
Re: (スコア:0)
わざわざIEでしか動かないWebアプリがどれだけ作られたと思ってるの?
最近は社内アプリでもサポート対象がChromeという案件が増えてきた。Firefoxという案件すらあった。古いIEで動かすようなノウハウを持った技術者の確保が難しくなってるのかな。
Re: (スコア:0)
で、MicrosoftはわざわざChromeでしか動かないSkypeを作りたいってか?w
Re: (スコア:0)
それを言ったらそもそもMSは今後も絶賛Win32アプリを作っていきたいと?
Re: (スコア:0)
ではMSはやりたくないことをやっていると?
Re: (スコア:0)
> High-DPI環境でも文字が汚くなく
それは基本的にアプリの手抜きのせいだがSkypeのデスクトップアプリですらそうならWin32でのHigh DPI対応ってよっぽど面倒なんだな
Re: (スコア:0)
Win32 で既存アプリのHigh DPI 対応は、たしかに面倒くさいですけど、新規で作るならたいした手間かからないし、昨今のデスクトップアプリは、半数以上 .NET になってるとかって話なので、開発者が意識しなくてもできてたりします。
Re: (スコア:0)
そんな簡単じゃないです。
HiDPIにはnot DPI aware/system DPI aware/Per-Display DPI awareの3種類があります。後に書いた方が、よりHiDPI対応の度合いが高いといえます。
簡単にPer-Display DPI awareにするには、現状ではストアアプリ(win10からはUWP)しかありません。
system DPI awareならWPFにすることで可能ですが、.NETでもWindows Formsの対応は微妙な段階です。
Win32では、関連するwindows messageへの対応とマニフェストへの記述が必要です。詳しくは「MDD DPI」とかで検索してみてください。
また、画像リソースがある場合は、DPIに(ある程度)あわせた画像を用意しないと悲しいことになりやすいのが現実です。
これら全てを行うのは負担が高いので、ぶっちゃけnot DPI awareにしてwindowsの自動調整に頼る方が楽です。
まあ、それが「フォントが汚い」になるんですが。
Re: (スコア:0)
メニューとかのサイズが常にプライマリモニタのDPIでスケールされるというWindows側の問題もある。GetSystemMetricsにモニタを識別できるような引数が存在しない(そして当然ながらすべてのWin32アプリはシステムメトリックがモニタによって変化することなど想定していない)という根本的な問題のせいだから解決の見込みがない。Windows 10でGetSystemMetricsForMonitorが追加されたという話も聞かないからWin32アプリのPer-monitor DPI対応はあまり現実的じゃない。
Re: (スコア:0)
GetSystemMetrics()は16bit時代からの古いAPIですし将来の拡張も無いでしょう。
GetDPIForMonitor()というAPIが追加されたようです。MSDNライブラリをHigh DPIで検索すると出てくると思います。
ただ、いずれにせよ自前でスケーリングするのは面倒くさいとは思います。
Re: (スコア:0)
これからは高密度もサポートしなきゃって思った時に、
きっちり設計してたらこんな複数段階のキモい API にならんかったのでは。。
Re: (スコア:0)
互換性の為に残されている位置付けのAPIにそう言われましても
Re: (スコア:0)
既存のSkypeで両方できるようになるかたちになります
今回廃止されるメトロスタイルのってできることほんと簡易版で使い物にならなかったので
Re: (スコア:0)
> 既存のSkypeで両方できるようになるかたちになります
それはデスクトップ版がUWPアプリとしても動くと言うこと?
Re: (スコア:0)
僕の場合はアカウント統合必須だった時点で使い物にならんかったです。
Re: (スコア:0)
いや、ユニバーサルアプリ版Skypeが今後の主力だよ。
Win10より古いOSには既存のデスクトップ版Skypeがあてがわれただけで。