I don't like xaml :-)

I don't like xaml :-)

• ImagineNation

  Ok, firstly, as you stated yourself, the XAML just gets parsed to normal C# code anyway, and then the designer is rendered from the C# code, so I really don't see the reason that if I can get C# generated code, I would want it to be converted back to XAML anyway.

  What I am proposing is maybe give the option of bypassing XAML, as C# is generated anyway from XAML. There is still a lot of benefits of having a designer to build a UI, as appose to building it completely from code. As Rob Relyea stated that they are interested about what people feel, I guessed that I could also share my 2 cents on the whole designer and the fact that I also don't like working with XAML. It would be nice to have a designer that generates C# code.

  Thank you,

  Jaco

  
  

• Chintan Vyas

  Hey Michael

  First thing is, if you don't want to use .xaml, don't do it.

  I was going to use sparkle, to make my interface and never have to see .xaml but even

  though sparkle is amazing, fun and easy to learn, it isn't yet up to doing everything I need.

  (or if it is, I can't figure out how to do it), So I got a couple xaml books and I'm comfortable with it

  and think that my learning time was well spent.

  Why Here a couple things I discovered.

  1. Even if you stick with C# there is a huge bunch to learn to make WPF sing.

  2. Most tasks, you'll need to write allot more code than you would xaml.

  3. Xaml it is easier to read and edit, the xaml for one page is all in one spot, hierarchically laid out.

  4. In my mind, Xaml is more logical, it more directly expresses what I want to do.

  Just a few thoughts from a xaml convert

  Later

  MIke Greenway

  
  
  

• Rhapsody

  Hi,

  I would like to know if we can have the option in the future of having and working straight with C# generated code seeing as the .Xaml gets converted anyway as can be seen in the .g.cs file. The reason why I would like this, is because it is unbaringly annoying to wait literally minutes for the designer to get drawn in Visual Studio (the Cider add-in), especially if there is a lot of UI components, as I guess that the code gets re-generated everytime you open up the designer.

  Thank you

  
  

• pinoyz

  1. "Everything done in XAML can be done in C#" -- This is correct. On one level or another, the XAML compiler is turning XAML syntax into CLR code; XAML can do no more by itself than any other type of CLR code.
     
  2. "I know C# and I don't have designer" -- I am in the same position. I have no time or patience to learn the Expression tool; for my purposes, it is hideously over-complicated. I write my XAML by hand, in Visual Studio.
     
  3. "...don't want to learn some kind of new language (xaml) only to use it because it is cool" -- I don't find XAML cool so much as I do find it plenty more readable than C# in doing equivalent tasks, particularly when using attached properties. It is more intuitive to build a hierarchial GUI (which is what Windows UIs are) in a hierarchial style than a procedural style. Remember, just because you're the only one creating an application now doesn't mean you'll be working alone forever. It's always in your best interest as a developer to pick up and maintain good habits, regardless of the current number of people working with you.
     
  4. "When I am writing XAML I feel like doing web page and not implementing standalone application" -- I don't know why you might feel that way except that XAML bears a passing resemblence to HTML. Once you know how XAML works though (see #1), it looks less and less like a static page of information and more and more like what it is: the front-end to your application.
  5. "And I have some feeling (maybe wrong) that doing things in code runs faster than when using xaml" -- Yeah, that's wrong. see #1. UI creation in C# and UI creation in XAML boil down to the same thing.
  6. "And debugging code is much better than debugging xaml" -- no argument there, but I have to admit that I don't really see how 'debugging' XAML would work. XAML is a declarative structure, it's not something that has a chronological flow that can be stepped through. It doesn't *do* anything other than describe the UI that will be displayed. How would it be debugged other than by parsing it, looking at the resulting UI, and changing the structure accordingly

  Hope this helped :)
  
  edit:  Addendum to #1,  the reverse is not true.  Although C# can do anything that can be described in XAML, XAML can't do everything C# can do because, again, XAML isn't code so much as it is a declarative structure.  It doesn't *do* anything, which is why it is bound to backend code and data
  
  

• Jose-san

  When I first approached WPF, I didn't know XAML, either. I picked up a copy of Chris Sells' book (Programming Windows Presentation Foundation - ISBN 0-596-10113-9) to learn about it and used this forum. What did I find I was a lot more productive getting things done using XAML, even though I was learning it. Furthermore, it's easy to change visual representations of things because you can clearly see and edit such things. I haven't used the designer tools at all (other than starting them up).

  I'm no XAML expert, but I like it. It helps me do my job better.

  
  

• JNBabcock

  We are definitely interested in your feelings about XAML.
  WPF has no need for you to use XAML, however, most tools, examples, etc.. will be biased towards markup.
  As long as you know how to translate those XAML samples into code, you'll be fine with just code, if that is what you choose.

  • Speed - the speed of compiled xaml is similar to that of compiled code. I'm asking our perf team for more solid numbers. We compile XAML into a binary form that is pre-tokenized and embedded in the exe. We also create a bit of code for each XAML file.
  • Debugging - yes, the debugging tools for pure code are more mature. A number of tools are being developed that will improve the debugging. (This includes VS "Orcas"). We will improve design time, compile time and run time.

  I am interested to hear what we should do in v1 and beyond to make XAML something all developers can love.

  Thx, Rob Relyea
  Program Manager, WPF Team

  
  

• Vipul123

  Hi,

  Ok, if loading times will improve, that will be great. One issue I have is that creating UI in the designer when placing or sizing elements, they are assign unbelievable big (small :) ) fractions. I don't know about you, but it clutters the XAML side of things, and from a performance point of view (yes, thos fractions matter if the application is huge!!) having numbers with fractions like that is BAD!

  Thank you very much,

  Jaco

  
  

• danadanny

  CodeDjinn-

  Yes, loading XAML pages in "Cider" should be faster (and will be.)
  However, it actually won't matter if we started compiling XAML into more code than we do now.

  So, assuming that XAML page loading in Cider is a separate issue, what else

  Thx, Rob

  
  

• Jason Saunders

  CodeDjinn, the designer does have problems with large sets of controls, but why would working with the C# directly make a difference over working with XAML Just...don't use the designer :)
  
  I could see human interaction with the generated C# turning into a disaster. How would changes be able to be echoed back to the XAML
  
  

• Alex K

  Jaco-

  Totally understand about the number of decimal places...more precision than is necessary for most uses.

  I'll pass that feedback along. Please realize that there are forums that are specific to Cider + Expression Interactive Designer that you could directly raise issues with as well.

  Thanks, Rob Relyea
  Program Manager, WPF Team
  http://rrelyea.spaces.live.com

  
  
• I don't like xaml :-)