It was a good idea. Thanks.

Now all they need to do is add the bit rate, given that after a driver update i have to change the bit rate on both my screens to 10bit this will add 3.5 secs to my day opening 2 apps every time theres a driver refresh

The Goose:

Now all they need to do is add the bit rate, given that after a driver update i have to change the bit rate on both my screens to 10bit this will add 3.5 secs to my day opening 2 apps every time theres a driver refresh

I don't think its about saving 3.5 secs, it's about not hiding everything in menus. I find W10 much more difficult to configure compared to W7, the menus are atrocious. These options are hidden inside old menus that look like they are from WXP or something.

Just think how many people would lose their jobs if designers didn't flip flop all the time. 1. Design out a critical piece of functionality, developers implement. 2. Support channels flooded with questions and complaints - support/CRM need to get involved. 3. A year later, design the critical functionality back in, developers implement. The whole IT community should be grateful for designers!

Now if only more games would let you select a refresh rate in-game.

What's been changed that's where the refresh rate setting is anyway isn't it? EDIT: Yeah I'm not seeing a difference here unless people were going into the device manager and display hardware properties for this for some reason?? (Or the GPU control panel which should work just fine too.) https://abload.de/img/test01mxkql.jpg EDIT: Is this backported as some funny thing Microsoft just kinda flipped on for 20H2 or something?

I would like to see more responsive XML interfaces with less white on wide and ultra wide screens.. BTW 5 years to move a drop-down value choice...

The Goose:

Now all they need to do is add the bit rate, given that after a driver update i have to change the bit rate on both my screens to 10bit this will add 3.5 secs to my day opening 2 apps every time theres a driver refresh

Maybe you could create a .reg or .bat file to force-adjust it and have it run at boot. Not ideal but better than going out of you way to fix it every time.

Silva:

I don't think its about saving 3.5 secs, it's about not hiding everything in menus. I find W10 much more difficult to configure compared to W7, the menus are atrocious. These options are hidden inside old menus that look like they are from WXP or something.

Yeah, I'm not a fan of the new control panel, because too many things are missing. I've found myself pretty much entirely depending on the search tool to get anything done. It's also just really cumbersome, particularly if you're trying to configure multiple different things at the same time.

so, 2 click (1. open adaptor properties windows, 2. change to corresponding tab) less compare to current build

schmidtbag:

Yeah, I'm not a fan of the new control panel, because too many things are missing. I've found myself pretty much entirely depending on the search tool to get anything done. It's also just really cumbersome, particularly if you're trying to configure multiple different things at the same time.

Yea, some of the settings in the new control panel are all over the places.

Alessio1989:

I would like to see more responsive XML interfaces with less white on wide and ultra wide screens..

That`s XAML, and the responsiveness is not about XAML, but about WinRT - completely new runtime, new OS API for UWP apps. XAML is just a markup language to hold the UI (and used not only in UWP apps, but in legacy desktop apps written with WPF for user interface). But of course, XAML is based on XML.

JonasBeckman:

What's been changed that's where the refresh rate setting is anyway isn't it? EDIT: Yeah I'm not seeing a difference here unless people were going into the device manager and display hardware properties for this for some reason?? (Or the GPU control panel which should work just fine too.) https://abload.de/img/test01mxkql.jpg EDIT: Is this backported as some funny thing Microsoft just kinda flipped on for 20H2 or something?

You are on an insider version, so it appears that they implemented this on an earlier insider version, but are just now talking about it.

Yeah 19041 / 19042 are fairly similar to how the previous build was handled (Shared updates and a enablement package that activated the new build features.) and I'm thinking a lot of focus is on the new builds for next years update of the OS now so 20H2 can't be far off from full release. Same stuff in the cumulative updates which are now out for all users as of the latest monthly patch rollout and update cycle but there is that enablement package which bumps the build up by one and activates these extras for 20H2 and that also does a install for Edge Chromium as part of that process. There's not much with this though at least that Microsoft has listed far as I can find. Theme aware start menu tiles. Alt-tab support for Edge tabs. Quick access to pinned sites in Edge. Personalized task bar for new accounts. Improved notifications. System page in the control panel is migrated to the settings app. Tablet experience improvements for 2-in-1 devices. Chromium Edge as the new default browser. Modern Device Management policies. Think that's it. (Not a huge fan of re-linking control panel settings to open the app instead and a page there but the rest is fairly small changes to the OS.) One never really knows though what else is enabled with this even if the underlying code is identical with this .572 or KB4579311 update along with the servicing stack update and updates to .NET and the final update for Adobe Flash before it's discontinued. Servicing stack is this. https://support.microsoft.com/help/4577266 Cumulative is this one. https://support.microsoft.com/help/4579311 And .NET 3.5 / 4.8 just to throw that in too cause why not. 😛 https://support.microsoft.com/kb/4578968 Interesting if they did include this feature into the 20H2 update instead of the 21H1 builds though, also taking quite a while for the actual enablement pack here to hit public release for 20H2 too which I think started around the .450 somewhere updates and said enablement pack which has only been updated once so far just adding a newer Edge Chromium version into it. Can't be too long now though, 21H1 should wind down to bug fix mode too soon and then launching in April / May I assume is the idea with this cycle although it sounded like Microsoft considered changing back to a yearly rollout but that didn't happen. EDIT: All that said though there's several thousand changes between Windows 10 builds and numerous tweaks and adjustments and even the build announcement is a highlight of specific features so the full number of changes usually takes a while to show up compared to what Microsoft is highlighting.

mbk1969:

That`s XAML, and the responsiveness is not about XAML, but about WinRT - completely new runtime, new OS API for UWP apps. XAML is just a markup language to hold the UI (and used not only in UWP apps, but in legacy desktop apps written with WPF for user interface). But of course, XAML is based on XML.

WinRT is just a (almost) 0-overhead C++ wrap upon a part of Winapi (win32+COM). You can use almost every WinRT API in common desktop applications too and not having those shit GUI results. Those interfaces are crap XAML (which is just XML with some shit resulting in auto-compiled code) usage. You can write hard-coded GUI in WinRT too without having those shitting results, plus you usually don't use both WPF and XAML in the same application, unless for some reason you are migrating a WPF GUI to XAML. The fake responsive design used in almost all Microsoft UWP apps and in the "new" control panel are just terrible design choices and poor usage of their own platform tool-sets.

I could change my refresh rate in Windows 98.

Ghosty:

I could change my refresh rate in Windows 98.

and without rebooting the system! (unlike windows 95)

Alessio1989:

WinRT is just a (almost) 0-overhead C++ wrap upon a part of Winapi (win32+COM). You can use almost every WinRT API in common desktop applications too and not having those crap GUI results.

https://en.wikipedia.org/wiki/Windows_Runtime

Windows Runtime (WinRT) is a platform-agnostic application architecture first introduced in Windows 8 and Windows Server 2012 in 2012. WinRT supports development in C++/WinRT (standard C++), C++/CX (Component Extensions, a language based on C++), Rust/WinRT, JavaScript-TypeScript, and the managed code languages C# and Visual Basic .NET (VB.NET). WinRT applications natively support both the x86 and ARM processors, and may run inside a sandboxed environment to allow greater security and stability.

WinRT applications run within a sandbox and need explicit user approval to access critical OS features and underlying hardware. By default, file access is restricted to several predetermined locations, such as the directories Documents or Pictures. WinRT applications for Windows RT, Windows 8 and beyond are packaged in the .appx file format; based upon Open Packaging Conventions, it uses a ZIP format with added XML files. WinRT applications are distributed mostly through an application store named Microsoft Store, where WinRT software (termed Windows Store apps) can be downloaded and purchased by users. WinRT apps can only be sideloaded from outside Windows Store on Windows 8 or RT systems that are part of a Windows domain, or equipped with a special activation key obtained from Microsoft.

https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide

How the Universal Windows Platform relates to Windows Runtime APIs If you're building a Universal Windows Platform (UWP) app, then you can get a lot of mileage and convenience out of treating the terms "Universal Windows Platform (UWP)" and "Windows Runtime (WinRT)" as more or less synonymous. But it is possible to look under the covers of the technology, and determine just what the difference is between those ideas. If you're curious about that, then this last section is for you. The Windows Runtime, and WinRT APIs, are an evolution of Windows APIs. Originally, Windows was programmed via flat, C-style Win32 APIs. To those were added COM APIs (DirectX being a prominent example). Windows Forms, WPF, .NET, and managed languages brought their own way of writing Windows apps, and their own flavor of API technology. The Windows Runtime is, under the covers, the next stage of COM. At the actual application binary interface (ABI) layer, its roots in COM become visible. But the Windows Runtime was designed to be callable from a great range of different programming languages. And callable in a way that's very natural to each of those languages. To this end, access to the Windows Runtime is made available via what are known as language projections. There is a Windows Runtime language projection into C#, into Visual Basic, into standard C++, into JavaScript, and so on. Furthermore, once packaged appropriately (see Desktop Bridge), you can call WinRT APIs from an app built in one of a great range of application models: Win32, .NET, WinForms, and WPF. And, of course, you can call WinRT APIs from your UWP app. UWP is an application model built on top of the Windows Runtime. Technically, the UWP application model is based on CoreApplication, although that detail may be hidden from you, depending on your choice of programming language. As this topic has explained, from a value proposition point of view, the UWP lends itself to writing a single binary that can, should you choose, be published to the Microsoft Store and run on any one of a great range of device form factors. The device reach of your UWP app depends on the subset of Windows Runtime APIs that you limit your app to calling, or that you call conditionally.

Alessio1989:

I would like to see more responsive XML interfaces with less white on wide and ultra wide screens.. BTW 5 years to move a drop-down value choice...

You mean like this? https://i.imgur.com/DBWBgd4.png

Alessio1989:

plus you usually don't use both WPF and XAML in the same application, unless for some reason you are migrating a WPF GUI to XAML

What are you talking about? XAML was introduced with WPF in 2006 and it offers such benefits that it became an "industry" standard to contain UI in XAML: https://en.wikipedia.org/wiki/Windows_Presentation_Foundation

XAML Following the success of markup languages for web development, WPF introduces eXtensible Application Markup Language (XAML; /ˈzæməl/), which is based on XML. XAML is designed as a more efficient method of developing application user interfaces. The specific advantage that XAML brings to WPF is that XAML is a completely declarative language, allowing the developer (or designer) to describe the behavior and integration of components without the use of procedural programming. Although it is rare that an entire application will be built completely in XAML, the introduction of XAML allows application designers to more effectively contribute to the application development cycle. Using XAML to develop user interfaces also allows for separation of model and view, which is considered a good architectural principle. In XAML, elements and attributes map to classes and properties in the underlying APIs.

When you create new WPF project in VisualStudio the initial UI created from template is always held in XAML, and you can edit it in special designer. If you remove XAML file from the project and create UI in the code you loose the ability to use UI designer. Also professional designers use Microsoft Blend - very powerful editor which utilises XAML files only. Also another thing which became a standard too - MVVM - is not possible without XAML files. So I have no idea what are you talking about. Maybe school projects can avoid using XAML files but professional ones can`t.

mbk1969:

https://en.wikipedia.org/wiki/Windows_Runtime https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide

I don't care about what you state or wiki, I care what I see in the SDK when I work with Visual Studio. WPF was born for .NET environment, so C#/VB.net (and no, it's was not native for C/C++, since you have to use that garbage of CLI language extension), another piece of garbage tool for people that don't know what the hell they are doing 'cause they are all but CS or real programmers (if you cannot deal with pointers and threads synchronization you are just a hobbyist or a hipster that wanna give itself a title that doesn't own). The so called "designers" should go back in kindergarten and do some finger-paint. Blend is another piece of shit for making more crap & slow interface with XAML. Now it's directly compiled into per-packed shitcode. Yes using that native C++ wrapper around Winapi with the old good COM (WRL is just another mid-level wrapper too, so I don't count it) works better than CLI and .NET, but doesn't matter. Oh yes, I almost forgot it...before there was another piece of garbage between C++/CLI and native WinRT called C++/Cx, another piece of garbage that could be easily outperformed by C# and .Net. Fortunately someone had enough of that shit and made proper port (well, it was almost a dismantling) called now "C++/WinRT" and now he works at Microsoft. And all that's was really.. dumb, since the WinRT was just per-compiled native code with meta-interface for C#/VB.NET/JS and that shit called C++/Cx, but Kerr work was also better than the closed piece of junk used inside at Microsoft itself that it become not only part of the current SDK but also the tool used ow at Microsoft, giving cleaner code and better performance.. This is also why you don't have any limitation and can made amazing interfaces with WinRT if you get rid-off of XAML. So yes, another failure for the managed languages team... and guess what, it was just a black-box upon COM interfaces using the good old WinAPI (one of the favorite ranting aim of some trash sites and their common viewers.. but that's another story of ignorance and the abuse of the internet from people that should go back to the abacus..). XAML interfaces are crap and the usage Microsoft made and continue to do into it's own UWP applications and the "new" (can be called new after 5 years even if it's not end at all?) control panel is shit too. XML-like based interface works for phone since you have just to do a dumb GUI. They sucks on PC since they cannot handle an enriched I/O environment of multi-resizable windows upon (multiple) screen of different sizes, form factors and capabilities, as well as the classic combo mouse+keyboard... So sorry, but you or any other "fake" tech site/journalist/wiki/self-satisfaction article/video made by MS will ever change my mind. I dealt with them even too much and I don't wanna go handling with them again.

* nvm *