Cross platform WPF


#22

I think wpf is slowed down for a good reason, it is mature, let’s not forget it’s been there for a long time (including internally in Microsoft long before it was shipped with .net). I’m pretty happy with the state it’s in and more development happening outside (third party controls etc). But having the source to port it would be nice.

It wouldn’t make sense to port it to mantle at all, having a DX12 renderer might make sense (it’s mantle-ish) and will be supported by all graphic makers (unlike mantle). Also don’t expect much out of it except maybe if you’re doing very very heavy 3D rendering in wpf. It wouldn’t change performance at all (you’d be hard pressed to find a case where you’re CPU bound on GPU operations in WPF, or even any case where you’re graphically bound at all vs limited by the speed of your own logic). It’s already very fast and the diference between DX and mantle is irrelevant since there aren’t thouthand of state changes per frame here, the big performance simply comes from the rendering being hardware accelerated vs previous software only solutions and from the well designed Framework and UI virtualisation.

Edit: as for crowdfunding that’s really not needed, if it was open sourced there would be a quick effort to port it i’m sure (i’d be happy to contribute personally as long as it’s open sourced in a way that lets you port it and doesn’t tie your code to the open source world, if it means i can use WPF as a compiled dll on other platforms without any patent / licensing issues i’ll be more than happy to work for it).


#23

Why would you want to port a UI framework that was specifically designed with Windows UI concepts in mind to platforms like Linux and Mac? Mac OS in particular has some very different UI paradigms that do not map well to the existing WPF APIs (system menu bar, anyone?). And then there’s the fact that the appearance and behavior of core controls differ, as do the platform’s style and layout guidelines. Assuming someone went to the trouble of developing a Mac theme for WPF, there would still be behavior inconsistencies with native controls, and control sizes and layout would often differ significantly from those of Windows. In the end, you’ll either end up with apps that clash noticeably with native apps (i.e., apps that feel like Windows apps running on a Mac), or you’ll end up crafting separate views for each platform, at which point you may as well have native front-ends.

It only makes sense to develop a cross-platform UI toolkit if you design it to be cross-platform from the beginning, and even then you run into lots of annoying limitations and behavioral differences (just ask the Xamarin guys). It makes much less sense to “graft” cross-platform capabilities onto a UI toolkit that was designed specifically around a single platform.

WPF as we know it will never run on anything other than Windows, nor should it. If the community wants to build a new cross-platform framework that’s inspired by WPF, then great, but there will need to be a lot of fundamental changes.


#24

Well the apps that micorsoft show case and everyone else showcase to show the power of wpf also look nothing like native windows apps??? why is that???
search google for wpf apps and you will almost never see system menu bar in them, because if all you want to use was a system menu bar what was the need for wpf.?
Can you do a simple thing for me?
Download mahapp.wpf nuget package for wpf and see what it does to your application.It gives your application a complete windows store apps look and feel. And mahapps is a community effort with a few people involved. So i do not see why someone can not emulate mac’s native look,feel and behaviour . This is one of the strenth of wpf that one can change the look,feel and behaviour of wpf controls and write new controls easily. And remember wpf controls are not native controls, their default templates and styles emulates native windows controls.


#25

disagree with all of that, WPF doesn’t “feel like Windows” to begin with, it feels like whatever you want and more like a low level access high level concept UI Library. WPF would be great for UIs that don’t feel like a specific OS, just having the actual same app and same look on all platforms while not having to go for a crappy look (since WPF does it’s own rendering, you’re not tied to whatever native UI is available).

As it’s stated on the other thread WPF wouldn’t be that hard to port as it’s actually not “that” tied into Windows at all. And i DO want WPF everywhere, NOT some crappy substitude made by the community that would be “inspired by it”. I want the actual 10+ year tested on very large project WPF, that’s what i’d like to get ported. There are already xaml ish alternatives, but they’re not in the same league, hell even the full Silverlight isn’t quite in the same league as WPF.

I know i don’t care about native look on each platform, open source WPF would make it viable to port projects for which you had settled on WPF for the productivity / performance / design and for which you wouldn’t have considered cross platform otherwise. I don’t think we could see something like wpf coming from the community (not like wpf is new, yet nothing was ever started to get WPF in mono unlike moonlight for Silverlight), and certainly nothing that would compare to what was once backed as a selling OS feature (avalon) and has been tested as such and then refined for > 10 years on small to extremly large (visual studio) projects.

Edit : and if you really want native look, it’s not hard to style wpf for it, it would be a one time community effort, and even if it wasn’t, it would still be a smaller effort for one team to do once per project than to have 2 gui on any mid size or bigger software, so yea there definately would be OS specific templates from the community pretty quickly that style all the default WPF controls for each platform, let’s not forget a button in wpf isn’t a square, it’s just “something you click”, it just so happens to have a default style that is Windows ish, but that’s all it is, a convenient default.


#26

Look beneath the surface. Once you get past the superficial differences like brushes and fonts, the controls all mimic common Windows controls that have been around for years. The properties, events, and capabilities of the core controls are all based on Windows conventions and behaviors that date back to the 3.1 era. Some Windows controls may appear visually similar to controls on other platforms, but I guarantee you there are plenty of idiosyncrasies that users will pick up on–little things that make a Windows/WPF app feel out of place when running on another platform. And don’t forget about things like keyboard navigation, focus management, and drag & drop–are the conventions the same on Mac? What about the numerous Linux desktop environments? Do you even have the slightest idea what users of those platforms expect?

Changing the visual appearance of controls with platform-specific styles only goes so far in making an app look, feel, and behave like a platform-native app. And even if someone comes up with a set of platform-specific control styles that look very much like native controls, the metrics and layout are going to be quite different across platforms. The majority of UI developers have never even bothered to see how their apps look with a different system font. They hard-code window sizes based on the size and layout of controls as they appear on their system. Plenty of them ignore best practices and rely on absolute positioning and size constraints, not to mention hard-coded colors. Do you really think most WPF apps are going to look nice and at home when they run on another platform, with substantially different control styling, font sizes, color schemes, margin/padding guidelines, etc.? Unless the UX styling is completely proprietary, every pane in every window will probably need to be tweaked, often to the point where it would be better to scrap them and start over.

I wasn’t talking about your typical WPF application; I was talking about your typical Mac application. Mac applications, by convention, hook into the system menu bar. That’s where Mac users expect to find your application’s commands. Windows, and by extension WPF, have nothing like that. That’s just one of many things that would cause WPF apps to stick out like a sort thumb when running on Mac.

What you want as a developer has no bearing on what your users want. Programmers’ tendency to indulge their own laziness at the cost of the user experience is arguably one of the chief reasons most developers have no business designing and building UIs. Users like it when applications on their platform look, feel, and behave consistently. You seem to want to use the same UI across all platforms, whether it’s appropriate or not.

Those 10+ years of testing aren’t going to mean much once you refactor the framework to be platform-independent, with separate input and rendering layers for platforms that WPF was never intended to target. Especially when those layers are some of the trickier and more performance-critical parts of WPF.


#27

I’m not sure what your point is on the first block, no i don’t think that “every wpf app is going to look nice and at home on another platform”. But i do think WPF apps made with cross platform in mind could look just fine yes. It’s not that hard to make a layout that scales well in WPF.

What do user of those platforms expect? Doesn’t really matter because currently they get nothing, once again i’m not saying people using cross platform technology would switch to WPF, i’m saying this would enable a huge stack of software for which it simply makes no sense today to write for cross platform UIs to have portability. For example for me writing apps for mac / linux is just a no go, it’s not making any financial sense to drop WPF and do it as soon as you do something nontrivial visually. If WPF ran there then it would be worth the effort to do some additional testing / tweaking.

This really has nothing to do with lazyness, producivity isn’t lazyness, it’s simple business sense, if you spend more time on something because you’re forced to use another tech or worse, multiple techs, then it better be worth it, currently it isn’t for all of my use cases, having WPF available on other platforms (even if it means porting a lot of it MYSELF) would make it viable. Users don’t “like it” but “like it best” when the application match their platform, as you can see from the endless linux forum rants when something is not available, what they really like is actually getting the software, getting it to look nice on their platform is a bonus.

You’re also talking only about mac and linux and general conventions but

  1. General conventions don’t always apply, not every WPF app is a simple form / LoB appliation and there often are no conventions for displaying very graphically intensive nested data hierarchies, unlike simply stacking a few textboxes.
  2. What about mobile phones / tablets, it can be for your Windows users too that also have an iPad / surface / iPhone / droid / whatever on the side, having the same UI on all those devices can be an upside at times, for my use case i have a business reporting application that could look just as nice on tablet / phone than on PC, with WPF being perfect for my need, and i definately would like for the user to feel like they’re using “the same” application when they’re on the go.

#28

Mike, we all know that you’d want to probably make different UI’s for different platforms. That’s not that surprising. But you’d get a lot of reusability in both your skills in the UI tech being used and also a lot of the underlying code. That’s the benefit of cross platform code. None of the counter arguments you’re making about the differences in the UX of different platforms is very compelling since this problem has been dealt with by web and mobile already and it’s not any different here.

WPF has built-in themeing capabilities that are well suited for the visual differences between platforms, in fact it already has different default themes depending on the different versions of Windows you’re using to look like the native OS. The fact that the OK and Cancel buttons are typically switched really isn’t that hard to deal with to be honest.


#29

You don’t need WPF for that. You can share your core code base regardless of what UI framework you use. There’s no reason you couldn’t hook up your view models to something like Xamarin.Mac.

It is substantially different. The web and mobile solutions like Xamarin were designed from the beginning to be cross-platform, so they handle the differences gracefully. WPF was not, and it’s not something you can just bolt on as an afterthought and have it work out well.

[quote=“justinmchase, post:28, topic:421”]
WPF has built-in themeing capabilities that are well suited for the visual differences between platforms, in fact it already has different default themes depending on the different versions of Windows you’re using to look like the native OS.[/quote]

The differences between any two version of Windows are, in terms of UI, superficial. All versions of Windows use the same controls, and apart from the actual brushes and fonts used, the sizes and metrics are all similar. The UI guidelines for things like layout and margins/padding are similar. Window management, keyboard navigation, and focus management haven’t changed. When you look deeper than the paint, the differences in look, feel, and behavior of a Mac application versus a Windows application are far more significant than a Windows XP versus Windows 7 application.

All platforms have plenty of great native applications. Saying they “get nothing” because they can’t run your Windows application is silly.

I get the feeling you don’t know a lot of Mac users.

You do realize you’ll still need to buy Mac hardware to test your applications, right? And are you going to expect the Visual Studio and Blend teams to throw in support for designing UIs with theme switching to show how your views will look on other platforms? Did you account for that in your “it would take one guy six months to a year” estimate?

What exactly do you think would compel Microsoft to rewrite the internals of WPF just to facilitate mediocre support for running on Mac or Linux? Even if they were to open source it, they’ll still be expected to maintain and support the platform. What do they gain by abandoning time-tested input and rendering/composition systems?


#30

You’re really seeing the bad in everything.

You do need wpf to share “everything”, viewmodels aren’t everything, views are pretty complex once you go past “simple controls” that are os specific and seem to be your core issue. In some of my application most of the code is in XAML by far, sharing just the viewmodel isn’t much of a saving.

The web was deigned to be cross Platform, but it wasn’t designed to be “native on mac or native on linux or native on Windows”. So WPF wouldn’t do any worse there.

They get nothing OUT OF THE NON PORTED APPLICATION. Not everything is about random applications of which there are a dozen, there are plenty of custom company applications for which you don’t chose, it’s custom, there is one, and if it isn’t multiplatform you don’t get it period. Once again you’re countering the use based on a very narrow view (on cases where , yes , wpf doesn’t make sense). I’m not argueing on those, i’m saying you’re missing the plenty of use cases where it doesn’t apply. For example in the last company i was in, we settled on WPF, mac users just didn’t get the app, it was deemed a good tradeoff as we had < 5% mac users, i do think they’d rather have gotten something that “kinda didn’t feel perfectly native” instead of well, once again, nothing.

You keep bringin mac up, this isn’t a mac forum, the discussion is global and with the ton of UI on linux there hardly is a linux look and feel for example, WPF would work fine there, as well as on IOS and android and Windows phone, all at no cost if it was ported.

I do know a lot of mac users, and in a company when you have a custom program you need to use, you use it period, no one cares if you like it, so mac users are happiER using a wpf ported application, than having to dual boot into Windows to use the exact same application for sure.

My 6 month estimate (if you read well), didn’t include any porting, simply abstracting the OS part from it, it would still require per os testing / bug fixing etc, it was 6 month just to untie it from win32 / directx, that can be done on Windows and doesn’t require a mac, beside buying a mac isn’t exactly a big issue / cheap to test (but i wouldn’t, i have no particular interest in mac atm and while i would love to make WPF a portable Platform i wouldn’t contribute to the mac part personally). I’m not sure what you mean about “the visual studio and blend team to throw in support for designing UIs with theme switching”, you can already switch themes at runtime, what’s the issue?

They wouldn’t need to support it, this could be a community port, beside Microsoft always cared about multiplatform ability (deciding to release and maintain it is a separate issue) as they themselves expand to other platforms (phone, consoles etc). Having the rendering abstracted could be an upside. You’re barely abandoning anything too, you don’t redo the composition / input, just the rendering and the very low level input, all of the eventing system feeding the input stays as well as the composition. The actual code monkey work is likely, very tiny in comparison to the whole system.


#31

Have you actually used wpf? I am sorry but judging from your ideas i think you have never really used wpf. Look wpf renders its UI itself and does not use windows win32 api’s for rendering its controls and anything else that can be seen on the screen, properties and behaviors of the controls are also its own and are not inherited from windows or use win32 api’s, the default behavior,look and feel of wpf controls is emulated to be like native windows controls and it does not mean that they are based on or derived from windows api for UI, try to understand, a button for example by default looks like a windows button because its default template gives it that look and feel and its default behaviors and styles gives it its nativity look . just change that template and you can have every kind of button, and changing a template in wpf is very easy and developers do it often than not. Take another example you do not like a scroll bar’s default behavior, you think it should be doing page up and page down instead of moving slowly up and down, you do not even need to write another scroll bar class in wpf. Just write that behavior behavior which is a trivial job for even a mid level wpf programmer. What you are counting as weakness of wpf are actually the strengths of wpf.

I think you have not installed the nuget package mahapps.wpf which i suggested in my last reply,that package will prove to you emulating an entirely different look,feel and behavior for wpf controls and even writing new controls in wpf is not a difficult job and this is one of the selling point of wpf.
In mahapps.wpf they have even changed the main window, you can have a window which has an application menu located in the caption using mahapps, and you can roll other types of main windows too

And about your statement that people like native look,feel and behavior and most people do not like different look and feel that may be a case but you can not file it against wpf,because 98% developers choose wpf to give their application their own look,feel,style and behavior and meet their customers demand, i am one of them.
So this is no no reason for not porting wpf to mac or Linux because it will not look like native and will not behave like native in some cases.Because come on its one of wpf’s strength.


#32

I have been working extensively with WPF since the September 2005 Avalon CTP. I’ve worked in every obscure layer, including the lowest-level text APIs; I’ve written custom controls, a custom theming system, countless behaviors and core control enhancements, drag-and-drop functionality, an XNA interop system, and what is probably the fastest WPF data grid implementation in the world for displaying large volumes of high frequency data. So, yes, I have used, abused, and extended WPF to the extreme.

I never said that it did.

From a user interactivity standpoint, the behavior and default look and feel of most core WPF controls closely mimics common Windows controls that have been around for decades. They were modeled after the same old MFC controls as WinForms and classic Visual Basic. Yes, you can change their visual appearance with custom templates, but the logic, behavior, and underlying model are based on historical Windows conventions, which do not necessarily align with those of other platforms. Platform-specific themes can only go so far in changing the core controls’ behavior without introducing side effects that could cause user code to behave differently on, for example, Mac versus Windows.

No, I fully understand and appreciate the power and limitations of WPF’s “lookless” control model.

I was building games with completely restyled WPF-based UX back in 2005. I know how it works, and I probably know it a lot better than you.

No. Some certainly do, but not a majority. The stock experience on alternate platforms would need to be up to par with the stock experience on Windows. You can’t just write off the out-of-the-box “native” experience because some apps will end up restyling everything.


#33

Ok fair enough. i still do not agree but everyone have their own views, mine are different from yours.
But seriously some of your complaints gave me the feeling that you have never really used wpf. But as you have used or developed it and you think it is bad idea to port it other platforms i respect your view.But my view is entirely contrasting.


#34

It’s not so much that I think it’s a bad idea to port it; I don’t think Microsoft has any incentive to refactor the stack to facilitate the porting (or at least nowhere near enough to justify the cost, which many seem to be underestimating). My other comments were intended to highlight reasons why cross-platform WPF apps will likely fail to hit the quality bar, and why multi-platform support won’t provide the instant gratification that some of you seem to be hoping for; it will almost never “just work” and provide a first-class native app experience, and that is especially true for already-written applications. Moreover, the the design and testing processes will probably end up being agonizingly tedious to the point where you won’t even bother supporting platforms other than Windows. I do not see it being worth the effort, and I will be astonished if it ever happens.

I suspect that is because you are thinking in terms of what you hope the end result will be, and not what it will ever realistically be. Too much would need to happen on the Microsoft side (e.g., tooling) for the cross-platform development process to be anything like the current process, and the amount of tweaking and redesign required to make your apps look at home on multiple platforms is probably way more than you think it is.


#35

Totally agreed i will also be astonished. Cross platform from Microsoft side will never happen that is almost certain. And not even open source. But what i hoped was the possibility of things that the community can do to wpf if it is at least open sourced, because we know it from history that open source software has been used and changed in ways which were not expected. But then again in a similar thread on this forum i have argued about this myself that open source of wpf will never happen do not even think about cross platform but my reasoning is different from yours.


#36

I think that Microsoft should concentrate on WPF for Windows platform only and not even consider other platforms as they clearly do not have enough developers working on it. It has so many Windows.Media.Composition.DUCE.Channel.SyncFlush() and other rendering resulted crashes impossible to reproduce which they don’t want to fix that I am even suspecting they will abandon it soon.


#37

Open sourcing doesn’t mean that they have to support it on every OS with inhouse developers. Just give us the thing so we can play around with it. If they just dump the source and never touch it again, it would make me already happy enough.


#38

Hi all,

It is impossible for WPF to be ported on non-Windows platforms – not even Microsoft can do it. WPF as well as WinForms have too many platform dependencies and are not well though for cross-platform support.

The only .NET solution that allows you to write 100% identical UI code and applications for Windows, Mac and in the future Linux, iOS and Android is Nevron Open Vision. This is a heavy User Interface solution that can help you create cross-platform applications.

Nevron Open Vision is also the UI behind Nevron Office – a free alternative of some Microsoft Office products, that works on Windows and Mac from a single code base. So cross-platform applications development on .NET is not some fiction – it very real, cost effective and productive.

If you intend to be cross-platform I would suggest dumping WPF and stepping on the UI platform that really does the job. The nice thing is that you can do it gradually, since Nevron Open Vision components can be used in WPF too.

Full disclosure: I work for Nevron


#39

Yes, I agree with you. Xamarin.Forms should support Mac OS. But full computer UI has much more control sets, so it will make the Xamarin.Forms complicated. Probably it is easier to let Xwt to support XAML.


#40

“It is impossible for WPF to be ported on non-Windows platforms” this group just like it was to much 't for mono , just because you cant, for the love of logic , don’t use that word, what am i doing it’s impossible to enlighten the self proclaimed experts, is it impossible to port a directx app to opengl, impossible, impossible? do you know how weak you sound?


#41

xamarin does weak forms apps for iphone and adroid nothing more , it is so weak the fanboyism is getting out of control, lets see a where is a great xamirin app? native app are better on everything but win ha8te


.NET Foundation Website | Blog | Projects | Code of Conduct