Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Calling Windows 10 APIs from a WinForms or WPF application

blogs.windows.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Calling Windows 10 APIs from a WinForms or WPF application

#51

Post by CoolGuySteve »

diimdeep wrote: post #16

Look at this screenshot of context menus in Windows 10 https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.

The simplest answer is that Microsoft's software mimics the design of the organization with multiple fifedoms building their own toolkit, causing fragmentation.

We already know that the Office and Windows teams have different GUI toolkits from reports from inside the company. But there is evidently a lot more fragmentation than just those 2 groups.

What I find more interesting is that Google products are starting to feel similarly fragmented. Project fi, Android, Plus, and Search all look and behave differently. My damn phone gets SMS on Hangouts and the Messenger app, my voicemails come on the phone and hangouts. None of it makes sense.

We can all agree that inconsistent GUIs are bad, but it seems like a problem you have to solve from a top down organizational perspective, which might not obviously align with the business.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#52

Post by cptskippy »

diimdeep wrote: post #16

Look at this screenshot of context menus in Windows 10 https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.

That collage of screenshots is kind of misleading. There are issues however those screenshots are scaled, the theme is different from one to the next. Here's a more fair comparison: http://i.imgur.com/nCmOrmn.png

Re: Calling Windows 10 APIs from a WinForms or WPF application

#53

Post by nightski »

CoolGuySteve wrote: post #51
diimdeep wrote: post #16

Look at this screenshot of context menus in Windows 10 https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.

The simplest answer is that Microsoft's software mimics the design of the organization with multiple fifedoms building their own toolkit, causing fragmentation. We already know that the Office and Windows teams have different GUI toolkits from reports from inside the company. But there is evidently a lot more fragmentation than just those 2 groups. What I find more interesting is that Google products are starting to…

I'm actually not all that convinced inconsistent GUIs are bad. Especially when the main difference is the appearance. They all function identically.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#54

Post by pjmlp »

recursive wrote: post #48
pjmlp wrote: post #37

Earlier quoted context omitted.

I have a better idea, drop JavaScript from Web and leave it as pure HTML/CSS.

It's as easy as disabling it in your browser options. You can purify your own web in seconds!

It doesn't help if the web site is JavaScript only!

Re: Calling Windows 10 APIs from a WinForms or WPF application

#55

Post by tbrock »

CoolGuySteve wrote: post #51
diimdeep wrote: post #16

Look at this screenshot of context menus in Windows 10 https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.

The simplest answer is that Microsoft's software mimics the design of the organization with multiple fifedoms building their own toolkit, causing fragmentation. We already know that the Office and Windows teams have different GUI toolkits from reports from inside the company. But there is evidently a lot more fragmentation than just those 2 groups. What I find more interesting is that Google products are starting to…

The Excel team even has their own compiler!

Re: Calling Windows 10 APIs from a WinForms or WPF application

#56

Post by cm2187 »

diimdeep wrote: post #16

Look at this screenshot of context menus in Windows 10 https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.

The philosophy of WPF is that you do all of the UI yourself. It gives great flexibility to make anything look like anything else, but it provides a subpar experience if you mostly need your app to be functional, vs winforms. And as you point out it kills any form of standardisation. What's missing to WPF is good tooling. The current tooling in VS is nothing more than an XML editor, without a useful intellisense, and reverting to a blank page if you need to customize any control.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#57

Post by cm2187 »

wtallis wrote: post #28
nikanj wrote: post #20

Earlier quoted context omitted.

+ All your apps look the same - Half of your apps are no longer supported I think mostly everyone who uses their computer to make their living (ie the prime audience of MS) does not consider this a good trade-off

That argument works to an extent, but all of those screenshots are from components of the operating system itself, not third-party apps. Surely Microsoft has the resources to keep the core components of their OS up to date, and if not, they should devote fewer resources to creating new APIs and more to using them. Deprecating all but one GUI framework doesn't mean breaking all but one. It just means picking one optio…

And what I don't understand is that they are capable to create tools to create very productive UI, but do not seem to be using them themselves. Refreshing the appearance of a menu should take one of their intern a day at most.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#58

Post by cm2187 »

tbrock wrote: post #55
CoolGuySteve wrote: post #51

Earlier quoted context omitted.

The simplest answer is that Microsoft's software mimics the design of the organization with multiple fifedoms building their own toolkit, causing fragmentation. We already know that the Office and Windows teams have different GUI toolkits from reports from inside the company. But there is evidently a lot more fragmentation than just those 2 groups. What I find more interesting is that Google products are starting to…

The Excel team even has their own compiler!

The problem is that they keep compiling the same version of Excel, just changing a little bit the color scheme each time.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#59

Post by frik »

diimdeep wrote: post #16

Look at this screenshot of context menus in Windows 10 https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.

In Win9x and even WinXP Luna theme everything looked the same. Even as new as Win7 with its theme or the classic UI in Win7 99% looked very consistent.

But Microsoft tipping point was Win7, everything beyond 2009 was put the former UI and UX guidelines to the trash bin and it seems color blind designers and managers with no taste and understanding are working on the Windows UI. Win8 and Win10 are now and inconsistent mess of dozens of legacy UI frameworks. The little maintained Win32 API is still the most used and best in class - like 99% of applications are coded in C/C++ with Win32API. All the small scale enterprise dotNet apps with legacy WinForm or legacy WPF in legacy dotNetFramework or the new dotNetCore mess are used rarely outside of a small niche market. (all of my hundreds of applications on Win7 are Win32, I see no dotNetFramework in ProcessExplorer - would be highlighted in yellow). And the new WinRuntime aka UniversalRuntime seems to be a trainwreck as well, with limited to to the failing WinStore - clearly a success story ;) Oh and there is the failed Silverlight and the non-public UI API from Win7+ that is used in various new UI elements like Help, Addon dialog of IE10+.

It would be so nice if they once again focus on a nice looking UI theme, and focus on an consistent UI again. In Win95 to WinXP (or Win7) days everything looked to familar and nice put together. If one knew one Windows application, he knew how to use all other applications without searching around or reading a manual. Please surprise me with a nice UI, do away with thr evil phone home features and show that you value the user as your customer and not as dump sheep products. For this to ever happen, they need a major management change and turn-around.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#60

Post by frik »

cm2187 wrote: post #58
tbrock wrote: post #55

Earlier quoted context omitted.

The Excel team even has their own compiler!

The problem is that they keep compiling the same version of Excel, just changing a little bit the color scheme each time.

Word, Excel, PowerPoint were all coded between 1989 and 1993. And received major update with Word 6 and Office 95 and 97. Basically Office 97 was feature complete. Very little has changed since then. The ribbon bar and all the other minor increment improvements are really minor compared to the changes up to Office 97. Office uses it's own UI library. Using Word 6 in Win95 shows floating toolbars in Win3.1 UI theme. Office 95 had an italic title bar. Using Office 97 in WinXP or Win7 shows and Win95 UI theme.
Post reply on HN