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!
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!
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
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?
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.
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.
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.
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.
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.