WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part21 [無断転載禁止]©2ch.net

Windows Presentation Frameworkについて語るスレ。

前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part20
http://echo.2ch.net/...cgi/tech/1458082648/

関連スレ
Windows 10 UWPアプリ開発
http://echo.2ch.net/...cgi/tech/1440150886/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/

Prism触ったけどなんか俺にはmoduleとかresionとかなんか取っつきにくいわ
まだlivetの方が扱いやすい
しかしlivetは更新きそうもねぇ…

おー
わんだふる
こーでぃ
んぐ

>>2
俺は一人でやっているからmoduleはほとんどつかわないな
resionは画面遷移させたりするからよく使うね
livetはオワコンってどっかで見たような気がする
MVVMパターンでコーディングしていくなら
prism一択だともう、UWP向けもあるし

WPFは定着したのか？

煽るなよクズ

WPFとUWPはコントロールを統一してほしいわ

WPFにもx:bindくださいよ・・・

WPFは実験台だったんだよ!!

>>6
質問しただけなのに煽り扱いとか草

>>9
silverlight「せやな」

>>9
WinForms「そんなバカな！？」

XAML Standard 1.0かあ

> Post specification plans include support of XAML standard in Xamarin Forms and UWP

ﾌﾌｯ

WPFにx:bindがくるの？

https://github.com/M...l-standard/issues/20

本当にどうするつもりなのやら…

XAML StandardはUWP基準でやったほうが楽っぽいけど、どうなるんだろ？

DataGridViewとDataGridとGridView・・・名前だけでも収拾つかなくなってるな

VS2015upd3のデザイナー上で突然、下記のエラーが起きたんだけどなぜこうなったか分かりますか？
{
"Version": "W.3.2.2.0",
"Guid": "6fe59b26-7383-40d5-947c-7448769a5e81",
"Type": "System.Runtime.InteropServices.COMException",
"Time": "2017/05/13 11:39:38",
"Position": "PresentationCore--->Void SyncFlush()",
"Message": "HRESULT からの例外:0x88980406",
"StackTrace": " 場所 System.Windows.Media.Composition.DUCE.Channel.SyncFlush()\r\n
〜〜〜〜〜〜
System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)"
}

自己解決です。
どうやら拡張機能である[BabeLua]をインストールしてたのが原因でした。

DataGridのRowDetailにDataGridをネストして、更にそのDataGridのRowDetailにDataGridをネストして...
という感じで多階層にデータを取り扱えないかチャレンジしているのですが、
この時、動的に生成された全てのDataGridの中から最後に選択された１つのアイテムを取得する方法ってありますでしょうか？
SelectedItemプロパティを全て同じVMのプロパティにBindしてみたのですが、思うように動いてくれず・・・。

せめてサンプルは出そうよ

高度に発達した天才はキチガイと区別がつかない

失念しておりました！下記の通りです。
※View.xaml
<DataTemplate x:Key="Expander">
<ToggleButton IsChecked="{Binding RelativeSource={RelativeSource AncestorType=DataGridRow},
Converter={StaticResource VisbilityToBoolean},Path=DetailsVisibility}">
</ToggleButton>
</DataTemplate>
<DataTemplate x:Key="ChildDataGrid">
<DataGrid ItemsSource="{Binding Children}"
SelectedItem="{Binding SelectedRowItem}"
RowDetailsTemplate="{DynamicResource Child}">
<DataGrid.Columns>
<DataGridTemplateColumn CellTemplate="{StaticResource Expander}" />
</DataGrid.Columns>
</DataGrid>
</DataTemplate>
<DataGrid ItemsSource="{Binding Items}"
SelectedItem="{Binding SelectedRowItem}"
RowDetailsTemplate="{DynamicResource ChildDataGrid}">
<DataGrid.Columns>
<DataGridTemplateColumn CellTemplate="{StaticResource Expander}" />
</DataGrid.Columns>
</DataGrid>

※VM.cs
public object SelectedRowItem{get;set;}
public ObservableCollection<Item> Items{get;set;}
※Model.cs
public class Item{
public int ItemId{get;set;}
public string ItemName{get;set;}
public List<Item> Children{get;set;}}

DataGrid(A)のItem1を選択→展開されたDataGrid(A)のRowDetail内のDataGrid(B)のItem2を選択（ここまでは理想通りにSelectedItemが拾える)
→DataGrid(A)のItem1を再度選択（この時にSelectedItemがnullでセッターに飛んでくる）
といった感じで最終的に選択されたアイテムはItem1である、となって欲しいのですが、うまく行きません。。。

Xamarin.Forms Feature Roadmap ? Xamarin Forums
https://forums.xamar...rms-feature-roadmap/

Xamarin.Forms for WPF

DataGridが大量データに弱すぎて使い物にならない。
せめてExcel並みのパフォーマンスくらい難なく出させてくれよって感じ。

いろいろ調べたけど、結局満足の行く情報も得られず。英語読めないし、日本語文献少なすぎ。
線と文字と縦横のスクロールバーを使って自前の描画をさせることも試したけど、
1ピクセルの細い線が満足に引けないって何なんだか。
見える範囲だけ線と文字を並べるのも速く無かったし。

で、WPFをメインに据えるのは諦めた。

WebBrowserでHTMLやJavaScript使う方がマシだなって思ったら、WPFのWebBrowserが
Windows FormsのWebBrowserより低機能とか、全くどうなってんだか。

WPF何とかならんのかね。。。。。。。。。。

なんかすぐにパフォーマンス的な制約にぶつかるよねWPFって
何で最初からせめてWindows Formは機能的に完全に置き換え可能なように気合いれて作らなかったのか

できるわけないだろ、常識的に考えて・・・
最近はアセンブラ経験ない奴増えてパフォーマンスに対する認識が低すぎる・・・
どういう処理が重くてどういう処理が軽いが全く認識せずコード書いてる・・・

この2017年にもなってまだアセンブラ意識してコード書かなきゃならんのかよ

むしろアセンブラの知識がいらないという発想が全く理解できない。
たぶんキミはPGに向いてない。

必死すぎワロタ

アセンブラまで行かなくても、ライブラリー類を一切使わず処理を全部基本の文法だけで書いて
パフォーマンスを自分で考える位のことは、プログラミングの勉強の一環として必要かもね。
利便性とパフォーマンスのバランス感覚を身に付けると言うか。

DataGridはWinFormsでもうんこだから。

だよねー
いつ良かったんだろ？

DataGridは入力系だから、最大でも数十行マトモに動けば問題ないと思うんだよな
数百数千行表示したければListBox使えばいいよ
Formsと違って、WpfやUwpはListBoxの表現力は高い

WPF初期リリースにDataGridが含まれてなかったのは、
Templateいじれば同等の事できるはずだから不要ってことだったのかね？

RenderTargetBitmap からメタファイルを生成するサンプルって
どこかにありますか？

WPFスレでアセンブラどうこう言ってる化石は土に埋まってろよ

百歩ゆずってCPUの動作、また百歩ゆずって機械語を意識しろなら
わからんでもないけどアセンブラはないねw

しかも正式にはアセンブラじゃなくてアセンブリ言語だしw

き〜か〜い〜の〜き〜も〜ち〜

>>39
すごい知ったかだな。普通にAssemblerもよく使われる。
書籍の題名とかほとんどアセンブラになってるだろう。
最適化の文献や機械語の勉強を一度もしたことないことがすぐ分かる。

おじいちゃんほんと申し訳ないんだけど一生懸命覚えたであろうアセンブラの知識や機械語の知識
現代では君が信じてるほど出番無いんだわ

大昔は、乗除算や分岐が重い処理だから少なくするんだっけ
ちょっと昔は、コンテキストスイッチに気を付けるくらい？
今は何に気を付ければいいん？
マネージ・アンマネージの行き来？

キャリーフラグの値が欲しいときがある。

まあ、頑張ってチマチマ最適化しようが、DataGridに数万行突っ込んだら全て終了です

仮想化しても駄目なの？

>>41
しょうがないお馬鹿さんだな
アセンブラっていうのはCで言えば「Cコンパイラ」に対応する言葉。
C言語に対応するのは「アセンブリ」。

数万って実際どのくらいかな

>>47
こういう奴は今でもD-RAMはおかしいD-RWMって言え
とか思ってるんだろうか w

そもそもDataGridに何万件もデータを入れようなんて設計が間違っているんじゃない？
それにWPFなら仮想化できるし、そこまで問題にならないような・・・

>>50
あのさぁ…話ループさせたいだけの下痢便くんはこの世に要らないわけ
分かる？
今すぐ中央線に突っ込んで死ね

暑いけどまだ夏休みじゃないのにな

毎日が日曜日なんだろ

いまさらListViewがデフォ仮想化されててIsSelectedとBindしても同期されないって知ったのですが
仮想してる場合SelectionChangedから自力でやるしかないのですか？

ItermsControlの仮想化は欠陥品もいいとこだから切ってるわ
あとはパフォーマンスに端から期待しない設計をすればいい

http://stackoverflow...istview-to-viewmodel
こういうのはどう？

>あとはパフォーマンスに端から期待しない設計をすればいい
パフォーマンスがWin Formsと同等、あとはコントロールなどWin Formsと同等のものが
早いタイミングで用意されてたら、WPFの現状も今とは多少違うものになっていたろうにな

WPFも.NET Nativeにすれば良かったんだよ。
今からもすれ。

>>50
その程度の思考でプログラマーやってることにドン引きだわ。

Excelみたいなアプリを作っちゃいけないんだ。へー。

DataGridの仮想化が糞なのも有名な話だと思うんだが。

50に設計を依頼したくないな

>>59
WIｎFormsはListBoxやListViewがお粗末だから、見栄えの良い表にしようとするならDataGridViewを使わざるを得ないが
ｗｐｆなら大量データの表示はListViewやListBoxを使えばいい
DataGridは入力する場合だけに使えばいいから、言うほど大量のデータを扱う必要はない

Excelが何万件ものデータを扱うとき全部オンメモリで
やってるとでも？
その程度の思考でプログラマーやってることにドン引きだわ。

しっかし、相変わらず文句ばかりのスレだね。
そのエネルギーをもっと有効活用すればいいのに。
別にWPF使えとか強要してるわけでもなし、こんな
過疎スレにわざわざからみに来るなんて余程暇なんだな。

適材適所が理解出来ないお爺ちゃん達には困ったもんだよ、ほんとに。

どうでもいいけどD-RWMって何を考えてこういうことになるんだろかね。

ROMがRead Only Memoryだから
RAMはRead Writeとかトンデモ理論なの？

Aはなんだと思ってたのかね。
Random Access Memoryなのに。

>>64
横だが、ROMも機能的にはランダムアクセスメモリーなわけで、ROMと区別するための識別子としてRAMは意味合い的にふさわしくないが
定着しちまったから略語として正しいRWMじゃなくてRAMと言っている

この理屈はアセンブリ言語を定着しているからアセンブラと呼ぶことと同じ理屈だってことじゃないかな
「アセンブリ言語だーと喚くならRWMと呼べ」という主張には一定の正当性があります

なんか鳥頭なのかこの話の流れの突っ込みどころ、笑いどころが分かってないのが多いけど、
そもそもWPFのパフォーマンスの話の中で「アセンブラ」なんて頓珍漢な言葉が出てくるのはどうなのっていう
そこだからw

言葉遣いが不適切であるってのはついでの話

ループ以外のレスをしないでください

>>64
バカは書き込まなくていいぞ w

XAMLのBindingで質問です。

とても単純なケースで説明すると、
XAML側でTextBoxを定義して、Textに
MainWindowに新設したstring testStringをBindするとします。

public partial class MainWindow : Window
{
public string testString { get; set; }


<TextBox x:Name="testTextBox" 〜省略〜 Text="{Binding testString}"/>

この状態において、

コンストラクタ内で
public MainWindow()
{
InitializeComponent();
this.DataContext = this;
testString = "1st set";
}

このコードを実行すると起動時にテキストボックスに"1st set"が入っており想定通りです。
さらに、新規ボタンコントロールを追加して
ボタンが押された際に新しい文字列をテキストボックスに設定するようにするとテキストボックスが更新されません。

private void testButton_Click(object sender, RoutedEventArgs e)
{
testString = "push Button";
}

>>69
INotifyPropertyChanged

しかし、この状態で

private void testButton_Click(object sender, RoutedEventArgs e)
{
testString = "push Button";
// 以下を追加
Binding bind = new Binding("testString");
bind.Source = this;
this.testTextBox.SetBinding(TextBox.TextProperty, bind);
}

とするとテキストボックスは更新されました。

XAML側のBinding指定はコンストラクタなど各ウインドウ？が生成される時にしか有効ではないのでしょうか？
それ以後Bindされているオブジェクトが新しくなる場合は、再度バインドしなおさなくてはならないのでしょうか？

自分の理解では、
オブジェクトが更新された場合の内部挙動はBindingで所持しているプロパティパスを
DataContextからFindして該当プロパティの値を参照する、というようなイメージだったのですが、

どうもこの挙動をみていると、該当プロパティを見つけるところまでは同じですが、
見つけた後、プロパティの中に入っているオブジェクトそのものだけを記憶しているように感じます。
C++的な書き方をするなら
class MainWindow
{
string* testString;
}
// 想定していた挙動
string*& bind_property = MainWindow.testString;
// 実際の挙動
string* bind_property = MainWindow.testString;
みたいな感じですかね。新規オブジェクトのアドレスが代入されるけど、バインドは旧オブジェクトのアドレスをみているようなイメージ。

>>70
> >>69
> INotifyPropertyChanged

testStringをMainWindowではなく
INotifyPropertyChangedを継承した別クラスにおいて、
そこで通知をうけれるようにする、という事でしょうか？

GUIコントロールからプロパティへのフィードバックが必要な場合はINotifyPropertyChanged
を使う必要があるのかなと思っていたのですが、
プロパティ->GUIコントロールだったとしてもINotifyPropertyChangedが必要なんでしょうか？

>>72
> GUIコントロールからプロパティへのフィードバックが必要な場合はINotifyPropertyChanged
> を使う必要があるのかなと思っていたのですが、
> プロパティ->GUIコントロールだったとしてもINotifyPropertyChangedが必要なんでしょうか？

これは逆だね
>>69 のコードでもテキストボックスのテキストを打ち変えたら testString の値も変わる
(デフォルトではテキストボックスからフォーカスが外れたとき)
INotifyPropertyChanged を実装するのは testString の値が変更されたことをテキストボックスに通知するため。

> testStringをMainWindowではなく
> INotifyPropertyChangedを継承した別クラスにおいて

インターフェイスなので MainWindow に実装してもいい。もちろん別クラスでもいい。

ありがとうございました。
INotifyPropertyChangedで解決できました。
最終的にはPrismいれてBindableを使うようにしました。

ちなみに皆さんは、どこでWPFの情報を収集して学習しましたか？
MSDNだけで十分？
自分は本などは買っておらずネットだけでなんとかしようと思っていたのですが、
WPFのバックエンドの動作などが細かく解説してあるようなページはみつけられなくて・・。
そういったイメージがつかめるととっつきやすいかなーとおもうのですが。

ReactivePropertyのほうが簡単でいいよ。
PrismとReactivePropertyの組み合わせが鉄板。

>>74
書籍だとエッセンシャルかな

Google先生で十分じゃないかと
便利な世の中になったもんだと思う

>>76
エッセンシャルに一票
てか、まともなのが和書じゃこれしか見当たらん。

みなさん、ありがとうございます。
参考にさせて頂きます。

HogeViewModel は名前空間 "clr-namespace:ViewModels に存在しませんとかいうエラーに小一時間悩んだあげく
（実行はできるけどXAMLデザイナーがエラー出ていじれない）
結局ViewModelが参照してるDLLのインターフェースを実装したらそうなることが分かった・・・
意味分からん

そんなクラス(ロードでき)ないぞ！
というエラーなわけだな

デザイナーエラーで悩んだこと有ったが、俺の場合は古いBlendのｄｌｌがGACに入っていることが問題だったな

ねーねー
WPFってメモリリークしやすいっていうけど、リークしてるってのはどういう手法で見つけてるの？

例えば、VS2017の場合とか

>>82
CLR Profiler

Prismのインストール方法教えてください

Prismはソースコードを必要なとこだけコピペして切り貼りして使うもんだよ
ライブラリじゃなくてあくまでサンプル集

>>84
NuGet

>>85
ワラタw

実際Prismは本来はそういうものだけどな
最近はフレームワークを自称するようになったけど、元々の位置付けはあくまでサンプルコード

>>74
https://www.slidesha...i0130/wpf45-38048141

>>88
そんな昔話をして>>84の質問に対して何か意味あるの？
今は>>86が正解。prism 6で検索してターゲットに
合うものを入れればいい

いや今も昔もPrismって出来合いのままで広汎なアプリの要求に対応できるようには作られてないだろ
基本的にはアプリに応じてカスタマイズして使うもんだし、それが負担になるような小規模のアプリはそもそも想定外
カスタマイズが必要になるまではライブラリとして使うというのはアリだと思うけどね

今も2017に対応させたLivetを使ってたりする…

誰一人としてPrismがフルスタックのフレームワークだ
なんて主張してないし
>>84はプロジェクトへの組み込み方聞いてるだけだし

他のスレッドでインスタンス化したTextBlockを
UIスレッドでは見れないのはなぜでしょう？

あなたが仰られているそれが理由ですよ
他のスレッドでインスタンスを作ったから

差分アップデートの実装ってどうやってるの
差分ファイルを作るライブラリとかないすか

>>96
DLLベースで作ってんの？
違うなら意味ない

>>94
コントロールを作成したスレッドからしか操作できないんでしょう。
シングルスレッドアパートメントってやつ。
Win FormはそうだったけどWPFは知らない。

このスレって過疎ってるね。
WPFって需要ないんだな。

なんだオマエ
喧嘩売ってるのか？

Windows7 を切り捨てたくないからなかなか UWP はね…

海外製の業務パッケージなんかだとWPF使ってるのもわりと見かけるけど、たいてい酷い品質なんだよね
別にWPFが悪いんじゃなくて、作る側が慣れてないのが使ってて伝わってくる
そもそもWPFって頭良くてWPFの仕組みも完全に理解してるアーキテクトがトップダウンで大枠から設計していくような開発スタイルに向いてて、
散らばった開発体制になりがちなドカタ開発には根本的に向いてないんだと思う

ヘルプが充実しすぎてて語ることもない

Livet更新する気ないなら、そう言ってくれないかな？
実はもうLivet2のリポジトリもあります！ｷﾘｯ（ｽｯｶﾗｶｰﾝ
とかほんと勘弁。

んだねぇ・・・

>>99
言い値で買ってくれるのなら売るけど

>>101
もう、MVVMなんか完全に無視してXAMLの描画能力だけを使えば。
コードビハインドにイベント直書きで。

ほんとそれで済むならそれが一番お気楽だと思うw

WPF アプリケーションからショートカットキーで単語登録ツールを開くと、クリップボード上のテキストが単語登録ツールに送信される
https://blogs.msdn.m...eam_blog/2017/06/30/

>>107
済まないのけ？

バグか
多言語環境は後回しにされるからと言っても今更な問題だなー
枯れてもいないのにクラッシック扱いとかないよな

ちょ○どさんと人脈築かないのが悪いんでしょ。:-p

ちんぽ騎士団のことか？

>>103
3〜4年前に選定で状況がアレなんで落としたけど
未だに何かメンテされるとか思ってる人は何を見て
そう思ってる(期待してる)のかねぇ？

>>103
あいつは信用できない人だから諦メロン。

>>113
メンテされてるとは思ってもいないよ
Livet無しでは生きていけない体にされてしまったから、
今から新しいご主人様のもとにいけないだけ。

もうLivetなんてさわりませぇ〜んｗｗｗとか言ってくれたらすっぱり諦められるのにな、って話

PrismとReactivePropertyにすればいいのに。
化石か。

>>106
そういうのやったことあるｗ
MaterialDesignThemeのボタンとかが欲しかったんで
Win32ダイアログのStaticに貼り付けて、SendMessageでメッセージ送信、
WPF側はCOMにしてって。

livetはセットアップが使えるまでさわりそうだわ

>>116
そうする。
Livet滅びろ

>>119
prismにしたら、序にprism.Unityも検討すると幸せになれます

DIならAutofacの方が遥かに使いやすい

>>121
ｗｐｆ版のunityはごちゃごちゃしているけど、UWPはシンプルで使いやすいよ

autofac使いたいけどドキュメントが英語しかないのよ
unityもだけど
TOEIC500点にはしんどい

500あれば英語のドキュメントくらい十分読めるだろ

何も考えないでならMEFが楽だったけど、色々問題もあるので
今はNinjectを試しに使ってみてる。Autofacは使ったこと
無いから次使ってみよう。
Unityはなんかこー使ってて芋くさい感じで即捨てたナァ。

Livetは会社の先輩にあいつについて行ってもろくな結果に
ならないよ言われたので何言ってるのか理解できなかったけど
検討すらしなかったな。
なんかそっちの業界では有名な人みたいね。

個人的には現段階で要求満たしてて物作りに使えるなら
文句言うような話でもないと思うけどさ。
コードもあるんでしょ？

個人的にはDIはAutofacが一番活発っぽいので、将来性を見るならいいと思う。
後、使い勝手に癖があるけど、パフォーマンスを求めるならSimpleInjectorが今のところ一番かな。

MicrosoftがUWPとXamarinのXAMLを標準化
https://www.infoq.co.../07/xaml-uwp-xamarin

XAMLを使用する重要な技術のひとつはWPFだ。
BUILD Friday Q&Aに参加した.NET開発者のMorten Nielsen氏が、
MicrosoftのWindows Developer Platform担当VPであるKevin Gallo氏に、
WPFに関する同社の計画について質問している。
Nielsen氏によると、この質問に対してGallo氏は、
“XAML Standard機能への対応を目的としてWPFを改訂する計画はない”、と答えたという。
“この回答は“WPFは死んだ”という宣告に等しい”、とNielsen氏は言う。
同じ開発者のBastian Schmidt氏はこの話題について、
“MicrosoftがWPFを標準から除外すると決定したのならば、WPFの終了に関して公式声明を発表するべきだ”、
という意見を述べている。

考えられる対策として、Shaun Tonstad氏は、WPFアプリをUWPに変換する方法を提案している。
そうすれば標準においてWPFをサポートする必要はない。

　私たちはこれまで、WPFやSliverlightのアプリをUWPに書き換えてきました。
　WPFのサポートは有り難いが、
　UWPを通じたクロスプラットフォームXAML実現の妨げになるような取り組みは望ましいとは言えません。
　WPFをどう考えるかは別として、今後はUWPが重要である以上、
　クロスプラットフォームの相互運用における出発点にUWPがなるのは自然なことに思われます。

XAML StandardはUWPとXamarin.Formsのためのもので、UWPがベースとなる。
WPFは当然そうなる。

クロスプラットフォームか…
UWP はホント何とかしてWindows7以降位で動くようにしてほしいわ

まあMSのプラットフォーム切り捨てはその時点ではショッキングで時期尚早のように感じられても
後で振り返ると何だかんだ言っても常に正しい決断をしてるからね
WPFはその歴史の中では長く延命させてもらえた方だったと思う

いい加減需要無視の官僚主義でゴリ押ししても誰もついてこないって悟って欲しいよね。
UWPなんぞWPF以上に普及する訳がない。

VB6とwinformsが細々と生き残ってるのにWPFは終了ですか

VB6やWindowsFormsには触れてないけど、WPFと同じくレガシー扱いするんじゃないかな

WPF→UWP移行なんて簡単にできるやん。
セキュリティに引っかかるくらいで。

WinForms連中に移行は無理だろうけどｗ

UWP移行せえって言うことはこれまでみたいなツール類ソフトは作るんじゃねえってことだな
c++のDLLのラッパーも作れないしpythonにすら劣る環境になるぞ
戦わずして負け

UWPなんていらんし

UI だけ作らせてくれりゃいいよ
ちゃんと古いOSもサポートしてさ
ってことでもう全部 Xamarin でいいよ

UWPやXamarinでは制約のせいでVS Codeすら作れないからな
electronに負けるってどういう環境だよ

Xamarin なら UI (とロジック)以外はネイティヴで書いていいもんだと思ってたけど制約あるの？

チョマドも切り捨てたら信じる

VS2017のインストーラーがelectronで作られてて
MSなのになんでUWP使わないのみたいな記事があったけど
UWPは制約のせいで作れないからな

あのインストーラはむしろなんでElectronなのかの方が謎ではあるが
Visual Studio Codeはクロスプラットフォームという前提があるからわかるけど

新規でインストーラ用ツールを書き起こそうと思ったら
まともなデスクトップ用GUIフレームワークが自社ありませんでした
みたいな理由をMS自身が抱えてたとしたら最高にウケる

謎でも何でもないだろ
新規で作るものにWPF使うなって内規があるんだろ

UWP で作ったら Windows 7 で動かないじゃん

それ以前にUWPなんか誰も使いとうないw

見づらい糞フラットデザインにぱっと見アクティブウィンドウがどれかも分からん糞仕様とか
ふざけてるのでなければMS自身に普及させる気がないとしか思えん

MSはそもそもWPFアプリを全然作らなかった。
UWPアプリは作りまくり。
そういうことだ。

XPに馴染めずに、何年もWindows2000使っていたマニアって少なからず居たよね・・・

UWPは業務向けアプリを作るのにちょっと都合が悪いんだよなぁ・・・
今更WinFormsに戻れってか

迷走してるよなー

Javaも AWT、Swing、SWT(非標準)、JavaFXとか変遷続いてるけど、
万人に向いている GUIフレームワークって存在しないよな

MSがWPFを見捨てる理由って、
一般プログラマに敷居が高くて流行ってないという理由以外になんかあるのだろうか？
UWPだってXAML使ってるから敷居の高さは変わらない気がするけど（未使用者並みの感想）

この程度で敷居高いとかいってる人は開発向いてないよ。
WPFが使われてないって日本固有の話だと思ってたが？
海外じゃミドルも含めて製品いっぱいあるしStack overflowの
記事もかなり多い訳だし。

そもそもVBとかで飯食ってた緩い層がiOSとかAndroidとかに
いっちゃって、さらにiOSやWeb系の開発のためにマックの
ユーザーが増えて結果としてWindows のデスクトップアプリ
作りを生業とする人が激減したという話でしょ。
実際一般ユーザーがやることなんてマックだろうと
Linuxだろうと何でもいい程度の世界にはなってるわけだし。

俺もWPFで作ったパッケージ製品抱えてるし、この流れは
どうしたものか悩ましいな・・・。買い入れてるクソみたいな
コンポーネントがUWP対応してくれないと話にならないけど
正にWinFormsにしがみついてる層が作ってるからなぁ。

>>148が言ってることが全てを物語ってると思うが、ストアで儲けたいけどタッチ対応出来てWin7でも動く、業務アプリ作るのに制限が無いWPFがUWPにとって邪魔ものなんだろ。

ストアで配布さるんじゃないなら、側(UI)だけUWPにして本体は Python ででも書けば良いのかもよ。

UWPがもっと使い勝手よければ移行してもいいんだけど
今のクソ仕様じゃなあ

2018年 UWPへの旅 #002
https://blogs.msdn.m...6/11/27/2018uwp-002/

WPFを入れてデスクトップアプリ的なところも入れたいんだけど、
最悪これはなくてもよいかと。
要は今のUWPでデスクトップアプリ的なところがちゃんとカバーされればいいんだよね。
いろいろ言われているけど、電卓もペイントも徐々にUWPに移行されつつあり、
コンテキストメニュー的な連携もできれば
別にデスクトップアプリなのかUWPなのかはユーザーにとってはどうでもいい話だったりします。

ということで、デスクトップアプリの取り込みは
今の Bridge というか Desktop App Converter になるのかもしれないですね。

まともに使えるようになったら発表してくれ

自在にファイルにアクセスできればUWPでもいいんだけど、、、

まあWebでいいわな
全く価値のない技術

UWPはプロセス間通信できないのも糞

WPF、UWPどちらを使うか迷っているので質問です。

WPFで作ったアプリをDesktop Bridge？App Converter？を使って
Windows Storeで配信できるようになったらしいけど
WPFから変換したそのストアアプリでもUWPで作ったアプリと同様に
「広告収入狙いの無料アプリ」にしたり、「有料アプリ」にすることはできるのですか？

>>159
有料アプリは値段選ぶだけ。
広告はUWP用MSの広告SDKなのでWPFからだとひと手間いるはず。詳しくは知らない。
それか、自前でどこかの広告使うか。

ギョーミーなアプリとUWPは激しく相性が悪いんだが

>>159
WebかXamarinにしたら?
Winストアアプリで広告収入とかGoogleMapアプリのクラスですら厳しいんじゃないか?w

>>160 >>162
ありがとう
有料アプリならWPFからの変換したものでもUWPと同様に使えるのか

>>162
厳しいというのは利用者の面から？
Windows Phoneだけなら利用者少なすぎだけど
PCでも使えるようにした変換UWPアプリなら
利用者はかなりいるから期待できるんでは、と思っている

Xamarinはmono時代のASP.netで昔少し触ったけどバグだらけで
ひどい品質だったから、名前だけで敬遠してしまう。
Xamarinは各プラットフォームの挙動の違いを理解してないと
バグではまりそうで実はかなり敷居が高い気がする。
上級者じゃないからバグでたときに情報が少ないXamarinはつらい

UWPで実現可能かつ対象ユーザーがwin10のみでOK
なら普通にUWPで良いっしょ

まずはAPIを一通り確認してから

>>164
有料アプリとか広告付き無料アプリみたいな不特定多数向けだと
Win10限定になるUWPは選びにくいと感じる。

Win10はまだ26.8%しか利用者がいないようだ
https://www.netmarke...d=10&qpcustomd=0

WPFならXPでも使えるはずだから90%近いPCをカバーできるし
単純にユーザー数が3.3倍
ユーザー数というデメリットをひっくり返せるメリットをいまUWPに探しているが
まだ見つからないでいる

>>165
メンテ性だろうね
UWPが優れてるとかじゃなくて、数年後に訪れる7のサポート終了時の対応のしやすさ

作り手から見れば
・ネイティブでとにかく高速、そして難読化と無縁
・署名付きアプリの配布が格安（一度19ドル払えば何本ソフト登録してもこれだけ、法人は９９ドル）
・広告や販売の面倒をMSが見てくれて楽ちん

利用者は
・勝手に変なソフトインストールはありえない
・ウイルス混入のリスクは可也低い
・レジストリ弄らないから、アンインストールのトラブルは皆無

Windows10でしか動かない、セキュリティーが厳しい、システムの完成度はWPFに劣る、プロセス間通信不可
ココらへんのデメリットが２０年までにどれだけ解消されるか注目だね

むしろUWPやめてWPFに統合しろよと思う

WPFの遅さからするとUWPの速さは魅力。

Formsが高DPIに対応した以上WPFはもう要らない子

Formsの高DPI対応はまだ初期段階らしいけど

>>168
WPFにNative化とx:bindが来るだけで大分変るな。
UWPはセキュリティーガチガチ過ぎて使い道に困る。

Windows10でVS2017を使ってWPFを勉強し始めたんだけど、WPFって何かを設定しないとHighDPI認識してくれないの？
検索してdpiAwareをマニフェストに追加してみたりしたけど文字がボケボケになる
どこを設定すれば良いのか教えて欲しい

>>173
ちゃんと.NET4.7使ってる？

>>174
いま確認したら使ってた
http://i.imgur.com/OuylU5i.png
http://i.imgur.com/rLbS0GV.png

>>173
Windows 10 Anniversary Update以降では、dpiAwarenessで指定するそうだ。
Creaters Updateからは、このdpiAwarenessにPerMonitorV2って設定が増えてる。

High-DPI Scaling Improvements for Desktop Applications in the Windows 10 Creators Update
https://blogs.window...-10-creators-update/

例:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.micro.../PM</dpiAware>
<dpiAwareness xmlns="http://schemas.micro...ot;>PerMonitorV2, PerMonitor</dpiAwareness>
</windowsSettings>
</application>

今更だけど、>>127の記事のWPFは事実上死んだって見解は実際正しいの？

WPFだけじゃなく、UWP以外まとめて死亡って感じだと思うけどな。
x:BindはWPFにバックポート出来そうだけど、UWP推進するために敢えてやらないのだろうし。

>>173
Windows10で文字がボケボケになるのを直すだけなら、dpiAwarenessをSystemに

>>176
>>179
おお、できた！
dpiAware「ness」かー。
そこまで探せなかった。
ありがとう、助かったよ！

>>180
VSでapplication.manifestを新規で追加した時に、dpiAwareの方は
コメントでサンプルが記述されてるけど、dpiAwarenessは記述されてないしね。
VS2017位は追加しておいて欲しいね。

xamarinはwindows10アプリケーションのみ開発するのには向きますか？

>>182
スレチ

Xamarin Part5 [無断転載禁止]©2ch.net
http://mevius.2ch.ne.../tech/1498575762/l50

>>183
すみません。誘導ありがとうございます。
xamarinとwpfの違いがいまいちわからずにここで聞いてしまいました。

>>184
ゴミめ
http://pbs.twimg.com.../CyKXMkvUsAAkB_g.jpg

そろそろ普及の兆しが見えてきたな。

などと妄想を垂れている一方で、MSはElectronを使ってプログラミングエディタ界で天下を取ったわけだが

エディターだからどうにかなっているけどElectronでExcelは作れんだろ
遅すぎて

適材適所だね〜

>>188
UIを載せ替えるだけなら余裕で作れるでしょ
Electronの裏をネイティブや.NETで書く技術は完全に確立されてる

>>187
LinuxやMacまで含めたデスクトップアプリを開発するならelectronってだけじゃない？
無理矢理フィットしない技術を選ぶ必要はない

ExcelOnlineの機能を拡張すれば済む話だとは思うけど
そもそもデスクトップアプリ化する理由が無い

だーからそういう戯言は20年前も聞いたよw
いまだに実現してないけどねww

そうは言っても、テキストエディタという開発者にとって最も身近なデスクトップアプリがHTMLになったのは紛れもない事実だからね
しかもその変革がこれまでデスクトップアプリの世界を牽引してきた当のMSによって為されたということも事実
いい加減現実を直視しなければならない
VS2017も一部Electronになってるし、順当に行けば次の本家VSはテキストエディタがVSCodeベースに置き換わるだろうね

xaml挫折した人がElectron使えるとも思えんわ

SkypeのためにReactXPとか立ち上げたりどこに進むのかよーわからんしWPFが死に行くのはどうでもいいけど
さっさとWin32デスクトップアプリを書くためのまともなGUIフレームワークをOSの一部として提供しろや本当にお願いします

なぁにぃ〜やっちまったなー
男は黙ってMFC

.NET Standard 2.0とXAML Standard 2.0です。

>>186
ギョーミー底辺のオレが使い始めたからな。

xamlのエラーはどうやってデバッグするのさ?

神に祈る

>>200
どの神？
アッラー、エホバ、ヤハウェ、ビラコチャ、ケツァルコアトル、アメン、フレイア、天照大神、疫病神?

知らねえよカス

>>202
全ての神々の祟りがオマエにありますように。ﾅﾑﾅﾑ

>>201
つ >>185

>>204
ちょまど神を信仰せよと?
ぐぐったらほんまもんの女神様ではないですか。信仰します。

まーたチンポ騎士団員が増えてしまったのか

あのスライド1枚で優位に立ってたと勘違いしてたプライド激高の囲いエンジニア達が一斉に掌返し始めたの草しか生えなかったな

すっかり迷走してますな
まさかWIn32APIとDirect3DとDirect2Dを組み合わせて
ボタンやらツールバーやらメニューバーやらスクロールバーやら独自で作って
我ながらアホなことやってるなと思ってた俺の方が勝利するとは

よくよく考えれば、最近弱くなってきたMSのMSによるMSのためのMSの市場戦略に
昔からのユーザーである俺らが、なんで振り回されなきゃならないんだろうかと
スマホもMSがシェア取ってれば、MSもどっしり腰を据えて世の中や俺らのためになる
そういう方向にかじ取りできたのかもしれないが
なんかもう、Win8以降は、とにかく戦略戦略戦略、市場戦略先行でマトモじゃない
良いもの作ろうという精神が無い
こういう事態に追い込まれたら、もう負けなんだよな
だからそうならないようにゲイツは汚い手を使ってでもライバル企業をつぶしてきたんだよ
自社製品を素晴らしいものにするために、横綱相撲するために

>>209
神への信仰が足りませんね。
つ >>185

> まさかWIn32APIとDirect3DとDirect2Dを組み合わせて
> ボタンやらツールバーやらメニューバーやらスクロールバーやら独自で作って

泥のGUIもアーキテクチャは似たようなもんだし別にそこはええんでないの
圧倒的に最適化が足りなかったとは思うけど
あと既存のHWNDとの相互運用がへぼかったのもあるか

>>209
正論

ゲイツ以降の経営陣が本当にダメだな

スマートフォンの台頭で、調子に乗ったAppleがRIAプラグインを排斥し始めて
その煽りでSilverlightが死んだ時、俺のMS信仰も死んだ

いやスマホ諦めた時点だな。
それまでは開発者大事にしようとする気持ちはあった。

全く諦めてないでしょ
単に主軸がWebに移って未だにWPFに固執してるような極一部の老害だけが蔑ろにされてるだけだよ

自分達がMSに必要とされなくなったのをさも開発者全体のことのように言うのはみっともないからやめなさい

>>215
移ってないってw
君が大海を知らない井の中の蛙なだけw
世界は君に見えてる範囲だけじゃないよwww

つーか、ネトウヨにしろネットde真実くんにしろ、アホと間抜けな自己陶酔ってほんとセットだなw
俺スゲー俺以外老害ってかw

Azureバカ売れの時代に何を言ってるんだ
いいかげん危機感持った方がいいぞ

現に>>217のような人を生み出してしまったわけだから、Webへの移行にあたって
既存のデスクトップアプリ開発者向けの緩やかな移行パスを用意できなかったのは確かにMSの失策かもね
その意味で期待されていたSilverlightもダメだったし、ASP.NETもForms切り捨ててWebのメインストリームに迎合する方向だし

Webとモバイル、どっちも諦めたからな。
開発者離れは深刻。

開発者離れといってもWebへ行けないなら結局MSにすがりつく以外の選択肢はないじゃん
哀れ

しがみ付くならしがみ付くで構わないんだけど
MSの実らない市場戦略に
振り回されることになりそうだから嫌だよね
って話だったのでは？

自己陶酔くんに現実が見えない理由は、ネトウヨ的な間抜けな自己陶酔以外に
絶対量と変化率の区別がついておらず、後者を前者と錯覚してるって要素もあるんだろうね。

例えばSaaS化した方がメリットがある分野が存在するんだからそういう流れが存在するのは当然だが、
だからといって世の中のソフトウェアの需要の全部がそうであるわけじゃない、
っていうか、そんなものは現実には全体のごく一部でしかない。

主軸が移った？
んなわけねえじゃんw

余談だけど、「俺スゲー」って自分に酔いたい願望っていうのは、
普通は逆説的に抑圧された自己不安や劣等感の表れだよw

それは2chにいっぱいいるネトウヨやネットde真実くんを観察すれば明らかだよね。
観察者も同類ならどうだか分からないがw

こういうのってやっぱ自己紹介乙ってやつなのかね
皆興味なくてスルーしてるようだけど

習得や移行に苦労するのに、それが普及しなかったときの精神的ダメージは計り知れないね。
こんなもの普及しないと笑ってた奴らを新しいものについていけない老害だと罵倒していた自分が恥ずかしい、みたいな。

まぁでもWinFormsにしがみついてるよりいいんじゃない？流行らなくても使えない技術ではないし

毎日使う定型業務のアプリが全部Web化されると使う方は辛いぞ。
JavaScriptでフロントエンドを頑張っても所詮はブラウザの縛りからは抜けられん。

座間弥老

WPFもSLもUWPも同じ軸の技術の流れだし、考え方としてはElectronというかHTML5やらJavaScriptやらとは根底は同じ方向性だと思うけどな。ミクロな見方する人からするとチゲーよってなるんだろうけど。
そういう意味では、ここでよく喧嘩してるWinFormsに固執する人はどれにも乗っかれなそうな感じはするな。

>>230
ウヨサヨやってる馬鹿な連中じゃあるまいし、WPFの問題点を指摘したからって
Windows Formマンセーなわけじゃないよww

まあプログラマの世界にもそういう党派的な物の見方しかできない馬鹿多いけどね昔から

>>230
その通り。ゲイツがその考え方を糞つってんだからやはり糞なんだよ。
ゲイツが退いてからのVista以降のMSの失敗の数々。やはりゲイツは正しかった。

XML系技術は糞と言いたいんだろ。

ゲイツが続投してたら上手く行ってたかは分からないけどな。

そろそろZAPして次のUIフレームワークが上手くやることに期待した方がよいのではないか

1スレ埋めるのに2年掛かってるUWPは良さを語る前にやることがあるでしょう
お前はお呼びではない
さっさと普及活動しろ

つか太古の昔、IE作ってActive Desktopとかやってた時代からWeb系をUIの主軸にしようとしてたの忘れたのかね。タブレットと同じで何度も挑んで玉砕してるけどな。それでも諦めないのはMSのいいところだと思うけど。

そういえば　ActiveDesktop　も失敗だったな。
IE4.0でCOM化して、ペタペタ張れるようになったのは大成功で、
2chブラウザとかは便利に作れたな。

あまり1つを育てる気がないよね
下火になると放置フェーズに入るし

どうせUWPもストアアプリ（モダンUIだっけ？wもう忘れた）と同じようにすぐに捨てられる
普通はそう考えるよね。実際デキ悪いし

だからPetzoldも今度は本書かないんだろう。ふざけんなって思いもあるだろうがw

分ったことはタッチUIとマウスUIは一つにはできない。

できてるやん。

どうみても失敗やん

UWPはマウスに合わないんじゃなくてキーボードサポートが絶望的にうんこなのがダメ

UWP自体はそんなに悪いと思わないけど
初期の、どんなに大画面のモニターだろうと全画面にしか表示する仕様だけは、擁護できない
MS社内って全員WindowsPhoneだけで仕事してるのかと思ったよ

そもそも初期の頃タブストップないって聞いて驚いた

それまでのMSのアプリはよほどおかしなことしてない限り必ず
キーボードだけでも操作可能だったのにね

違うタブオーダーだね(´・ω・`)

.NET Framework 4.7上で実行している WPF アプリケーションで、タッチ操作を繰り返すと、タッチ操作に反応しなくなる。
https://blogs.msdn.m...3/wpfnetframework47/

何度もパイタッチしていると不感症になるのか

.Net 4.7でWPFのタッチパネル対応が強化された時にバグも仕込まれたのか。

ユーザーから拒否られるUIって根本的に腐ってるということ。

もうメトロUIも止めるみたいだけど、使いにくかったしね
ほんのちょっとグラデーションかけるだけでも随分見やすくなるんだけど
単色は見にくい

このスレはUIを使いこなせないユーザーを叩く傾向があるね。

>>252
え゛

Windows7でWindows10ライクなモダンウィンドウを手軽に作りたくてWPFに手を出そうと思うんだが、
他にいい選択肢があれば教えろください。

>>255
Electronだな
Visual Studio CodeがElectron製だからイメージを見てみたらいい

>>256
VS CodeレベルのものがElectronでお手軽に作れると思ってるとはかなりお目出度いな。

尾頭付きで祝って貰えそうだな

Win8の時代はWPFでモダン（笑）UIっぽいGUIを作るライブラリみたいのが
いくつかあったね
これとか
https://marketplace....ernUIforWPFTemplates

たぶんUWP時代のもあるんだろうけど、Windowsのタッチアプリには
興味失ったんで調べてないや

モダンという言葉は昭和どころか大正の香りがする

>>260
そろそろ自分の感覚が古くなってることを理解した方がいいぞ
若い奴はモダンってなにそれ？
状態だから

中に粘っこいあんこの入ってるやつだな

ジジイだとしたら「昭和どころか」って言い方が不自然だな。
一周回って再発見した若者なんじゃないの？

若者に昭和と大正の違いがわかるとは思えん
爺の俺でも大正と明治の感覚的な違いはわからんし

>>264
そういうのは年代の問題じゃないと思うよ
無学かどうかの違いだけw
大正デモクラシー云々って話は中学校の社会科でも出てくるレベル。

こればモボ・モガなら年代の問題かもしれないけどねw

大正はサクラ大戦で
昭和はひぐらしのイメージ

>>265
香りとか感覚的って書いてるのに...
無学って悲しいな w

何を言ってるのか意味分からんけど、モダンって言葉から
大正を連想するかどうかは年代の問題というより無学かどうかの
違いだろうねやっぱり。

暗黒の昭和戦前との対比でモダンであった大正時代、って言う風に
語られることが多いから。

そもそも、今肌感覚で大正時代を知ってる日本人なんて
もうほとんど生きてないんだから、知識として知ってるかどうかって問題でしょう

アレは恐らくモダンアートのモダンだから、年代とか関係ないんじゃね？

>>268
> 何を言ってるのか意味分からんけど
学がないって辛いね w

バブルの頃に大正時代のモボ・モガが復刻で流行ったことが有ったから
モダンが古く感じるんだろうが、そもそもバブルも大正もマイクロソフトのアメリカには関係ないからｗ

>>271
なんか得意げにバカなこと言ってるけど、そんなこと（無学の彼はどうだか知らんが）
みんな百も承知だと思うよw

ついでに言えば、モダンアートなんて関係ないw
modernはmodernだからwww

いきなり大正デモクラシーとか言い出す自称学のある奴に言ってやれよw

>>273
まだ言ってるのかアホだねおたく

少なくとも日本の文脈では、モダンって言葉から大正を連想する>>260の感覚は
普通であって、むしろそうでない奴が無学であることを無学な奴に説明するために
大正デモクラシーという無学な奴でもこと聞いたことがあるだろう補助線を引いてやっただけ。

ちなみに、もちろん俺は>>260とは別人。

っていうか周囲の奴に聞いてみろよほんっと。
モダンって言葉から大正時代を連想するかって。

え〜っと、WindowsのモダンUIから大正デモクラシーを想起しろと

そろそろ自分でも無理あるなとか思わない？
頑固爺には無理かな w

だめだなこりゃ
馬鹿は死ななきゃ治らない、か

調べてわかったのは、Modern UI等のフラットデザインの源流が２０世紀初頭≒大正時代のモダニズム運動ってことで
大正のモダンとModern UIは無関係ってわけでもないようだ

>>276
死ね

ブーメランってこう言うことなんだろうな...

WPFがか？
次UIフレームワーク用意してくれるなら賛同してもええぞ

フラットデザインの肝である装飾を配したデザインってのを始めたのが２０世紀始めのアドルフ・ロースという建築家で
彼は「装飾と犯罪」というエッセイを残しているhttp://www.geocities...ntVerbrechen_jp.html
そこから始まる芸術運動がモダニズムと言うんだから、ModernUIが、その名前が古臭いとか勘違いも甚だしいってことだね

フラットデザインの側だけマネして肝を理解できなかったのがMSのデザイナー

まで読んだ

>>281
関係ないと思うよw

Modern UIの当初の呼称がMetro UIだったことが象徴してるけど、
当たり前だけどModern UIはピクトグラムと同じように（商業）デザインであってアートじゃないw

そもそもmodernていうのは相対的な概念で、Modern UIが何に対してmodernかっていうと
旧来のデスクトップアプリでしょう。

それから、これ何度も言ってるけど、>>260の人はModern UIって呼称が古臭いなんて
必ずしも言ってないよwww
どういう読解力よ

>>283
古臭いと言っているのは>>261の変な人のほうだから・・・・

VS2017はWPFを捨てたのかな？　ｸｽﾝ
MarApps.Metroを使ったアプリがVS2017ではイベントにブレークかけると、アプリケーションエラーで死んでしまう。
VS2015でデバッグするしかない。

>>283
> それから、これ何度も言ってるけど、>>260の人はModern UIって呼称が古臭いなんて
> 必ずしも言ってないよwww
> どういう読解力よ

【問題】
>>260が「昭和どころか」と書いたときの心中を20字以内で記述しなさい。

>>283
さっき書いたモダニズムの始祖であるアドルフ・ロースは建築家で
普通に商業デザインやっていた人だからね

だから、20世紀のモダンは2010年代にはモダンじゃないってw

それ、例えばプログレッシブスキャンはプログレ（プログレッシブロック）から来てる
っていうのと同じぐらい滑稽なトンデモだと思うよww

歴史を知らないのは単純に学歴の差だろう。

モダン＝近代的、現代的、新しい　という意味なのでいつ使っても
超今風ってことだから　今風は常に最新
当時は最新で今風

スレチなのにいつまでも歴史ガーとか爺は頑固で困る

今後何故か白黒が流行ってエラーやワーニング以外
字も写真も白黒という奇妙な事態になっても
それがモダンと言えばモダン

仲良くモダン焼きでも食ってこいよお前ら

偉そうに歴史を語ってこれがモダンだって言うのは痛々しい

モダニズムはただのなうニズム
大正モダンは大正なう
モダンUIはなうUI

もっとももうなうなんて使わないけど

>>294
https://en.wikipedia.../wiki/Modern_history

モダンとかいう名前つけちゃうのは恥ずかしい
10年経っても100年経ってもモダンなUIなわけないし

フラットデザインなんて昔からあったが、
UIに使うとここまで拒否られるデザインも珍しい。

残念だったのは、パクリ元の地下鉄の看板が
元来見るだけの物で、操作する物では無かったって所だな
結果、何処が操作できて何処が操作できないのか
パッと見てよくわからなくなって不評、といったところ

というより、地下鉄の案内版にしろピクトグラムにしろ、
看板という表現力が乏しいメディアで何かを伝えるための工夫だから
それは当然割り切って何かを捨てるトレードオフを伴うものだってことを忘れて、
GUIに適用しちゃったことが間違いの素だったね。

率直にいって、表示面積を無駄遣いして表現力のなさを補うための表現方法を
TrueColorが使えるけど一般的に狭くて表示面積が希少である液晶画面に適用するとか
狂ってるとしか思えんけど、MSみたいなインテリが集まってる企業で何でこんな
馬鹿げたことが通っちゃうのか、理解に苦しむ。

つーか、いい加減狂ったフラットデザインブーム終われよ。
見づらいんだよほんと

UIのセンスが無いのは昔から分かってたのに期待する方が悪い

そんなに気に入らないならWindowsもWPFもさっさと捨てればいいのに
まあそれができるだけの能力がないからこんなところで喚いてるんだろうけど
質問者もこうなりたくなければMS技術なんかに手を出さないほうがいいよ

フラットデザインの話がなぜ能力の話になってるのか。何かのマウンティングだろうか。
ゆとりの間では能力者が流行ってるらしい。無能に対する劣等感でもあるのだろうか。

嫌なら出ていけ系は本当にうんざりする

フラットデザインのお姉さんは結構好きかもw

MFCが糞でもなんだかんだ使われたのは、手本のExcelのUIが素晴らしかったおかげだろう。
逆にWPFが普及に失敗したのは、ExcelがリボンUIを採用したせいで悪い手本になってしまったからだろう。
あるいはWindows8のUIのせいか。

タブレットUIとデスクトップUIを共通化したのがあかん

WPFの登場って、Win8よりずっと前からでしょ

WinForms慣れした人が、あれこれ難癖付けて別技術への移行を渋ったのと
MS側も、「PGとデザイナーの分業」とかいう夢物語を大々的に喧伝したのとのダブルパンチで普及させられなかった
加えて、Silverlightが殺されたのも大きい

WPF&Silverlight自体は良い技術だよ

ああそれと、長らく「MVVMの決定版」と言える様なフレームワークが出なかったのも原因の一つか
そんなのは最初に用意しておくべきだった

結果として、「MVVMの論理として破綻しない、正しいMVVMはこうである」みたいな宗教っぽくなっちゃったからな

デザイナー主導で作ったUIがWindows8やメトロUI、リボンUIなのだから目も当てられない。
デザイナーはどうしてこうもメニューを削除したがるのか。

文字が並んでると美しくないと感じるんだろう
造形美なんざどうでもいいから機能美を追求してくれとつくづく思う

その辺はデスクトップを足がかかりにスマホにも乗り込もうと意気込んでいたからね
結局撃沈して無意味になって、単に割食らったデスクトップのUIが
キメラになったって負の遺産だけが残ったが
俺的にはスマホもMSが天下を取ってほしかったが、相手が悪すぎたね
Google以外の企業が相手だったらMSは勝てただろうに
あんな早い段階で提供して、CMもバンバン打たれたらね
恐るべしフットワーク

またリボンまで否定するお馬鹿さんが懲りずに暴れてるのかw

そんな駄文書いてる時間があれば自分で実際に使ってみれば
あれはそれなりに合理的なUIだって分かるのに馬鹿だよね本当

ストアアプリやUWPは「打倒××」からスタートしてるから機能性が
ないがしろにされている部分があるが、リボンUIはそうじゃないのに。

リボンUIがそれなりに合理的なのはわかるよ
それ以前のツールバーUIよりは合理的でないだけで

>リボン
Excelを始めとしたOfficeアプリには向かないと思った
リボン自体を大量のタブで切り替えるのはやめた方が良い

全部が一画面内に収まる（or普通は使わない部分だけ別タブに切り分ける）なら、悪くないUIだよ

>>314
それは逆で、リボンはOfficeのようにある程度多機能のアプリにしか向かない。
ワードパッドみたいな単純なアプリに適用してもメリットは少ない。
作る側の負担も大きいしね

VSは多機能だけど

多機能になってもF5押すだけ

リボンは各要素が無駄に場所を取るからページ切り替えが必要になる
無駄に場所取る原因は文字による表現を入れるから
文字表現を入れなきゃならないのはメニューバーを無くしたから

というわけで、メニューバーを導入して場所を取る文字表現はそちらへ移動させる
そうするとツールバーで良くなるので、ページ切り替えはなくせる
問題解決

そもそもリボンUIはリッチなパーツを載せるには高さが足りてない
http://blogs.adobe.c.../Ps_CC_workspace.png
このようなリッチなUIはリボンに載せれない
なんで結局、ボタン+文字、という構成になりがち
文字が無駄に場所を取るからページ切り替えが発生する
しかし文字を無くすわけには行かない、何故ならメニューバーを無くしたから
ここでしか機能を文字で表現する場が無い
だがあまりに長い文章だと場所を取りすぎるので、片言の文字表現になる
アプリに慣れてないユーザーからしたら、もっとしっかりした文章で説明してほしいし
慣れているユーザーからしたら、片言の文字表現など場所を取るだけで無駄
実際ページ切り替えが発生するわけで

頻度による分類もある
多くのアプリがそうであるように、ツールバーは良く使う機能だけを厳選して載せる
一方メニューバーは使う頻度によらず網羅的に階層で機能を載せる
なんでツールバーを省スペースに出来る(からページ切り替えが無い)
使う側からしても、良く使う機能はページ切り替えなしに
ツールバーからアクセスできて便利だし、余り使わないうろ覚えな機能は
メニューバーの十分な長さの文字表現で説明してくれたほうが有り難い

ところがリボンUIは網羅的なメニューバーが無いので
リボンUIに全ての機能を載せきらなくてはならない
頻度の低い機能でも、網羅的に載せないと、アクセスする手段が無い
となれば先の片言の文字表現云々と合わせて、場所を取ることは避けられない
その結果、ページ切り替えなわけ

実世界でも、あるいはプログラミングでも、おおよそすべての事で、二つの要求があって
それは、空間的な考え方と、時間的な考え方
当然UIも例にもれず

まず空間に着目して、機能ごとに分類して纏めたいという要求がある
じゃないと、何がどこにあるか分からなくなるから
それとは別に実際の作業手順に伴った時間軸的な考え方もある
その点リボンUIはツールバーに劣る
何故ならページ切り替えがあるから
ツールバーのように頻度の高い機能を厳選して小さなボタンを沢山並べたほうが良い
機能による分類も、ツールバーは複数同時に表示できるので問題ない

しかしながらよくよく考えてみるとリボンUIは
「ツールバー+片言の文字表現+ページ切り替え」
であって、メニューバーがあれば 片言の文字表現 も ページ切り替え も無くせるので
メニューバー+ツールバーでいいじゃん、となる

まあ、メニューバー+ツールバーの見た目がダサイってのは解るんだけどね
見た目を大事にした結果、使い勝手が悪くなってちゃ意味が無い

mspaintのリボンUIは割と好きよ

UWPじゃ公式extensionでMenuサポートされたし、ToolBarだって横スクロールするようなものもCarouselコントロールで簡単に実装できる
https://www.microsof...p/9nblggh4tlcq?rtc=1
DataGridもサードパーティー製のものが Apache Licenseで公開された→https://github.com/telerik/ui-for-uwp

Windows10オンリー以外の問題は粗方解決したようだな

>>318-321
前も書いたけど、実際に使いもせずに頭の中だけで考えているとこうなる。
だーから、ウダウダ言ってないで一日ワードでもエクセルでも実際使ってみろと（笑）

まあ、これも以前書いたけど、頭の中で考えるだけでも、従来のツールバー＋メニューの問題点を
理解していれば、どうしれリボンUIなのかはある程度わかるはずなんだけどね

Excelなんざ嫌というほど使っとるわ('A`)

まあ、XPのルナ以降のスタートメニューの使いづらさとか、メトロやUWPの惨状を見てれば
MSにUIのセンスがないのは事実だと思うけど、物事是々非々で見られなくなったら
2chでウヨサヨやってる頭の悪い連中と同レベルだ。

さすがにオフィスはMSのドル箱だけあって、リボンUIはそれなりにドッグフード食って作ってるのが分かる。
2007の時はちょっとチューニング不足だったけどね。
それでも2003のツールバーよりだいぶマシだ。

もっとドッグフード食いたければVSもリボンUIにすれば？
猛烈な大反対にあったらしいけど

１０年前のリボンUIを未だに騒いでいる人って・・・

エクスプローラのリボンUIとか全く機能してないしな
誰も使ってないと思うけど(ショートカット覚えてるから)
無理に使おうと思っても
コピー、貼り付け、削除、などのメインコマンドが並んでるページと
表示切替が別ページになってるとか、もう機能してないね

多分MSのリボンUIのガイドラインで決めてあるんだろうけど
メインのページと表示のページが別って時点でね
表示切替はどのようなアプリでも頻繁に使うものなのに
仕方が無いからステータスバーに表示切替を載せてるのな
MS公認で機能してないって事なんだよ

しかも今まで網羅的な機能へのアクセスを提供していたメニューバーが無いから
どうでもよい機能までリボンUIに載せてて、煩雑なことこの上ない
必要そうなのだけに纏めたら十分1ページに収まるでしょ
それが無駄に3ページもね、メニューバーが無いからそうなる

エクスプローラのような比較的シンプルなアプリですらこのありさま

一方でメニューバー+ツールバー方式は、よほどのアホが作ってもキレイにまとまる
方式的に優れているから、自然とそうなる

リボンUIが良いといってる人もページ切り替えは面倒に違いないんだよ
ページ切り替えが発生する原因は、文字表現で面積を食ってるのと
マイナーな機能まで網羅的に載せてるのと、の2つあるんだが
その両方ともメニューバーを無くしたことに起因してるんだよ
だからメニューバーを追加して取捨選択してページ数を減らす最適化していくと
ツールバーに戻る

逆にメニューバー＋ツールバーの組み合わせは、余ほどの馬鹿でもない限り
何も考えなくても、普通の使いやすいUIに纏まるんだよ
方式的に優れているから、適当にやっても上手くいく

一方でリボンUIは方式的に破綻しているから、使いやすくするためには
ものすご〜く考えないとダメだし、方式的な欠陥は根本の問題なので
考えてもダメなものはダメ、どうやっても結局ページ切り替え
そのページ切り替えもメニューバーを模範したページ構成なので
機能による分類であって頻度による分類じゃないから
「表示」が別ページになるなど、実際の作業フローに即してない格好になる
だから結局どうやっても無理で、当のMSもステータスバーに表示切替を載せてる
こういったことがありとあらゆる場面で発生する

プログラマ的な観点から見て、ど〜なんよ、と
方式的に優れているから基本的な平均点が高く、適当にやっても上手くいきがちな方式と
方式的に破綻しているから使いこなしに非常に苦労して
しかもせっかく頑張っても結果並み以下にしかならない方式と
どっちが魅力的かって

言いたい事は解るけど
2chで長文連投は、言ってる事がどんなに正しくても同意を得られなくなるから辞めとけ

分からないってw
ただの食わず嫌いw

Office、とくにワードにはリボンUIは従来のUIより適していることは
1時間使えば馬鹿でも分かる。

もちろんある程度実用的なドキュメントを書く場合ね。
図表も装飾も何もない文章ならリボンなんかいらない

リボンはノーコメ
「設定」に代表されるなんちゃってフラットデザイン採用した奴は
死んで生き返ってもう一回死ね

WPFでリボンUIを実装出来るとは言え、リボンUIそのものの良し悪しだとかUI論とかはスレチだろ。
まったく脱線するなとは言わないけど、いい加減しつこいぞ。

Officeユーザの大量の移行拒否もすごかったが、VS開発者でさえ拒否してる。根本的に欠陥品なんだよ。
合理性を理解できない奴が馬鹿とか、Windows市場でジョブス論理は通用しないよ。
シンプルに拒否られるだけ。信者じゃないんだから。

>>335
これ前も書いたけど、もうオフィスユーザーにアンチリボンUIなんていないよw

VSみたいな開発ツールにリボンが向いてないことは自明だから、将来も採用されることはないだろう

個人的にはリボンってあまり好きではないってくらいの存在なんだけど、従来メニューとの
多少の善し悪しを論じてもあまり意味がないと思ってて、従来メニューを過去のものにするくらい
広く支持されてるかどうかってところが大事だと思うんだよな
正直MS以外があまり積極的に取り入れてる感じはしないし、あまり支持されてないなら、
いたずらにUIの種類増やして混乱させただけの存在だと思うわ
道具の世界では従来のものが必ずしも最善ではなくても、「継続」する事が時には大事だよ

現に全然広まってない事実を無視するの？
未だにメニューバー+ツールバーが大多数
広まるには随分な時間が有ったはずだろ？
いつもはWindowsのルックアンドフィールをマネするのが大好きな
Linux界隈もガン無視
フリーソフト界隈も少なくとも俺のPCにはリボンUIなフリーソフトは一つも入ってない
まぁWeb中を探せば一つや二つは出てくるかもだが圧倒的少数派
まずこの現実を受け止めてくださいな

Officeには合理的でVSには合理的でないとか言ってることがオカルトにしか聞こえないよ。
VS陣営はOfficeの失敗を鼻で笑ってるよ。多機能なアプリからメニューを削除するなんて馬鹿げてるって。

>>337
だからオフィスユーザーには支持されてるってw

何でも適材適所な訳で、リボンUIは万能じゃないが、オフィスには向いてる。
それは実際に使ってみれば分かるが、使わないと分からない。

ネトウヨはよくネトウヨなんて存在しないって言ってる。同じ匂いがする。

>だからオフィスユーザーには支持されてるってw
Officeが支持されてるのであって、リボンが支持されてる訳ではないのでは？
オレもリボンのOffice使ってるけど、従来のショートカットを指が覚えてるからさほど
不自由を感じないってだけで、別にリボンは支持してないw
たぶん大概の人は善し悪しはどうであれ、慣れればどうにかなるから使ってる程度の話で、
積極的に支持してる人が多数派とは思えんのだけどね

>>342
2007が出た当初に散々あった拒否反応が2010の時代にはほぼ消えていたのは確か。

Win8/10のUIに対する不満が今でも消えてないように、
本当は使いづらいけど仕方なく使わざるを得ない人がいるなら、
今でも不満を言い続けている人がいると思うが、ネット上でもそんなの見たことないよ。

っていうかねえ、MSにとってもオフィスは特別だから、本当に不評ならいくらMSでも
リボンを廃止するか、少なくともオプションで旧UIを選択できるようにとっくにしてるよ。

ちなみに、俺自身2007の時代はリボンUIは使いづらいと誤解していた。

しかし、「VSでは使われてないじゃないか」ってこれオフィスろくに使ってないことを
語るに落ちてるよねw

使ってればリボンUIがVS向きじゃないことなんか自明過ぎるよ

>ネット上でもそんなの見たことないよ。

今まさに、ここに沢山居たじゃねーか
お前それらに反論してたんじゃねーのかよ
見たことないってどういうことだよ
お前ひとりで頑張ってて四面楚歌と言ってもよい状況なのに
おかしなことを言うよな

自分は、MSのオフィスユーザじゃないし、
エクスプローラのリボンは使いにくいと思ってる派だけど、
LibreOffice 5.3 では**実験的な機能**としてリボンUIが実装されてる

http://www.softanten...are/libreoffice-5-3/

一部の分野の一部のユーザには使いやすいのだろうというのも認めるし、
メニュー方式が使いやすいと考える人もいるということでいいじゃないか

ただし、フラットデザインの「Windows の設定」、オメーはダメだ

>>343
それは何年たっても延々と批判を言い続けるほどリボンを大嫌いな人が多数派じゃないって
だけの話で、リボンが支持されてることの証拠にはまったくなってないよw
どうも君と議論しても時間の無駄みたいだから、このへんで。

LibreOfficeとしてはMSOfficeに使用感を似せたいっていう一部要望があったんでしょ
パチもんの宿命

リボンはいいにしても例の「設定」に関しては本当に何がしたかったのかすらよく分からんからな…

>>345
だから使ってない奴の批判なんて何の意味も価値もない
使ってる奴は不満持ってないから

>>349
Windowsのキメラ化w

使ってないという勝手な決めつけと
使ってる奴は不満を持ってないという勝手な決めつけ
このような頭じゃないとリボンUIを素晴らしいと感じない
って結論が出たな

リボンUIに需要があればWPFも普及したのになw

WPFにおいてはリボンがコンポーネントとして標準化されたのってだいぶ後だし
現在にいたるまでMS側からもこれ使っていけという扱われ方もしてなくね

リボンは標準化されたと言っていいのか？
標準でツールバーにも入れてもらってないのに
現実は非推奨状態

リボンはUWPでも採用されてない

まあ2012でようやく他所からもって来なくて良くなったという意味でしかないか>WPFでの標準化

普及しなかったのってユーザー側の評判以前に
MS自身が積極的にデベロッパーに使わせようという素振りが無かったのが一番大きいと思うで

なもんでリボンに重要があればとかリボンの悪評のせいでとかの文脈でWPFが出てくるのがさっぱりわからん

>>356
そんなことは誰も言ってないんじゃない？

>>357
言ってるんだよなあ・・・
「イヤ全然関係なくね？」って思っただけだからあんま絡む気もねえけど

> リボンUIに需要があればWPFも普及したのになw

> 逆にWPFが普及に失敗したのは、ExcelがリボンUIを採用したせいで悪い手本になってしまったからだろう。

認めたくないものだな、若さゆえの過ちというものを。

俺はXAML系の技術はSilverlight切り捨てのときに見限ったなあ
あのとき思い切ってWebへの転向を決断して正解だった
あの状況でWPFの方なら大丈夫と思うのは正直どうかしてる

過去ログ見てみたらこんなレスが

921 名前：デフォルトの名無しさん[] 投稿日：2014/08/23(土) 15:42:12.35 ID:qd6ZCp8I
HTML5がくるっていってどのぐらいかね。
開発者的にはHTML5で作るメリットは何もないし、いろんなとこで動かせるメリットはあっても結局パフォーマンスとかデバイス・プラットフォームに最適化出来ないとかでネイティブに対する需要は亡くならんよ。しばらくは。

921 名前：デフォルトの名無しさん[] 投稿日：2014/08/23(土) 15:42:12.35 ID:qd6ZCp8I
HTML5がくるっていってどのぐらいかね。
開発者的にはHTML5で作るメリットは何もないし、いろんなとこで動かせるメリットはあっても結局パフォーマンスとかデバイス・プラットフォームに最適化出来ないとかでネイティブに対する需要は亡くならんよ。しばらくは。

924 名前：デフォルトの名無しさん[sage] 投稿日：2014/08/23(土) 21:54:13.82 ID:jO0zpBoJ
むしろWebというかHTML5に過剰な期待を持ってる人の方が2周遅れでしょ。
認識が5年はずれてるよ。

928 名前：デフォルトの名無しさん[sage] 投稿日：2014/08/23(土) 23:43:29.58 ID:hPpI01dm [2/2]
>>925
そうだね。5年後に答え合わせしようね。

ぬけてました

925 名前：デフォルトの名無しさん[sage] 投稿日：2014/08/23(土) 22:14:47.48 ID:JJDGD5m1
などと前世紀から何か息巻いた声が聞こえますが
イヤーピースするなりして流して下さい
もうじき歴史の彼方に消え去るはずです

開発側としては、「嫌だけど世間の流れなので仕方なく使う」みたいな印象　＞HTML5

歴史のかなたに消え去る準備はできましたか？

HTML5を嫌がる人への文句の前に
いつまで経っても協調せず、ブラウザ間の動作の違いを無くそうともしないWebブラウザベンダに文句を言ってくれ

まだ5年後まで2年あるからその間にWPFが盛り返せばいい（）

3年の間にjsで天下を取っていたjquerryが死んだことに驚き
jquerry使うと老害扱いされる

>>361
唐突に何？w

正直web系の技術の現状とか全然追えてないからよく分からんが、
HTML5が普及し始めた頃、どこぞのITの社長さんが「HTML5も結局互換性問題がカオスで
使い物にならねえ」って書いてた通りになってるんじゃないの？

>>367
変化激しい世界なんだなw

web系の人はどうやって技術のトレンドを追いかけてるの？
今時雑誌とかないよね。

ITProとか@ITとかじゃないの　＞追いかける

このスレでもまだ時代がとまってるらしい
>>365
>>368
実質Chromeが標準ブラウザだから
それ以外はほとんど対応しなくていい

>>371
Chromeはファンも多いがアンチも多いよ。
俺は大嫌い。あのUIのすべてが気に入らない。
ここ見ると多めに見積もってせいぜい4割ってところだろうね。
https://webrage.jp/t...og/pc_browser_share/
実際はもっと少ないんじゃないかと思うが...

いつも思うけど、web系の人ってドリーマーというか思い込みが激しいというか
自己陶酔系というか、およそエンジニアっぽくない人が多いよねw

>>372
計算できないのか？
世界でChrome以外のブラウザかき集めても2〜3割りでそれ以外Chromeって事だろ

Chromeが云々よりIEが無視できる時代になった事が重要
てかweb系と聞いてブラウザの話しか出て来ないのが既に寂しい

日本の数字ならIEもFirefoxも無視できない数だし
企業だとIE強いよな

俺は趣味で見てる程度だけど仕事でwebのフロントエンドやってる人は大変だと思う
mvvmも一瞬ブームになったけどもう違う方向に舵を切られた
フロントエンドでmvvmは時代遅れ

>>373
何でそう喧嘩腰かねw
言ってる傍からドリーマーだけど、どこをどう計算してもそんな結果にならんよw

そもそも集計方法が分からないが、この手の集計は「意識高い系」バイアスを疑うのが常識。
少なくとも日本に限れば、わざわざChrome使うような意識高い系（パソヲタともいう）がそんなに多いとおもえない。

>>371
>それ以外はほとんど対応しなくていい
趣味で作ってるならまだしも、仕事でこれは有り得ん
それが出来るならどんなに楽な事か

現実はPCでのIE・Fx・Chrome・Safariに加えて、主要な各スマートフォン&タブレットでも動作テストさせられるんすよ
俺がいた現場ではそうだった('A`)

>>377
偏見（バイアス）にまみれてるのは君だろｗ
今はweb見るのは大体スマホがメイン
androidのメインブラウザはChrome
ほとんどの人はChromeを普通に使ってる

Chrome　普通の人
FireFox　パソオタ
IE Edge　情報弱者

>>379
>>372の集計はPCだけ。

今時メインはスマホだというのは一理はあるが正しくない。
それはwebページの種類次第でしょう。

本当、エンジニアっぽくない思考回路のお方だね。

さっきのTOP10集計すると
Chrome 54.98%

その他 25.99%
(FF約 10% IE11 7.22 )

能力者気取ってるがそれって地雷を踏む能力だろ。

>>379
iOSの標準ブラウザはSafariだし、AndroidでもAPIの対応度が標準ブラウザでも違ったりする
しかも、モバイルとブラウザでは表示や機能も変わる
IEはまだしも、Firefoxは対応すべきだし、Edgeだって利用者はいる

age

リボンUIはやはり消えてなくなるのか。不便でしかなかったからな。

リボンは言っても１０年前に登場したUI。新しいハンバーガーメニューやアプリケーションバーのように
普段は説明文を隠してワンタッチで見られるUIについての議論とか無いのかな？

>>386
それ新しいかね？
そんなUI初代macの」時代からあった気がするんだけど

>新しいハンバーガーメニューやアプリケーションバーのように
>普段は説明文を隠してワンタッチで見られるUIについての議論とか
みんな議論する価値すらないと思ってんじゃないの？

リボンの無いExcelなんて使う気にならないさ。

>>387
漢字Talkにそんなもんあったっけ?

初代Macの頃は漢字Talkなんてなかったぞ

マカーがWPF触ってるのか。やはり地雷だったか。

>>392
地雷じゃないけどXAMLが冗長過ぎるぞ。

冗長と言っても単に記述が長いだけじゃね？
補完は十分に効くし、人が触るものじゃないFormsよりははるかにましになったと思うが。