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."
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
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.
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 must be doing it for this reason. At the very least, it may simplify their huge investments versions of Office which run on both Windows and Mac platforms, for example.
The fact that you refer to a "DTD" for the XML means you haven't been keeping up with XML. DTD's have been outdated for YEARS now. But that part of your comment in general was simply obvious and redundant. However, it becomes even more ridiculous when we reach your concluding statement, which amounts to, "If you have .NET, you can run .NET stuff." Hey, thanks, Skippy!