Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Microsoft Operating Systems Programming Software Windows IT Technology

Introduction To XAML 68

Posted by timothy from the glue-included dept.
prostoalex writes "It was recently reported that Microsoft will integrate its own XML-based language for application programming into the next edition of Windows (codename Longhorn). This Introduction to XAML (Extensible Application Markup Language) provides an insight into how it's possible to build a Windows application with Microsoft's brand-new XAML language."
This discussion has been archived. No new comments can be posted.

Introduction To XAML More

Introduction To XAML

Comments Filter:

  • Question (Score:4, Interesting)

    by jsse ( 254124 ) on Monday December 15, 2003 @10:04PM (#7730839) Homepage Journal
    XML is meant to be interoperable.

    How well does XAML achieve in this regard?

    • Re:Question (Score:4, Interesting)

      by borgboy ( 218060 ) on Monday December 15, 2003 @10:26PM (#7730983)
      That's an interesting question, and should be modded up.

      The possibility - hopefully not a minimal one, is that you could develop an editor that based your gui layouts on XAML. Then your .Net presentation rendering - the big sticking point right now between WinForms and Mono GUIs - would be in an interoperable form. Maybe. Looking at the samples in the FA, I don't see any reason XAML couldn't be implemented for any platform hosting the CLR. Or most modern languages running on a gui platform, for that matter.

      Disclaimer - I am NOT a hardcore GUI developer. I could be full of it. Don Box and lots of other folks seem to be pretty excited about XAML.

    • Re:Question (Score:4, Interesting)

      by The Bungi ( 221687 ) <thebungi@gmail.com> on Monday December 15, 2003 @10:36PM (#7731042) Homepage
      Interoperable with what? If you're hoping that MSFT will port this to some other OS, don't hold your breath.

      OTOH, since it's just XML you can theoretically create an implementation of the engine in any platform where you have an XML parser available, which is pretty much any meaningful platform in existence. Just bind it to your GUI/widget set/rendering engine and you're all set.

      I mean, if Mono can create a complete (or almost complete) CLR implementation that runs on Linux I don't see why they or someone else can implement this as well.

  • XML based programming (Score:4, Insightful)

    by Kethinov ( 636034 ) on Monday December 15, 2003 @10:07PM (#7730857) Homepage Journal
    'Less I'm mistaken, this means that people will be able to develop fully functional simple Windows executables by writing a few lines of script in XAML? I think that's a good idea. Sure we still need stuff like C for large projects, but why waste your time coding in C when all you want to develop is something like a simple caculator?

    • Re:XML based programming (Score:5, Insightful)

      by !3ren ( 686818 ) on Monday December 15, 2003 @10:49PM (#7731189)
      Mmm not so much.
      All this does is abstract the UI from the code.
      (Which is super if you look at the kludgey cra* they have foisted on developers through the VS series of products. I have always liked the ease of use of MS's designers but the resulting code usually made me angry. Nothing like adjusting the attribute of a control in the source and having it crash your IDE.)

      You will still need to write behaviours for any application using XAML.
      I believe there's been a couple of O/S projects that have done the same thing for a couple of years (abstracting UI to XML) but I'm not sure of the names..
    • 'Less I'm mistaken, this means that people will be able to develop fully functional simple Windows executables by writing a few lines of script in XAML? I think that's a good idea. Sure we still need stuff like C for large projects, but why waste your time coding in C when all you want to develop is something like a simple caculator?

      Or spell checker. (ducks)
    • Sure we still need stuff like C for large projects

      No you don't. C is an adequate choice for operating system kernels and isolated performance-critical libraries, but it's really one of the last languages you should look to if you're writing an *application*. XAML is a step in the right direction (out of the C slough), although the implementation may not be the right.
    • Yes, it is a good idea to simplify GUI programming with scripting languages. I used to work on applications that had screens and screens of text, images, and some forms, carefully designed by graphic artists and customized for multiple clients. We basically did the same thing and designed a scripting language that was interpreted using a UI class library. However, the scripting language and class library were all proprietary and not useful to anyone else.

      It used to take someone with a 4-year CS/CE/IT de
    • I shudder to think about the horrible software that people will write by writing a few XML tags.. What Microsoft doesn't realize, and doesn't want to realize, is that syntax is almost inconsequential.. the real difficulty is being able to hold algorithms in you head and specify them clearly without errors...no amount of easy syntax and cute RAD tools is going to make that easier. Granted, RAD tools have their place, but you still need to be able to create and specify solid, logical algorithms. That's why no
      • I recently found out [mit.edu] that Matlab of all things can script Java objects. My PHBs are engineering students -- their tuition pays my salary, their evaluations influence my pay raises -- and yes, I would like them to program rather than rely on canned CAD and simulation software all their lives. They love Matlab, but knowing only Matlab will leave them developmentally disabled, the are required to learn Java, but I would like them to do more with it. Just wait until I show them how easy it is to use their

  • Yawn (Score:1, Funny)

    by Usquebaugh ( 230216 )
    Another language and still no progress. When will CompuSci people stop re-inventing the wheel and go out and invent something.

    • Re:Yawn (Score:5, Insightful)

      by Jerf ( 17166 ) on Tuesday December 16, 2003 @12:32AM (#7731827) Journal
      You've been modded "funny" as I write this but really you have an interesting point.

      The answer is that to date, all of our wheels have been spikey and sharp, tending to work poorly and often killing, crushing, and destorying things in its path, rather then working as designed.

      My pet example of this is "Object Oriented Programming". I think OOP is a significant advance, but it took 20 years to start to get implementations of it that were really useful, in C++, in Python, in a couple of other languages. (I take a broad view here. C# probably qualifies, but I haven't used it. Perl does for wizards only; technically the capabilities exist but they're damned hard to really get right. Java is getting there but still borderline, unless you augment it with other tools. Most other implementations tend to hit complexity walls too early to be useful, such as pre-template C++.) Think "design patterns", and the subsequent work being done based on that.

      Finding the best way to do one thing is easy. Finding the best way to do a million things is harder. Iterators or Observers? MVC or something else? Pervasive persistence or request only? (These are of course only sample questions, not meant to be answered or considered as exhaustive.) The only way to answer these questions on a large scale is to try them on a large scale. That takes time, and a lot of what seems like re-invention, as some new combination is tried out with a few subtly different answers from last time.

      The sheer staggering multiplicity of answers on so many dimensions is really unprecendented in any other Engineering field, since they all tend to be able to use "physical locality" to isolate the complexities of their system. Consider the almost uniformity of mainstream CPU design, for instance; is it really so inconceivable that a little 'reinvention of the wheel', i.e., a complete re-thinking of PC architecture, isn't called for?

      Right now, we really don't know as much as Language X bigots ("Language X is the one true way!") would have you think. There's still a lot of room for experimentation. And the only true way to experiment is by building a slightly different wheel, and seeing if it maims its users slightly less then before in a wide variety of situations.

      In this sense, "software engineering" almost approaches a true experimental science, albeit with very engineering-oriented experiments.
    • Ocaml has been developed. If you can stand programming in functional languages, you already have a fast language suitable for application programming.

      The problem with languages recently is that they aren't driven by CS people, but by businesspeople. Java was not enthusiastically endorsed by language people, but by business technology folks.
    • They'll stop inventing languages when you start using Lisp.

  • Wow! (Score:5, Interesting)

    by thecampbeln ( 457432 ) on Monday December 15, 2003 @10:22PM (#7730959) Homepage
    Very cool stuff! This is a very cool way to define the layout of a form, it boils it down very effectively (IMHO). Depending on it's implementation, it could allow for cross platform development (assuming that the target platform had a compatible compiler, of course)... But then again it is Microsoft, to them "cross platform" means Win9x, Win 2k and WinXP (see .NET). This will probably step into the same sort of role that VB (has) filled for so many years - quick and dirty applications development. Course that doesn't mean the concept is shit. This seems to be a very cool (and relativity open) means of defining UI layouts, and all the compiler would need is an XML parser!

    If Microsoft was only a technology company and could leave that whole messy marketing evilness out of it. Microsoft has come up with (or outright "borrowed") some very cool RAD technologies over the years. But god help us if they try to integrate any more then the UI elements into this "programming language" (I was once forced to use an ad-hoc XML-based programming language... it sounded ok until you tried to program in it, implementing logic was weird), but for the UI, wow.

  • Dear MS, (Score:3, Interesting)

    by Strange Ranger ( 454494 ) on Monday December 15, 2003 @10:36PM (#7731043)
    Can we get some of the Windows, Outlook, and IE XAML security measures included with the first longhorn release?

    Or are we going to be reactive only, as usual?
  • Wasn't XUL designed to be the exact same thing? Or is it more like SVG? Either way, I think we've already cracked this nut before. It looks nothing like a programming language, as the article implies, but a way to create Mickey-Mouse-Mode GUIs, for which Visual Studio will have a Wizard for anyway.

  • MS's reply to XUL (Score:4, Insightful)

    by josepha48 ( 13953 ) on Monday December 15, 2003 @11:02PM (#7731283) Journal
    This is basically Microsofts answer to Mozillas XUL. What a suprise that they have such an original idea. Of course what they probably haven't realized is that this means that creating GUI interface that are cross platform becomes easier and it then becomes easier to move away from thier OS. If they publish the dtd for the XML then an interpreter for other OS's that can render the XML is all that is needed. Then using .net framework or web services, your applicaiton could run anywhere and work anywhere.
    • They arent' concerned about this anymore. By the time longhorn is released they hope to eliminated any hardware cooporation or capability to boot from competing operating systems.

      At that point they can show what great and wonderful guys they are and how they develop all these great things to ease development for multiple platforms and allow for competition.

    • Re:MS's reply to XUL (Score:1, Informative)

      by Anonymous Coward
      You don't deserve that "insightful" moderation. First of all, XUL isn't an original idea, either. XML for GUI layout is as old as XML itself, and for a GUI layout separate from the code, earlier examples abound. Heck, VB had FRM files which provided layout information that would work just fine without any code inside.

      Second, it's plain stupid to say that MS "probably haven't realized" that this makes cross-platform development easier. As a matter of fact, the only assumption which makes sense is that they

  • This sounds similar to how VB .NET works. Just have the application provide the logic, but let the OS take care of the GUI.

  • On the surface, this looks like it could be the poor man's way to replace VB. (Like your average poor man could afford Windows anyway.) The one thing about Longhorn that intrigues me is the fact that MSFT is apparently trying to abandon a great many outmoded paradigms. XAML is just another example (though not entirely original, as suggested elsewhere). I have to admit a non-trivial amount of morbid curiousity as to seeing how the whole system will ultimately work.
  • Looking at the skewed listbox, is Longhorn's theming going to be vector based? Maybe WVG?
    • If you are seriously asking about it being Vector Based, you would be correct. It IS vector based. The last meeting I went to had a couple MS employees showing off Longhorn and highlighting all the cool stuff which included vector graphics for even icons. Pretty interesting things.

  • Looks pretty good (Score:3, Informative)

    by spitzak ( 4019 ) on Tuesday December 16, 2003 @12:00AM (#7731636) Homepage
    Definately NOT a new idea, but it may establish a standard, which is just as important as having the idea at all. I don't know if Microsoft realizes that with this text base it is going to be very easy to clone on other platforms. Perhaps they don't care, or perhaps the developers were able to actually write what they wanted, rather than what management told them to write.

    I must point out that I invented the "Grid" layout in 1992 at Sun Microsystems when I was working for the NeWS TNT group (TNT = The NeWS Toolkit). I called it "GridBag" because all collections in TNT were called "bags". I implemented it in NeWS and then copied it to OLIT (an Xt-based toolkit), it appears my OLIT implementation was copied to make the identically-named GridBag in the various Java toolkits (this is evident from the names of variables and methods). It appears Microsoft has copied the functionality for this (since they did not realize that it can do what their "dock" panel does and did not merge them). It does appear that GridBag has the most life of anything I every wrote and I have no complaint, but it would be nice to get some acknoledgement. (legally I cannot demand any acknoledgement, I wrote it while employed at Sun and it belongs to them).
    • I tried to post the code but the filter won't let me. Here is instead the "help" I wrote to go with GridBag for TNT: (somewhat mangled to get past the lameness filter). This is dated August 6, 1992

      ClassGridBag

      Frustration with making ClassPanel do what I wanted made me create this new tnt class. It is a subclass of ClassBag and I think very fundemental, for instance ClassBorderBag could be a subclass of this.

      It's layout rules are not as powerful as /Calculated layout but they seem to be sufficient for alm

    • I have always preferred using a good layout manager over a drag and drop GUI builder. Look at most VB dialog boxes. Most of them can't be resized and they have ugly "Chicklet" buttons. The first Grid like layout manager that I used was the Table widget that came with WCL (GUI stuff for X-Windows/Motif). I am looking at the code and it contains the names David Harrison and David Smyth, with dates of 1989 and 1991. I don't mean to belittle your contribution but I just want to add some history to grid st

      • I believe my main contributions was that resize was controlled by identifying the rows & columns to resize, rather than individual child widgets. Also the ability to make a widget occupy more than one cell (though there was precedence for occupying an entire row or column).
  • Isn't one of the reasons HTML sucks is because it merges content and formatting?

    Have we learned nothing? Are XUL and XAML just for the default layout and values?

    What do these do to make adding/changing/reading user input any easier? Can you assign an independent name/number/resourceid to buttons and such? Did MSFT learn nothing from ripping off Java and the pitiful AWT checking by name that was sooooo fragile? How well does that work with i18n?

    Isn't SVG supposed to do all that graphics stuff?

    Why di

  • XSL Transformations can transform a well-formed XML document into another well-formed XML document using DOM manipulation. Since these aren't binary files (i.e. they are scripts interpreted by the browser, not code independently executed by the OS) and IE is embedded in Windows, a transformation wouldn't spawn a separate process that could be detected by an anti-virus program. Your browser would pick up the XSL virus file from a web site and interpret it itself.

    I'm not a security expert, but wouldn't it

  • When is someone coming up with a real good language for specifying applications. This is yet another language for describing the graphical interface of an application. And as such it adds nothing new! Just another technology for something that we already have dealt with before. I am waiting for the first frame work that gives you the ability to query and edit data in a consistent manner, without having to write code for every single query/insert/delete/update statement myself. That provides you with built i

  • About KDE (Score:2, Interesting)

    by rikkus-x ( 526844 )

    The idea of using XML to describe a user interface is nothing new, though that's not a criticism of Microsoft.

    I think KDE is a good example of how XML can be used in this way successfully. KDE uses XMLGUI to describe the menus and toolbars of a window, for example, here's Konqueror's menu and toolbar structure [kde.org].

    KDE also uses XML to describe the 'work' area of windows. The XML is created by Qt designer. Example: kcontrol's mouse configuration dialog [kde.org].

    Qt designer gives the XML a little more power, allowing y

  • Correct me if I am wrong, but looking at the code online, it looks like it is only a GUI placement specification - is it possible to say connect a button to a VB/JavaScript ? If more intelligence is not provided with the controls, whats the use of the controls ?

  • This is a mess, not for serious coders (Score:3, Insightful)

    by Viol8 ( 599362 ) on Tuesday December 16, 2003 @08:36AM (#7733479) Homepage
    I'm sorry , but I shudder at the thought of having to "code" in this unholy mess of a "language". SGML and HTML upon which XML are based were meant to

    be typesetting/dexcription languages , they were NEVER meant to be coding languages as as such their syntax is not geared towards that use. To try

    and shoehorn coding concepts into XML simple because its the current flavour of the month in marketdroids and other gullible types on the fringes of IT
    does NOT mean it should be used for this. And how exactly is this an advance over other supposed 4GLs anyway? What does it do that they do not? Nothing as far as I can
    see apart from giving the coder a headache. The only possible use I can see for it is all those 3rd raters in the web industry who learnt HTML and suddenly thought they could code
    and now heres a language to try and convince them they're right. Well sorry guys , you're not coders and you never will be until you learn a proper programming language.

    • Re:This is a mess, not for serious coders (Score:5, Insightful)

      by rbolkey ( 74093 ) on Tuesday December 16, 2003 @10:29AM (#7734268)
      Although I empathize with your sentiment, you obviously have no clue what your talking about in reference to the actual article submitted(yes, this is slashdot, big shock). The article's comment is a little misleading, this isn't for coding, it's for interface layout, which XML is quite effective at if you've ever touched XUL. XML is heirarchical. As are most, if not all, common GUI components. And separating logic from layout is A Good Thing, which XUL performs more cleanly than most toolkits I've seen (Swing, Windows Forms).

      The true measure of the impact of a technology is how many highly effective solutions you can find that it wasn't really intended for. This is one for XML.

    • Umm... (Score:2)

      by Slur ( 61510 )
      ...It's likely that a visual interface builder tool will write the XML on your behalf. As with most such interface builders it will provide snapping and layout hints to make sure things are well-spaced according to UI guidelines. There should almost never be any need to hand-code an XML description of the GUI. Many coders already build UIs with visual tools, and the use of XML behind the scenes isn't going to make a difference to bad design.

      I base my outlook on the fact that Interface Builder (NeXT, Mac OS
  • Here's a good video introduction [microsoft.com] to a lot of the new things being worked on for Longhorn. It shows demos of XAML-based apps. Including things like vector scaling and rotating a text box, then spinning it while playing a video in behind and still being able to type. Not practical, but shows the depth/richness of the vector-and-XAML-based engine. Also check out PDC Bloggers [pdcbloggers.net] for lots of inside info about the new architecture(s).

    I think a lot of this stuff is very interesting, even if you don't live in the MS
  • Is it just me? More Innovation(TM) out of Redmond! I personally am tired of hearing about XML based things that are XML-based (or worse XML-like) for the sake of "buzz" compliance. This isn't just a slam on Microsoft, it's all the companies that are looking for a way to jam the letters XML into their marketing pamphlets.
    • I have to agree with the sentiment here. I first discovered XML when creating a Java Servlet based application. I wanted an easy and flexible way to create messages between the servlets in my application. Of course this was when SOAP was still called XML-RPC. I thought that XML was well suited for describing messages and document structure.

      I think rather than replacing VB, XAML could replace the ugly mess of asp: tags in an ASP.NET application. :)
  • Anyone who has used IB is yawning now . A lot.

    IB is Apple's (from Next) tool that allows you to point and click create a UI. Why even bother with XML when you can just point and click to create the gui and hook it up to real code.

    Thus you can have 2 seperate teams, one for designing the nib files and one for the gui. Course this doesn't really seperate out so easily, and the GUI doesn't take much time to create, but the point is that people higher up can create or change the interface without bothering

  • What ever happened to "Transaction Authority Markup Language (XAML)" [coverpages.org]?
    It would appear that the xaml.org website is no longer online.

  • ok, i'm maybe the only one around here finding it kind of positive what microsoft is doing here (and that happens only every 2 years...)

    i'm wondering wether it's possible to modify mozilla xul [mozilla.org] engine so far that it reads this XAML stuff... (ok, bindings are different and so on but:)

    =platform independent UI

    Rule: native windows L&F / modified XUL for the rest of us. this would result in "usable" projects (instead of gtk2 port for windows / qt $$$$$ / slow java / problematic .net|go.mono)

  • Since NextStep there has been an interface builder tool, and it has evolved with the Mac OS X developer tools into the modern Interface Builder we use today. Interface Builder lets you build GUIs which are encapsulated into NIB files (stands for NeXT Interface Builder). Well, cool, NIB files are XML files. The GUIs you build in IB can be used to front-end applications written in C, C++, Objective-C, AppleScript, - and I believe perl and python as well using bridge modules.

    Now, of course, on Mac OS X as in
    • One of the more intriguing concepts in Interface Builder is the IDE support for generating controller objects. Is there a description of IB controllers written more in geek-speak than PHB buzzword-speak? I am trying to figure out what they do without a Mac in front of me because I develop for Windows (like, maybe I can be persuaded to develop for the Mac, heh).

      What I think those controllers are is what GoF calls mediators. The controller can be hooked up to data-model widgets as an observer, and it can

    • NIB files are XML files.

      No they're not. The objects in a NIB are stored in a binary format that's known only to Apple. That's why GNUStep's AppKit can't read them directly, requiring you to use nibtool first, to convert them to format it can read.

      Perhaps you were thinking of Renaissance [gnustep.it]? It provides a means of describing a GUI in XML. It works on both Mac OS X and GNUStep, but it's not from Apple and doesn't use NIBs.
      • You're either lying or uninformed.

        I just opened a NIB package, and opened all the files in it - including "objects.xib" in BBEdit. Every single one is XML. Have you ever looked at a NIB file? Where are you getting your information?
        • You're either lying or uninformed.

          Neither, as it turns out. My comments refer to Cocoa nibs, not Carbon. One would think that the reference to GNUStep and Renaissance would have made that clear...
          • D'oh! Well, shows how much I know at this stage in my Mac programming career! Okay, then. You're officially truthful and informed.

            Well, damn, now I want to find out more about these mysterious Cocoa NIBs and see where they have analogs to Carbon NIBs....

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close