Coffeehouse Thread

40 posts

All these XAML changes for WPF XAML too?

Back to Forum: Coffeehouse
  • User profile image
    RealBboy360

    What about that PDF viewing in XAML now, I doubt that will work for WPF right?

  • User profile image
    DeathBy​VisualStudio

    @RealBboy360: Of course not. The desktop is "dead" or "Microsoft is focusing its attentions elsewhere". Take your pick but don't hold your breath on these features coming to WPF. IMO Microsoft like to paint a broad brush by using the term "XAML" without qualifying it with the API it's talking about (WPF vs. WinRT).

    If we all believed in unicorns and fairies the world would be a better place.
    Last modified
  • User profile image
    Vaccano

    @RealBboy360:It is funny how they talk about XAML updates as if WPF (and Silverlight) don't even use it.

    Soma mentioned on his blog that "we've made many improvements to the XAML editor experiences in Visual Studio". 

    I hope that those apply to WPF use of XAML as well, but I have a suspicion that they don't.

    I don't understand how the Desktop can be dead when so many companies won't even upgrade to Windows 8 (which is the only platform that can support "store apps").

  • User profile image
    cbae

    If Microsoft were to profess its continued love for WPF and Silverlight, would .NET devs start flocking to those technologies again, if they ever did in the first place? I don't think so.

    These technologies are dead not because Microsoft necessarily intended to kill them. They're dead because devs THINK Microsoft intended to kill them.

    It's almost as if those that genuinely want Microsoft to support a technology are the ones spreading the FUD leading to that technology's demise.

  • User profile image
    Vaccano

    @cbae:From my point of view, Dead = Not being improved any more (by Microsoft).  (Some optimists try to call this "done".)

    You seem to be talking about how many people are using these Dead Techs and your opinion that developers venting frustration over Microsoft's change in "favorite technologies" is causing other developers to realize that the "favorite" has changed and to move to the favorite.

  • User profile image
    cbae

    @Vaccano: Why would Microsoft continue improving a technology, if devs leave that technology in droves? Because of all the "venting", there's absolutely no chance these technologies will ever attract NEW developers, which would give Microsoft the very incentive to improve the technology.

    There's only so much evangelizing that Microsoft can do on its own. The developer community itself has the primary responsibility, and going around crying like Chicken Little works contrary to that.

  • User profile image
    Vaccano

    @cbae:I think that Microsoft cares less about what developers want than you think.

    (example: If they did, my icons would not be gray and colorless.)

    Microsoft develops what it thinks will make it money.  That is why they are moving to Store apps. (What company would not want a significant cut of all sales on their platform?)

    We vent in hopes that Microsoft will listen to the feedback that their "store" solution does not work for most enterprise scenarios.  We vent in hopes that they will see that there is money to be made by continuing to support enterprise development needs.

    The only other option is to just silently let MS kill off the techs we use.  (Though that seems about as effective as giving feedback.)

  • User profile image
    Sven Groot

    , Vaccano wrote

    Soma mentioned on his blog that "we've made many improvements to the XAML editor experiences in Visual Studio". 

    I hope that those apply to WPF use of XAML as well, but I have a suspicion that they don't.

    I just tested it, and I can attest that the designer/editor improvements do apply to WPF, Silverlight and WinRT projects using XAML.

    The PDF viewing support does appear to be a WinRT feature, so it's not available in WPF.

  • User profile image
    Tokter

    @cbae: We have a big Windows Forms application in my company. Planing ahead for the next version, I was thinking about using WPF. Which would make me a NEW developer.

    But the desktop seems to be "Done", which makes me a little hesitant to invest my time in it.

    All the evangelizing doesn't help if the product only now becomes usable.  I remember going to a .Net user group meeting where a MS Evangelist demoed WPF. He typed (since the editor was even more laughable back then) an application together, then he told us. Yes it looks like *, but look what a designer back at MS was able to do with it. That's just not very compelling if you do Business Applications.

    So where do those devs leave in droves to?

  • User profile image
    DCMonkey

    , cbae wrote

    @Vaccano: Why would Microsoft continue improving a technology, if devs leave that technology in droves? Because of all the "venting", there's absolutely no chance these technologies will ever attract NEW developers, which would give Microsoft the very incentive to improve the technology.

    There's only so much evangelizing that Microsoft can do on its own. The developer community itself has the primary responsibility, and going around crying like Chicken Little works contrary to that.

    Oh, so its our fault now that WPF doesn't get any of these improvements because we all whined too much about it.

  • User profile image
    kettch

    I think that there's a widespread misunderstanding about what these different technologies do. WinRT isn't intended as a replacement for .NET. It is, however, an API that can be consumed by .NET. IMO, it seems that .NET and Native code are moving towards a model where they don't have their own API surface any more. Instead, they are simply becoming the means to access a common system API.

    Since .NET came out there's been a disconnect between the .NET libraries and Win32. They've had different and often competing capabilities. .NET developers complain that they can't do some of the stuff in Win32, and Win32 developers would complain that they wanted feature parity with .NET. The strategy that Microsoft has chose is to prioritize on WinRT in order to get it to the point where it has enough capability to start repointing pieces (or all) of the other API's to sit on top of WinRT.

    I think that was the gist of what Guggs was talking about yesterday. It's a big project, and people need to take a breath and realize that this isn't going to happen over night. Eventually there will just be WinRT. You'll chose native code vs. managed code based on factors like performance and garbage collection. You'll pick HTML/JS/CSS if you are a masochist. You won't be picking differing API's based on capability, because there will only be a single unified set of capabilities across the entire Windows platform. In the meantime, all of the existing development technologies will continue to work. An application you write today will still work in 20 years.

    It's amazing to me that developers can complain so vehemently about having to learn new things, and then be just as bent out of shape when that pace slows down. However, I'd argue that it hasn't slowed down at all. There's plenty to keep us all busy.

     

     

     

     

     

     

    Oh, and the Desktop isn't going any where. EDIT: Check out Channel 9 Live with Larry Osterman and Martyn Lovell at about 22 minutes in. "We still expect desktop apps to be a big and vibrant part of the development platform".

  • User profile image
    RealBboy360

    The keep talking about writing code once for many different platforms at build.  But wouldn't the simplest thing have been have a silverlight .xap file and deploy that same .xap file everywhere?  Yeah you did have to compile it differently for windows phone 7, but it could have been done and give error messages if the xap file doesn't work for certain device.  Now Windows 8 would have to be designed differently, but they could have done it.  Like the portable class library, you pick the devices you want the .xap to run on.

    I guess it comes down to money like said above.  If it worked like silverlight, it wouldn't have to go through the app store.  The could lock down certain devices to only go through the app store though.

     

    As for Windows 8 development, ever IT guy I've met hates windows 8  and will never install it.  most of the hate comes from a blind hate of MS, but most office workers are confused over desktop mode vs RT mode and the IT guy doesn't want to explain that to people.  It'll be 10+ years before you can develop LOB apps for windows 8 and expect everyone to have it.  And windows 8 apps are terrible for data entry and LOB apps.

  • User profile image
    kettch

    @RealBboy360: I think a properly designed Store app could probably do some stuff, but nobody has ever said you have to do your primary LOB application on that stack. The desktop is the perfect place for dense data focused application. I spent some time with a family member in the hospital, where they were using EPIC, which is supposed to be one of the top tier EHR solutions. Even a full screen application on fairly large monitor was bursting at the seams because of the huge amount of data that was being captured and displayed all at once.

    IT folks (being one, I can relate) are stubborn. We're ten years out from XP being released, and we are just now pulling the plug (today, actually). We just got permission to require a minimum resolution of 1024x768 when we write LOB applications. Enterprises will come around, they always do.

  • User profile image
    cbae

    , Tokter wrote

    *snip*

    But the desktop seems to be "Done"

    *snip*

    And why exactly do you think this? Did you come to that conclusion yourself, or are you listening to the Chicken Littles?

  • User profile image
    cbae

    , DCMonkey wrote

    *snip*

    Oh, so its our fault now that WPF doesn't get any of these improvements because we all whined too much about it.

    It's the fault of the developer community for not building enough compelling solutions to warrant Microsoft's continued investment in improving it. Complaining about how badly the technology sucks and requires improvement without balancing it with praise about how awesome it is or how awesome it could be only serves to scare new developers away. Then the blame solely rests on your shoulders for not helping to grow the community. How many times have you actually praised how awesome WPF is in the midst of your indignant complaints about how Microsoft wants to kill it?

  • User profile image
    Bass

    You could develop your app in HTML5/CSS/JS using a technology like PhoneGap instead of WinRT. As a plus it will work on Android too, which will overtake Windows in four years anyway. Big Smile

  • User profile image
    RealBboy360

    Try scanning or printing in HTML5... It's not the solution for everything.

  • User profile image
    Bass

    , RealBboy360 wrote

    Try scanning or printing in HTML5... It's not the solution for everything.

    It's not the same as a website, it's more similar to what WinRT does, but in a cross-platform manner. PhoneGap abstracts native functionality, so stuff like printers and scanners are indeed available from JavaScript in PhoneGap apps. And there is a port of PhoneGap for WinRT devices. In a world of device and operating system diversity like today, it's not really a good idea to limit yourself to writing applications for one platform.

    Imagine being able to write code once and have apps for all the devices, iPads, iPhones, Android devices, Windows, etc. You can reach an order of magnitude more customers without the expense of writing multiple codebases from scratch with profoundly different skillsets required.

    If that's not enough of a sell, at least some of your code can be reused on the web as well. So you can have mobile and web interfaces with very little work..

    And if you use node.js server side code, which runs well on Windows (Microsoft actually sponsored node.js development for Windows) and other OSes like Linux. And MongoDB for databases. All of which supports highly scalable cloud deployments. So you can have one language everywhere, infinitely scalable. And with CoffeeScript, that language can be quite beautiful.

    The only disadvantage really is you can't earn cheevos, but one day I hope they fix that.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.