Include WPF in the standard #20
Comments
|
+1 |
|
Yes, please. |
|
+1 |
|
+100 |
|
Silverlight is easier target to reach feature parity first |
|
I agree to a point, but I think that targeting full WPF compatibility would be... immense. More than immense. If MS can get 1/2 of xamrin parity in v1, with the ease of WPF/UWP development, I'd be ecstatic. Baby steps. |
|
I disagree with this. As someone who spent ~5 years working on WPF apps and the last 2 working on UWP XAML apps, the UWP flavor of XAML is way better. Example major improvements: x:Bind, x:Load, VisualState Setters, and bindings to functions (via x:Bind). Supporting unmodified WPF apps in the standard would bring in cruft like DataTrigger, EventTrigger, Effect, WPF's 3D stuff, and multi-bindings (function x:Bind is way better than multi-bindings and the IMultiValueConverter mess) that all have better replacements in UWP. |
|
@bschoepke No one said the WPF model is the way forward that sets the standard. Who said WPF can't get UWP features? (that's actually my secret agenda for pushing WPF to be part of the standard). |
|
So you mean backport XAML Standard 1.0 to WPF via a library and vs tooling? |
|
Well based on what's already in the standard draft, WPF is already .NET Standard 1.0 compatible. No work required. What I want is to ensure that going forward, if new functionality is added that WPF doesn't already have, it is then also added to WPF. |
|
@dotMorten ahh, I misunderstood the proposal. I agree that it would be nice if WPF supported all XAML Standard 1.0 markup, but not the other way around. It would make WPF a little more confusing though by adding a bunch of additional ways to do the same thing. |
|
I didn't know someone asked this earlier. :) So my #42 is the same request as this here. Please HEAR this we XAML passions are shouting this LOUDLY. Microsoft please listen. |
|
If a comment is a vote, here's mine. |
|
Any XAML platform that doesn't conform to XAML Standard should be officially declared dead. I'd prefer to evolve WPF to XAML Standard, but if it doesn't happen then we should stop pretending WPF is an official platform moving forward. |
|
from what I understand versions of XAML Standard will be similar to versioning in .NET Standard Library, so wonder if no existing platforms will be covering 1.0 and backporting will be used to bring them up to 1.0 compatibility (not just feature parity, but syntactic compatibility I mean). |
|
No don't include the WPF flavour of XAML in the XAML Standard. The main reason being that UWP / Xamarin are now the future. Whilst I myself am a WPF developer, I am also a UWP developer. WPF is legacy, but that being said, I'd be happy for some elements of WPF XAML to make it in e.g. DelayBindings, Triggers (Trigger, MultiTrigger, DataTrigger) etc. |
|
+1 |
|
Yes! |
|
UI sharing with WPF would make this standard a far more attractive platform. There's a lot more WPF development than there is UWP (or Xamarin, I think). |
|
Yes! Pls. |
|
If not including WPF in standard means WPF is dead, but what is the alternative to WPF for client app development? UWP? You can't force customers to upgrade their win7(even xp) to win10. There are many enterprise app developers you can't ignore. |
|
Getting the enterprise sector in the uwp direction wpf is an obliged step.... |
|
+1, please do this. I also work in WPF and UWP. In most times, I need to create two project and their XAML are almost the same. |
|
+1 |
|
That was EXACTLY the kind of issue I was looking for, I couldn't agree more to this idea, as we are close to publish a new WPF app and we want to reuse some screens cross platform. Please, don't forget devs that made you what you are now Microsoft |
|
In out industry sector, the 90% of computers have Windows 7, !PLEASEEEEEE .... support of WPF is a MUST HAVE!. |
|
I don't think it could be called a xaml standard unless WPF supports it. At the very least WPF needs to be able to read files that are valid xaml standard files. Otherwise it's not much use. As you can see there are many of us who are building WPF apps that need to have UWP versions and/or Xamarin versions once Xamarin has reasonable xaml support. At the moment as others have pointed out there are useful things in UWP xaml that are just simply not available in WPF like x:Bind. WPF xaml needs to be updated to support the newer UWP xaml standards |
|
What I mean to say is no underlying native COM components as in W10 components.
From: gulbanana [mailto:[email protected]]
Sent: Friday, May 26, 2017 5:47 PM
To: Microsoft/xaml-standard <[email protected]>
Cc: Chris Bordeman <[email protected]>; Mention <[email protected]>
Subject: Re: [Microsoft/xaml-standard] Include WPF in the standard (#20)
an interesting prospect. do you think the consuming of native-projection components could pose a problem though? i'm not sure how deeply that affects the semantics of pages and controls as they are today, it at least has the effect of making all the public types aliases for winrt interfaces. that would make binary compat very difficult.. the winmd files would need to be interpreted differently or something
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#20 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AB02aY_efuiCRHyc_3LWl15qduSm856sks5r90hAgaJpZM4NYQjd>.
|
|
No Winmd. No Universality for the exes. The target is Win32 exes only.
From: gulbanana [mailto:[email protected]]
Sent: Friday, May 26, 2017 5:47 PM
To: Microsoft/xaml-standard <[email protected]>
Cc: Chris Bordeman <[email protected]>; Mention <[email protected]>
Subject: Re: [Microsoft/xaml-standard] Include WPF in the standard (#20)
an interesting prospect. do you think the consuming of native-projection components could pose a problem though? i'm not sure how deeply that affects the semantics of pages and controls as they are today, it at least has the effect of making all the public types aliases for winrt interfaces. that would make binary compat very difficult.. the winmd files would need to be interpreted differently or something
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#20 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AB02aY_efuiCRHyc_3LWl15qduSm856sks5r90hAgaJpZM4NYQjd>.
|
|
backporting to WPF might not be needed if XAML Standard adds enough of WPF features and Xamarin.Forms then apart from implementing the standard also adds a WPF target as promised |
|
The problem with that is people will be tempted to do things the “WPF way.” And use non-UWP controls. The extra Xaml features of WPF need to be unavailable so the developer feels safe writing a UWP UserControl.
From: George Birbilis [mailto:[email protected]]
Sent: Friday, May 26, 2017 8:40 PM
To: Microsoft/xaml-standard <[email protected]>
Cc: Chris Bordeman <[email protected]>; Mention <[email protected]>
Subject: Re: [Microsoft/xaml-standard] Include WPF in the standard (#20)
backporting to WPF might not be needed if XAML Standard adds enough of WPF features and Xamarin.Forms then apart from implementing the standard also adds a WPF target as promised
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#20 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AB02aabD4AIxwyLsOrBRq_9aoLZTG_vRks5r93DtgaJpZM4NYQjd>.
|
|
Otherwise what the developer is writing isn't a XAML standard control, it's a WPF control. So we need a "new item" dialog that says "UWP WPF UserControl." that is restricted to what UWP controls can do, no MultiBindings, whose implementation is not COM based underneath. This doesn't seem like THAT much work, even the UWP controls should just work, at least those not written directly in that C++ COM monstrosity. That leaves the ViewModel and other services still potentially doing illegal stuff like Reflection.Emit, but |
Problem? What problem? 😆 😆 😆 |
|
When people will be writing a new app that targets multiple XAML platforms, they will have accepted the fact that they use only allowed functionality. Problem is when you evolve existing apps (while wanting to keep your existing target platforms always) and when you have lots of investment in XAML+code you want to reuse. So missing functionality is an issue that should be minimized |
|
btw, an issue I was having when trying to make porting layer between WPF/Silverlight (http://github.com/zoomicon/Compatibility) was that some control classes didn't allow one to extend them with a descendent so that you could augment their missing functionality say implement stuff from WPF that was missing at Silverlight. XmlnsDefinition also helped in reusing XAML since my porting layer classes could have same XML namespaces but be implemented in other library (see example at #141) |
|
Would it be possible to consume XamlStandard 1.0 Controls/etc from WPF vNext in a good way, WPF-developers can gradually convert their application into UWP/Xamarin compatibility=future proofness? |
Can you define what you mean by "useful", "modern", and what the "needs of today and tomorrow" are? I am sincerely wondering what parts of WPF xaml aren't and why, as I personally haven't used UMP much. Thanks! |
|
regarding Surface that was mentioned above, later on it was renamed to PixelSense and there was a third-party device that wasn't camera based (like in the original table) and so it was more like a thick screen that you could also lie flat on its back and move around apart from the Surface SDK, think there was some code released as opensource a nice thing with Surface is that it supported
speaking of multiple persons and tokens, obviously the system gave them some id and tracked them as they "moved" around. A similar approach of an "id" for mouse interaction was available at Microsoft India's MultiPoint SDK (and later MultiPoint Server). You could connect multiple mice on a hub and have students interact at the same time with a big screen or projection (showing different mouse cursors for each one [e.g. a different animal] so that they could associate with where their cursor is on the screen). Wonder why such functionality (multiple users working on a UI) has been forgotten and not standardized |
|
@birbilis surface / pixelsense?!? Wtf? please go to wpdev.uservoice.com and vent your frustrations about lack of features in windows rather than hijacking all sorts of threads here in a futile attempt to discuss unrelated stuff here. You've been warned so many times now. |
|
@dotMorten, Please correct me if I am wrong here, but @monkeynoises also mentioned Surface and I have not seen a warning given to him in regards from any perceived deviation from the topic here. @birbilis was continuing from that thought and providing additional insight around this in a constructive manner (in my opinion of course -- your opinion may differ and I respect that). Additionally, I do have to say that your use of profanity here and in the above -- even while in acronym form -- as well as your general tone of hostility can certainly be considered unprofessional, and as such can be viewed as a violation of the .NET Foundation Code of Conduct (last point in the list there). Of course, my interpretation could be wrong and the final word on this should be made by an administrator/contributor/DNF member. I for one would appreciate an admin's perspective on this while we're learning the ropes here. Also, I get that you feel that @birbilis has been warned many times, but by who? Again, I for one would feel better aligned with your sentiment if a contributor/administrator/DNF member has warned him of his practices so that we have an official gauge of what is appropriate and what is not. They are the one calling the shots for us commoners, after all. If this has been done and I have missed it, please feel free to correct me (again, LOL) and I'll shut up and go back to my corner. I hope it's clear that my intent is to promote a healthy community here. I for one enjoy hearing and reading all sorts of thoughts on a matter, even if it is not 100% on point/topic and especially if it is constructive and not done in a negative light. To me, it is the inspired passion that is valuable within this, as this (IMO) fosters the feeling of belonging which ultimately (if we're lucky) leads to the creativity and innovation we're striving (or should be striving) to achieve as a community. I'm all for correcting someone but let's please not be abrasive and hostile about it. A simple thumbs down will do and we'll get what you mean -- and join you if we agree. |
|
Everyone, new topics == new issues. Keep topics on point and civil. If you have any questions, please reach out to me, [email protected]. We're all devs, treat these like bug reports, don't add new bugs to existing bugs else they get lost. I will start cleaning out comments if they are off topic and that is something i 100% do not want to do as i feel it is anti-community. Multi-user in xaml standard is 100% a new issue as the heart of this issue here is WPF to be included xaml standard. |
|
seems @Mike-EEE has better memory on what was mentioned in the thread. I use windows phone mail threads and reply when I have time to do so. Github doesn't have threaded discussion. Surface SDK and IntuiFace btw that I mentioned is WPF based. Wonder how much effort such mature s/w would need to port to UWP. MS has been doing API surface checks on Nuget libs but not on products out there? And no, I don't have more time to spend here but contribute with more info on things mentioned. If others want to fillin issues from that discussion feel free to. As for self-proclaimed github police, @dotMorten can keep on, I'm hardly intimidated. |
|
@birbilis Love the interaction and discussion but once again, new issues == new thread. I feel it would be very beneficial for much more detailed asks here as per before, these are becoming catch alls which no one is ever happy with because they cannot be properly executed against. Surface 2.0 SDK (now surface hub, not surface as in laptops/studio) i would make the argument is pretty old at this point. It targetted Win7. And honestly, i think most, if not all, is now part of just UWP as you develop a UWP to support Surface Hub. Are you asking for multi-finger support / gesture support? If this is the heart of what you are asking for, create a new issue asking for that. What bits inside that SDK are you trying to parse out to be part of the standard. |
|
Actually it's multiperson tracking (multiple people interact on a UI via touch input, virtual touch input via vision / depth cams etc or via multiple mice like in Microsoft MultiPoint). So an id of input source comes with each event and input device tries to keep that id matched to persons, bots etc. that cointeract on a UI during app lifetime. This can include using tokens, would have some special id mask probably, not sure how Surface sdk handled tokens. Haven't followed Surface Hub and if it has multiperson input. If it does, it would be good usecase. Not sure if this standard will go into such things, they sure were/are inspiring though. Was mostly commenting on the mention of surface sdk earlier in the thread |
|
@birbilis please, new topic == new thread. this is 100% new topic. Next time i will edit and say "off topic" as that is 100% off topic from the support WPF thread. Also these should stick to only Xaml Standard. If you want net new Windows platform support for something, please head to https://wpdev.uservoice.com/forums/110705-universal-windows-platform |
|
[admin(crutkas): off topic, please use new topic] |
|
Hi again, people :) This more or less what I understand XAML Standard should be. Please, tell me your opinions. https://github.com/SuperJMN/OmniGUI @dotMorten @Mike-EEE what do you think? Keep in mind that I'm the only person behind it. |
|
+1 WPF support in .NET standard project would be awesome. |
|
+1 Yes, but it is worrying that they did not already think of this. |
|
+1 |
|
If I keep to a shared subset of XAML, I should be able to click compile and have VS spit out either a WPF, UWP, or Xamarin Forms assembly, no questions asked. This 'shared subset' should include all the features which make sense on each platform. That's all I really want. |
|
@mm201 I think you should give Uno platform a try |
and others
Lots of users are coming from WPF. To ensure users have a smooth transition from WPF to UWP or Xamarin, WPF really should be a 1st class part of the standard from the beginning, but the documentation at this point seem to only include UWP and Xamarin.Forms.
It will also help ensure the platforms will grow together in the future as the standard grows..
FYI you can just thumbs up right below here, rather than commenting +1 ;-)
Also please read my follow-up comment below: #20 (comment)
The text was updated successfully, but these errors were encountered: