Slashdot Mirror
Introduction To XAML
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."
XML is meant to be interoperable.
How well does XAML achieve in this regard?
'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?
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
Another language and still no progress. When will CompuSci people stop re-inventing the wheel and go out and invent something.
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.
"1984" was ment to be a warning, not a guidebook. You hear that Kim Jong-il!? BushCo?!
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?
Operator, give me the number for 911!
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.
The idea of XML-based interface definition has been around well before XAML. There are a ton of XML user interface languages around: http://xul.sourceforge.net/. Hell, Mozilla is built around it: http://www.hevanet.com/acorbin/xul/top.xul
Another method for virus!
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.
Only 'flamers' flame!
Does slashdot hate my posts?
This sounds similar to how VB .NET works. Just have the application provide the logic, but let the OS take care of the GUI.
I really hate Dan Patrick.
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?
Yet another signature that refers to itself. The irony and humor is dead.
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
/Calculated layout but they seem to be sufficient for almost any UI panel I have ever seen. It's response to being resized is much better and controllable.
/setgaps sets a space between each row and column of cells. The /insets (same as ClassBorderBag) sets a space around the outside of the grid.
/nameforcell name true | false
/type] client /addclient -
/type is optional. If missing the client is resized to the size of it's rectangle. If given the client is left at it's /preferredsize and justified against one of the edges or corners. /type is a compass direction such as /East or /North, or /Center to put it in the middle. Technically the /type is not necessary because the client could justify it's own display but this avoids a huge number of subclasses of controls and labels just to make different justifications.
/North).
/removeclient => client true | false
/setgaps -
/setinsets -
/insets ninset einset sinset winset
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
Layout is done in a rectangular grid of "cells". But the size of the rows and columns is not fixed or equal! Instead they depend on the maximum of the dimensions of the clients that are in them. Cell 0,0 is in the upper left corner. The grid is dynamic, the lower right cell depends on the current clients.
[x] [y]
Each client occupies a rectangular set of cells (not just one!). They should not overlap, although ClassGridBag does not enforce this. The client's size and postition is controlled by the outside border of the set of cells, the divisions inside do not affect it. A clever algorithim is used to choose the row and column sizes so they are all as small as possible whatever the arrangement (well, almost).
When the bag is resized, all the "delta" is divided equally between rows and columns identified by ResizeX and ResizeY. If these are empty the cell array is simply centered in the bag.
Public stuff:
/ResizeX array (variable)
/ResizeY array (variable)
Arrays of row and column numbers to resize. Negative numbers mean gridsize-abs(x). The default ResizeX is [-1], ResizeY is []. Subclasses would want to override these variables.
x y
Return the name of the (first) client which occupies the given cell. This name can be used to get the actual client.
[x y w h
The "layout parameters" of a client are an array of either length 4 or 5. x and y identify the top left cell and w and h are the size of the rectangle.
To allow access to the dynamic grid size, zero or negative w or h mean max(1,gridsize-abs(n)-x). This means that 0 w or h indicate "to the end of the row/column".
The
The type may also be an integer, this helps C code a lot. The compass points are determined from the array:
7 8 9 (i.e. 8 is the same as
4 5 6
1 2 3
name
Removes the client. The total grid size is recalculated.
[x...] [y...]
Sets the gaps between columns and rows of cells.
/gaps [x...] [y...]
The current gap settings.
ninset einset sinset winset
Sets the insets around the edge of the items, invalidates the panel.
-
Returns the current insets.
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 did they have to reinvent the wheel, and make it a 1980's HTML 2.0 wheel at that? How many people think tables are 'the way' to do layout? Didn't HTML 4.0 change all that with <div> to break free of table layout hell?
Maybe I can't see the forest through the trees, but it seems like an idea full of compromises. XAML looks like something that needs to be split into two pieces a resource palette and a layout document. Not merged together ala HTML.
---- Smokin' another sig.
I'm not a security expert, but wouldn't it be easy for a script kiddie to replace a standard Windows XAML GUI file to switch the OK and Cancel buttons in a dialog box or to make them both perform as the same button?
I suppose Windows could run a checksum against every OS file on access to make sure it hasn't been altered or replaced, but then you'd have to have a backup of the whole OS including the updated versions of files updated by patches on a hard drive to continue what you were doing without a period of hassle.
Can XSL files interpreted from web sites even do transformations on local XML files? Hopefully there would at least be a security prompt (dialog box from XAML file? Ha!), but it would be a nifty ability for legitimate web applications.
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 in undo/redo functionality and things like locking. A frame work where you specify data manipulation, instead of having to implement it over and over again. A frame work that let you generate single tire, two tire, tree tire, or what ever many tire systems, using any possible web-based or non-web-based communication protocol with the push of a button.
With Longhorn having been dubbed Longhaul by the Register for stretching even Microsoft's flexible definition of a deadline, how is this important?
.net before they can get anything useful out of it.
Probably a very nice idea, badly implemented like VB, and will be overtaken like
My impression is that MS will be dead (like IBM is dead) by the time Longhaul ships. If it ships.
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 also uses XML to describe the 'work' area of windows. The XML is created by Qt designer. Example: kcontrol's mouse configuration dialog.
Qt designer gives the XML a little more power, allowing you to set up connections between GUI elements within the XML itself. For example, you may specify that you will have a method named, e.g. 'addButtonClicked' and make a connection from your 'add' button to that method inside designer, by drawing a line. This connection will then appear in your code at runtime. All you do is implement the method and wait for it to be called. Examples of this can be seen in the above mouse configuration dialog XML.
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 ?
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.
Here's a good video introduction 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 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 world.
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.
Insert pithy comment here.
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 the coders, which is a major goal of this XAML im sure.
What ever happened to "Transaction Authority Markup Language (XAML)"?
It would appear that the xaml.org website is no longer online.
Examine my flame!
( * )
V
V
For grins, I did some Googling about what it would take to poke at Java objects from C++. There are a number of commercial and open-source projects to do just that, but golly, the C++ program has to launch a Java JVM, and then you have to create C++ proxy objects for the Java objects, and then you have to fret lifetime management and omigosh, what about thread? Now since C++ and Java are vaguely similar C-like OO languages, you probably are better off doing everything in C++ or everything in Java. But the point is to do something like that, if there was a requirement for it (how about a legacy Windows app using student-written Java plugins -- remember they are required to learn Java, not C++), it would take the better part of the semester to get my flock of PHBs up to speed. The Matlab thing can be handled in one class period.
Ok, scripts and RAD and such will allow PHBs to sully the reputations of programmers by generating garbage. I will take that risk so I don't have to labor in the salt mines of coding -- I have paid my programming dues writing thousands of lines of Windows API code, and I want to write scripts and use RAD in my lazy old age.
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 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 other Unix-like OS's, the GUI you build and script can invoke any of the facilities of the OS, command-line, libraries, frameworks, shell scripts, daemons, processes, and doodads. This is of course the kind of power X-Windows coders have enjoyed perhaps longer than anyone else. But a lot of this capability existed in NeXT as well.
Recently a very interesting and cool desktop widget engine called Konfabulator was released for Mac OS X. And of course, its interfaces are built in XML. The code that primarily interacts with the GUI is written in Javascript (aka ECMAScript). From JavaScript you can invoke any of the facilities of the OS. The possibilities are staggeringly neat. People have programmed everything from "top" front-ends to action games. PNG is the preferred graphics format for building GUIs due to its powers of translucency. But of course you can independently set the translucency and layering behavior of any widget.
The thing that appeals most to me as a programmer is the systematic reinforcement of the MVC design paradigm at the operating system level. Abstracting the GUI from the code is a good idea and it's good to see MS catching on at last. Earlier attempts at RAD solutions on Windows have always had a kludgy feel, or tied you to a particular framework. Making a modern GUI engine a part of the OS foundation will not only simplify development it ought to eventually lead to a more compact and clean OS in general.
-- thinkyhead software and media
...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 X) has long used XML for its GUI description files, and there are unlikely to be a dozen coders in the world who ever hand-edit the suckers. And I personally like both the abstraction of the GUI from my application and the use of XML behind the scenes.
XML is well-suited to the kind of data pertinent to a GUI, and it's infinitely open-ended, which is good for any evolving framework. It doesn't hurt that it's human-readable either.
-- thinkyhead software and media
I must agree. I do it all the time.
-- thinkyhead software and media
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 be hooked up to display widgets so it can write stuff. Furthermore, it can be plugged in as an observer or plugged in to get access not just to a model or a view widget wholesale but to particular fields of such widgets using some kind of proxy objects that resemble C# delegates.
Why I think this is important is that VB, Delphi, and their ilk implement Mediator pattern, but the Mediator is wrapped up into the main form -- it is like the controller setup only the main form is the controller and you get only one controller for the entire form. A lot of the complaints about spaghetti code in VB, I believe, have to do with the main form acting as traffic cop for all the communication between widgets on the form. The IB controller seems to separate the mediator function from the main form and allow you to have as many mediator objects as you have data paths.
One advantage of the one-size-fits-all VB approach is that the mediator needs to be an Observer, and if the mediator is the main form, you know that this Observer is going to stick around for the lifetime of the child widgets being observed. If you allow widgets to directly talk to each other, you have to have some kind of registration/notification mechanism in case widgets are created and destroyed at runtime. How does IB handle this? Or are the widgets on a form fixed by the NIB file and not allowed to be created or destroyed during program execution?
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?
-- thinkyhead software and media