Seems to me the automation bits could be implemented using attached properties/behaviors, which might be preferable to polluting the core APIs. Regardless, UIElement is really meant to be a lightweight visual element with minimal interactivity support. It wouldn't surprise me if automation support were implemented at a more derived level. FrameworkElement strikes me as a more appropriate place.
Definetely agree that UIAutomation is best implemented external to the Windows Libs, they definetely do pollute the API especially if you compare WPF/Silverlight code to the WinMD code. Also FrameworkElement in the current WinMD bits doesn't have any Automation as well, it's nowhere in the entire WinMetaData bits. Again it's early days in these api's life, so who knows maybe they will add it OR hopefully as you mentioned they'll be added as an external library for reference in your app when needed.
thanks soooo much SilverlightWPF guy. most interested in DirectUI, do you see it keeps all wpf controls, is that true can you see? maybe can you post picture of long ui controls in the reflactor your using???
I actually looked into this more by looking through the dependents within the actual Windows Runtime's and found that there is indeed native automation dll's that are referenced. So I'm guessing that the actual implementation does have automation BUT there is just no way in the current WinMD bits to inspect them.. Here is DirectUI.dll that depends on UIAUTOMATIONCORE.dll http ://farm4.static.flickr.com/3246/5835438921_a757931fc2_b.jpg
[purely personal opinion] From my perspective, we don't know who the consumers of the WinMD's are. The tooling story, the SDK's/Toolkits may abstract away these WinMD's from the ordinary developer. I know that we can easily consume these WinMD's in a C# project, thats what we're doing now in the examples. BUT that's not to say that thats the way MS are positioning these api's to be used on a large dev community scale. It could be that the dev/div have created SDK's/toolkits that wrap all these into higher level "UI Framework" that we haven't yet seen. All i was suggesting is that people shouldn't make assumptions on the way apps are to be built in Win8 based on the examples being built here, we need to wait till Build to see the "true" dev story which includes the tooling support (VS2012 & WinC++, Managed, Blend etc) p.s. Who knows maybe we are meant to use these WinMD's in the raw way your doing in your examples , thou i really hope not
You'll probably notice that it's a much reduced list BUT don't forget DevDiv will probably produce a toolkit too of controls. What's noticeably missing is the dreaded DataGrid Which is a very complex control. I wonder if it will ever make it into Jupiter, a datagrid sort of doesn't work well in the MOSH types of apps we've seen. Also don't forget that there will also be great third party shops that will churn out controls. DirectUI.Controls http ://xs.to/media/11873/464x2200 DirectUI.Primitives http ://farm4.static.flickr.com/3621/5842116822_965942352e_b.jpg
well, OK. but personaly I dont agree. I guess exposing directly to .NET is the exact reason of choosing .NET assembly format as the metadata format for WinRT in the first place. and comprehensive WinRT support is fully and deeply integrated into the .NET runtime and compilers, unlikely for a 'internal only' thing. and the framework built around WinRT is quite highlevel and complete, what will the benefits be if you build another 'framework' on top of this 'framework' ? bloated and redundant code ? of course you can build some 'higher level' framework like Prism for WPF/Silverlight but that's another kind of thing and not for everyone. plus, you may agree that the new C++ framework will be based on WinRT right ? then why should ms introduce more gap between native and managed world ? I can't see the benefits. why ? anything bad about the experiences of doing this ?
I agree with you that consuming these WinMD's directly and not through some new abstraction layer is the best approach. But as i mentioned , i have no idea how MS plan for us to consume these WinMD's. In the very revealing channel 9 video "C++ today and tomorrow" they talk about a single app using Native, Managed & Script. That is a completely new beast of hetrogenous app that sounds amazingly complex and, im guessing, definetely beyond anything we're building today. And that's all I'm trying to say, we have NO idea what MS is planning and no amount of hacking at Win8 will reveal this side of the story (i believe)... I really think that MS have some amazing tooling that sit's ontop of WinMD, XAML & ALL languages (native/managed) that will help us create this new class of immersive application. We have to keep in mind that the plan for Windows 8 is a single OS that spans 3 screens and the cloud, and in all honestly i can actually see them getting there. It's all about the tooling and how MS are going to enable us to create these immersive-hetrogenous-3-screen-cloud apps.
thanks !!! it not be complete yet i hope. none of listview treeview, virtualizingpanel virtualizingstackpanel wrappanel, combobox, flowdocument stuff how no gridviewcoloumn or splitter? maybe they not done yet?