Have a look at some of the KJSEmbed examples, or even more powerful (and building upon KJSEmbed), kdenonbeta/kaxul. kaxul takes Mozilla's XUL files and makes a native Qt GUI for it. The code is interpreted Javascript so it runs everywhere without modification. No compiler is required, just an interpreter. KDE has been ahead of Microsoft on this for over a year now. Mozilla has been leading the way with this for even longer, though I still don't like their widgets. :-)

The main thing is that XAML is really a Microsoft version:
XUL + SVG + JS + .NET framework
probably using ActiveX and Internet Explorer for "Web Apps"
and using CLR for Windows Apps.

Like KaXUL, it is expected that XAML will be translated into CLR code.

Obviously, comparing XAML with Qt is non-sense,
but comparing something like KJSEmbed+KSVG+KaXUL with XAML do makes sense.

Obviously anyone could create that XAML example,
in VB, HBasic, Qt Designer, C++ Builder, Visual Studio or any similar,
that's not the point.

The big issue here is that W3C is still bogging SVG
to include any serious add-on like XUL or even MathML,
currently it's not even sure we will get XForms... before Xmas!?
So, we would need some standard format that includes all those technology
in one XML namespace to compete with XAML.

So, basically it's like comparing some sort of Advanced .ui with XAML.

Are we getting any complete XUL/SVG renderer in Konqueror any time soon,
using a widget factory or similar?

Currently, KSVG is far behind ASV3/ASV6. =(

Basically, the point is to have the full feature sets before Microsoft
and once Microsoft launch Longhorn provide a simple XAML converter to
whatever XUL+SVG format established.

Yes I saw that, and downloaded the Nove Hrady presentation. It wasn't exactly Earth shattering, but it was certainly extremely interesting.

Although I don't see it being used for the things that Microsoft seem to be hyping it for (what are they hyping it for?), it should be interesting for form design (Kexi, office tools?) and various other exciting things I can't think of right now.

I haven't had anything to do with MS since I walked away from their sad excuse for software in the mid 90s. Back then I suspected that they actually added complexity to their coding requirements as a means of raising the barrier of entry for competition. Of course with Gates saying "everything is an object" and evidence I've been seeing for years indicating encapsulation and reuse are things they may discover at some later date it's possible there is another explanation.

The thing that is really fascinating here to me is the fundamental aspect of programmer efficiency. I remember at the advent of C++ the big point that was being made was that you could do "more in a line of code" and thus reduce the number of lines of code to do a task, producing more results from a programmer who is going to produce x lines of code in a day.

So if this example is effectively the same, as it appears to be, then using Qt not only provides cross platform benefits (which was and still should be the holy grail in programming) and a lesser level of frustration, but it is hugely more efficient. I expected it to be more efficient, but this example is remarkable... 60 lines compared to 200 is a savings of 70% and well worth while for the MS example. 11 lines compared to 60 lines is a savings of 81.67% over the XAML example and 94.5% over the raw code example!

That would seem to indicate that in the type of work done in the example a developer would be half way through his sixth dialog with the same number of lines of code as the XAML developer used to finish his first. Given that there is more than just coding here it is likely less efficient, but should still realize a result for that task of being at least twice as efficient. That's remarkable!

I continue to think that the MS advantage is held in place by a thread (held by bullies) and that there is a good reason they fear real competetition. How long can the emperor have no clothes?

Be careful when making claims. Qt/Mac is a step up from having to run X11 to get the app, but it doesn't use native interface elements, it uses it's own cheesy implementation of the Aqua UI primitives. It looks quite ugly in some cases, especially in Panther, where the old-fashioned tabs look out of place. TrollTech really needs to do better.

I can assure to you that Qt _is_ native to the Mac: in fact, it uses the Appearance Manager to draw widgets just like Carbon and Cocoa do. The code is fully open source and in qt/styles/qmacintoshstyle.[cpp/h].

Now, there are a few bugs with the current implementation, especially in panther, but they will be fixed. Many of similar off-by-one bugs existed in early versions of Carbon on OSX, especially before MacOSX 10.1.5.

The main problem is that the Mac has a much more advanced GUI system then you'd find on any other platform, thus making emulation very difficult. I wonder if Trolltech should try a wrapper-based approach to Qt/Mac. This is already done with QMenuBar, and it probably could be done to the rest of the widgets as well. I believe this is how Java on the Mac works as well. wxWidgets definitely works this way.

Of course, this might mean losing very obscure functionality, like painting arbitrarily on a QPushButton, but for 99% of the use cases, the benefits of wrapping the native widgets would outweigh this loss. Maybe Qt could fall back to an emulated widget if someone performs such an obscure operation. If I wasn't so busy I might actually try implementing this, as it sounds like a lot of fun (if a lot of work).

In addition to this, the Mac supports advanced widgets, like the preferences dialog stuff. It would be nice if there were a way to take advantage of these widgets in a Qt/Mac app. Years ago, this kind of widget reuse just wasn't seen, but nowadays with KDE and Mac, there are lots of advanced widgets available, and "plain Qt" apps definitely stick out by not using them. We're entering the next generation of desktops, and being a native app is more than just using primitive widgets these days. Trolltech's got some work ahead.

XAML has the ease of use of XML/HTML, everyone can write a GUI on XAML with minimal training! That was the point of it!
Qt is a C++ toolkit and no matter how simple it is, it is still a C++ toolkit and the programmer will have to know how to use the language, compilers, debuggers and all things that come with it.

Please people, be objective for once, that "XAML vs Qt" article is a joke. The author obviously doesn't get what XAML is and what its goals/advantages are in the first place.

The author, I believe, does 'get' what XAML is. XAML is _not_ a system for allowing people to write GUIs without recourse to a 'real' programming language. Even if you were to try and write your application's logic entirely in the XAML dialect, you would find yourself needing a similar depth of understanding to the person using a 'real' language; you would also be stumped as soon as you tried to do anything non-trivial.

Also on the subject of programming, who stipulated that you must write your app in C++? Write it in Python if you wish; then you get to forget about the nasty C++ compiler and debugger.

I would also say that anyone can write a GUI with Qt, with minimal training, if they use Qt designer, as I did. What exactly will be the difference between XAML with an interface designer and Qt with an interface designer? Not much, I would say.

I second that. I made a GUI app in PyQT in one month, language and object concepts learning included. It's not extremely efficient, it's probably ugly in many senses but it does what I want. I can't expect XAML to be any simpler or faster to develop.
BTW, the only language I used before coding this small app was Fortran.

You are both correct and incorrect. True, with XAML anyone can write a GUI with minimal training. But that GUI will be just a GUI. Nothing more. Without code behind it, it will be merely buttons and widgets that do nothing but look pretty. I can do the same thing with Qt Designer. Heck, I don't even need Designer, I can write my own ui file knowing only XML!

While XAML may have a few "featurettes" that Qt does not have, Qt gives you a complete easy-to-use development environment. Even if you don't know C++, you can still create the GUI. So while XAML gives you a screwdriver, Qt gives you a screwdriver, wrench, hammer and saw.

"True, with XAML anyone can write a GUI with minimal training. But that GUI will be just a GUI. Nothing more. Without code behind it, it will be merely buttons and widgets that do nothing but look pretty."

That's what I thought. It is even more pointless than I first imagined then. Are Microsoft actually selling this crap to people?

What I don't understand is why the MSDN article is showing you the XAML code and how to write it, because you're obviously going to need an IDE for this to really work for you, so it should all be transparent really. We've already got this in Qt Designer, and it produces XML, so I just cannot comprehend the hype some people are attributing to this thing.

This was useful, if only to ram home to me how totally pointless XAML is.

Oh, please - neither of you have the first clue what XAML actually does, and the same (sadly) goes for the author of this article. I really don't like Microsoft or its products, but even having said that I have to admit their implementation of XAML is damn clever.

For your reference, the XAML code is designed to lay out GUI objects. You have this much correct - you can put in tabs, buttons, menu items, etc. All things that XML describes very well.

However, that XAML can then have scripts added to it either in a compiled language (such as C#) or a script language such as JScript. One XAML file can contain a complete application written in VBScript and XAML: both very, very easy (if somewhat verbose and slow) languages. Comparing it to C++ is very stretched, and not accurate - XAML allows you to /fully/ separate design from the code driving it (a place that Qt Designer is rapidly approaching, as opposed to the 95% separation we have now), which means developers can be beavering away in Visual Studio with their C# whilst the designers are pointing and clicking to make the GUI look nice.

As far as I'm concerned, having the GUI defined in XAML and the code written in C# makes life much easier for the Mono developers, so everyone's a winner.

Honestly: did you really think MS made a technology that did nothing but display a fancy GUI?

"However, that XAML can then have scripts added to it either in a compiled language (such as C#) or a script language such as JScript. One XAML file can contain a complete application written in VBScript and XAML: both very, very easy (if somewhat verbose and slow) languages. Comparing it to C++ is very stretched, and not accurate - XAML allows you to /fully/ separate design from the code driving it (a place that Qt Designer is rapidly approaching, as opposed to the 95% separation we have now), which means developers can be beavering away in Visual Studio with their C# whilst the designers are pointing and clicking to make the GUI look nice."

Yes I did know that, and it is still rather pointless. It may be of use to Windows developers, but not to others - that was the point of the article.

"Honestly: did you really think MS made a technology that did nothing but display a fancy GUI?"

I got to go with Anon on this one. As much as I love Qt and usually hate microsoft tools I got to admitt that XAML is a good idea (although not completly new) and that it is not possible to compare it to Qt.

One point that I don't think anybody has mentioned yet, is that XAML allows you to use the same code for web pages as for applications. This is pretty cool in a way.

However I am one of those who think that one should not blur the distinction between the web and desktop applications like Microsoft is starting to do.

They should be treated separatly. In this respect I am not sure if XAML will be such a good idea. It might end up totally webifying all Windows applications.

I can also see that something similar should be possible to achieve with Qt without to much modification. We allready got the XML definition for the GUI. One only needs to expand it so that it can be understood by a web browser.

Lastly I think something similar to this is already possible with Java.

""One point that I don't think anybody has mentioned yet, is that XAML allows you to use the same code for web pages as for applications. This is pretty cool in a way. "

Where do you think this is heading?"

Into further webifying of the windows desktop. The distinction between web applications and desktop applications is going to be blured.

Perhaps the whole windows OS will eventually be a mixture of web services running locally and remotly. For instance that when you run regular apps like MS word, part of the functionality of the program will be provided by web services or something.

> XAML has the ease of use of XML/HTML, everyone can write a GUI on XAML with minimal training! That was the point of it!

This is easier than drawing it in Designer and getting the XML generated? Irrational!

> Qt is a C++ toolkit and no matter how simple it is, it is still a C++ toolkit and the programmer will have to know how to use the language, compilers, debuggers and all things that come with it.

Grab a copy of Kommander. You can build and run dialogs that assemble text to make strings, call DCOP or run applications. You can also use the scripting language of your choice as well as control the CVS version with DCOP. All of this in a non complied dialog based application with no C++... and you still get to draw the interface.

I think that beats what you're selling for ease of use for the common person.

The discussion concerning the inadvisability of XML over C++ (or Qt or Java or C#, et al) misses some fairly major points. When you're working with Algol based languages or frameworks, in general what you are doing is creating an imperative description of process -- call this function, pass this result to this store, change the state of this entity -- in a very linear fashion.

Algol languages emphasis DOing things. and typically the aggregation capabilities that are characteristics of GUI-centric languages such as Visual Basic, when converted into this type of code, can often become very cryptic, heavily dependent upon object APIs and tied to one host environment. I believe that it is this reason, more than bad coding practices directly, that is responsible for the plethora of truly bad VB apps.

XML based coding on the other hand, tends to BEing, rather than doing. The aggregation and encapsulation that is often the most complex part of maintaining state within C++ gets implemented for free, connectivity between components is defined more in terms of passing agreed upon XML structures through URL linking, and the API for interaction becomes a common one, namely the Document Object Model.

The significance of this should be obvious, though its usually not. I write an XML structure, and so long as I'm consistent within the language I've defined, it does not matter which platform I'm running on. Moreover, the code can be ported in and compiled into whatever the native platform formats are on the fly -- rather than passing the binaries (or even a low level IL like Java) you just pass the description of the environment.

It's not a perfect approach, of course -- there are places where XML is not appropriate. However, as someone who's been working with XML related programming issues for the last eight years, I've found that XML as a language descriptor is in fact far more powerful than the number of lines it saves a programmer would indicate. It can be generated dynamically, it can incorporate multiple outlier streams of content transparently, and can often hide the nasty issues of dealing with different data representations by using an XML bridge, such as that from a SQL database or LDAP directory.

If you use XML like C++, you will of course receive none of these benefits, because the underlying conceptual model is completely different (and even somewhat antagonistic).I see XML as being post-OOP, requiring a different paradigm for handling well, and capable of eliminating much of what currently exists in the procedural world.

What the hell is the point in XAML? Surely you can take .ui files, or XUL and with some work accomplish exactly the same thing. It doesn't mean a damn thing.

Besides, if your application is too complex for XAML, I guarantee you that it will quickly become a terrible nightmare very quickly. You will defintely have to use some sort of IDE for this, and since you will be doing that anyway, what's the point? Whoever wrote the MSDN article has obviously never thought about that. Dude, that's what programming languages are for. This is yet another absolutely pointless idea (trying to takeover the Internet?) from the boys in Redmond that is dangerous in the wrong hands. I can see some truly awful project failures due to some people saying "Oh, we can just use XAML". It also gives fuel to the people who say that XML is pointless.

I have no experience with XAML but I have used XUL to create a non-trivial application. That application turned out to be a failure in many ways, but it did enable me to realise that XUL is a flawed implementation of an otherwise sound idea.

Some people have compared XUL/XAML to Qt but they are not quite the same. I think the difference is more that the two technonogies foster different methodologies. In a Qt or VB type designer you place a widget and set its properties; likewise with XUL.

The end result is somehow different though. The XUL developer creates more widgets since its so easy to do and since it keeps the UI code clean. The XUL developer may also create smart widgets that have environmental awareness so that they change their behaviour dependent upon the widgets around them. This is likely possible in Qt, but it's easier in an XML UI language (XPath dependent methods or layouts, etc) and enables richer functionality to be expressed declarativey, again allowing the main UI code to be kept cleaner.

So the difference is more that the XML UI developer is more acutely aware of the mess he is making to his UI file, and has better tools to create widgets that allow him to express more of that functionality in a purely declarative manner. The disadvantage of this is that re-usable widgets take longer to code, but the advantage is that non-programmers that can understand declarative markup languages can create richer UIs before needing a programmer to take over, since the creation of richer widgets by programmers is more encouraged in the first place.

We've seen this before. Creative WEB designers using Java applets for all kinds of UI enhancements. Applets that came with the designer tools. Big disadvantage was the limitations of HTML and heavyness of Java VM. So we have Flash these days. But interaction between make up language and plugin objects is still poor.
Wonder how this will develop. If designers are able to create fancy looking pages with highly interactive/controlable .net objects (*), that may be the next step in network applications indeed.
(*) objects run in a sandbox, likely companies specialize in selling/sharing these (like with vbx)

I find it amusing to see people constantly reinventing the wheel. Rik's article is just one example. At work we're porting an old Motif application to Windows. One person is doing an evaluation of porting *just* the GUI using a motif-to-win32 conversion tool. He's spent two weeks on it so far, and is still not quite done. Funny thing is that I did the very same porting as an experiment two years ago using Qt Designer. It took me one day at the time.

They're reinventing the wheel for one purpose: a moving target. Whatever is 'the norm' on MS-Windows will be what developers expect when they think of moving to KDE or GNOME. And, of course, KDE and GNOME have just about caught up with what the current MS-Win can do now, so they've gotta move the gaol (or should that be gaol?)

They're reinventing the wheel for one purpose: a moving target. Whatever is 'the norm' on MS-Windows will be what developers expect when they think of moving to KDE or GNOME. And, of course, KDE and GNOME have just about caught up with what the current MS-Win can do now, so they've gotta move the goal (or should that be gaol?)

I thought the point of XAML was for microsoft to be able to replace HTML with something which describes and renders richer applications - applications which are more akin to a typical GUI app than a web page with a form embedded in it.

Obviously, the key word here is "renders". HTML web browsers, as we know them, won't render XAML applications, but isn't XAML intricately bound up with .NET? I read an article about this a few months back (sorry, forgotten the link) and I concluded that IE6 is the last visable, seperate browser in windows because future versions of windows will have this new superbrowser/.NET capability built in.

I assume the goal is to be able to download an interface description in which the screen controls are bound to server-side event handlers in the same way ASP.NET works now, the difference being that the client is running .NET and therefore is able to render a rich GUI app rather than just an (X)HTML web page.

Maybe QT/KDE could be similarly extended to make distributable web apps with a rich interface possible on Linux. It'll happen eventually, anyway. The Mono crowd, led by Microsoft-admirerer-in-chief Miguel d'incaza, are eagerly implementing their own version of XAML. A nice challenge for Mr. Hemsley et al, I would have thought...

"Whereas GLADE's output routines create C source code that must be compiled, libglade builds the interface from an XML file (GLADE's save format) at runtime. This can allow modifying the user interface without recompiling."

While I'm pretty sure QT doesn't provide that out of the box, obviously we have that power--otherwise Designer wouldn't be able to load it's own data files! And they're an XML format, so there you go. All we have to do to "have the power" as it were, is to refactor Designer's file-loader into a separate library. You know, create like a QWidget subclass called QDesignerUILoader, pass it a QFile pointing to the UI file, and show it. Or something similar, I'm not really a QT developer.

If one of the QT guys would implement this, that would be another bullet point for their widget set. While it takes coders to finish the UI file and make it completely usable, non-coders can take one with the appropriate stuff added and modify it to their heart's content, not unlike having web designers fiddle with templates written in DTML for Zope or Smarty for PHP.

Sorry, but I think that Rik's article completely misses the point, and dramatically underestimates the impact of XAML/Avalon in the desktop field.

The power of XAML is that it allows to create the general content of GUIs, without too much care for its representation (as it happens when you write XHTML). The final rendering is performed by the underlying desktop environment, that applies transformations (a-la XLS) and styles (a-la CSS) to ensure that the GUI always resembles the current human interface policies of the desktop environment (that may change over time). [NOTE: the MSDN article reported by Rik doesn't seem to stress this point]

Regarding actual application logic: it can be embedded in XAML pages, or put in external files, and it could be written using _any_ language supported by the .NET framework (C#, Visual Basic, Java, Javascript, Python...).

It basically means that XAML/Avalon applications are *very* easy to write (using your Favourite Language(TM)), can be approached by web developers (who often have strong GUI expertise), and have the potential of a *very* long life cycle: they can automatically adapt to the changes of the underlying desktop policies and programming environment, since both representation and logic are written using high level languages.

As of today, there's *nothing* in the free software world that resembles XAML/Avalon. The only common point is the XML usage - but sharing an underlying meta-format really doesn't give you much: the important part is *how* this format is used. XAML/Avalon use it as it was meant to be used (a way to store content, without representation), while the free software world uses it as a simple storage medium that also carries representation information.

If big corporations (and developers in general) choose XAML/Avalon to write their applications now, they won't be able to port them on the free software world, and will stick with Microsoft operating systems. It will, of course, force users to stick with Microsoft OSs as well. So we really need a free (and possibly compatible) XAML/Avalon alternative, as soon as possible

Actually we don't know if this will work in practice. Look at HTML it keeps going through some pretty major because what it needs to do changes so much over time that the older way things where done just don't work very well anymore. It is true that old webpages still render in modern browsers but the pages do look old and stuff done now will look just as bad a few years from now. Simple things like Forms are being redone as XForms which are far more powerful and if you want to use those features you will have to change your html. That is true of many others areas also. Your apps don't magically upgrade like you seem to be suggesting since new concepts need to be explained to the system so that it knows that they apply to your app.

Overall the best bet it is seperate the front end from the back end of the app so that it is easier to replace the gui since overall in computing history it seems that the guis need replacing a lot more often then the front ends do.

> Actually we don't know if this will work in practice. Look at HTML it keeps
> going through some pretty major because what it needs to do changes so much over
> time that the older way things where done just don't work very well anymore. It
> is true that old webpages still render in modern browsers but the pages do look
> old and stuff done now will look just as bad a few years from now

It happens because HTML is an inbreed between content and representation.

Things do change when using XML or XHTML: they have been created just to store *content*. The final representation is delegated to other systems (CSS or XLST).

Have a look at an XHTML page rendered without CSS support: it looks as ugly as the web pages written 10 years ago. But once you apply CSS rendering... The magik happens!

> That is true of many others areas also. Your apps don't magically upgrade like
> you seem to be suggesting since new concepts need to be explained to the
> system so that it knows that they apply to your app.

That's the whole point of XAML/Avalon: you just create the "content" of the GUI, the underlying desktop environment will know and apply the "new concepts" to the final representation. It does definitely ease integrating old apps with new (and revised) system GUIs.

> Overall the best bet it is seperate the front end from the back end of the app
> so that it is easier to replace the gui since overall in computing history it
> seems that the guis need replacing a lot more often then the front ends do.

Yes, and XAML/Avalon do allow it: it's always possible to write pure code that interfaces to your GUI, choosing whatever language you want (as long as it works under .NET).

You obviously know far more about this than me, but what you've written seems to bear out my own response, further up this thread. I was a bit too unsure of my facts, when posting, to say outright that Rik's missed the point, but having read your post, I can now say, "I agree". Rik has missed the point on this one.

"to ensure that the GUI always resembles the current human interface policies of the desktop environment"

This sounds more like wishful thinking to me, unless the 'human interface policies' are flexible like bubble gum themselves or the flexibility of creating GUI's (not their content) using XAML is fundamentally restricted. And many of the XAML GUI examples I saw didn't look usable but hideous. Please refer me to some documentation clearing up how the separation of GUI and content you like to emphasize so much should work.

Is that already possible? I think the whole development environment and framework for it to be really applicable is by far not usable in production use as of now, and that will only change when Longhorn is officially released (which will be in several years).

Yes, it may be just complete vaporware and/or poorly implemented stuff... But it seems that Microsoft is really working in that field - while the free software world is completely unprepared, and often underestimates XAML/Avalon effects.

> Please refer me to some documentation clearing up how the separation of GUI and
> content you like to emphasize so much should work.

There's no single reference (at least, I haven't found it yet): the plan can be understood by looking at the whole XAML/Longhorn scenario. If there was a clear explanation of Microsoft plans, maybe we wouldn't be discussing whether Rik's article underestimated XAML/Avalon consequences :-)

And most of the consequences are quite easy to understand: once you have such a XML-based GUI design system in place, integrated with the whole .NET framework, developers won't have to care e.g. about widget positioning and spacing: CSS-like and/or XLS-like transformations may take care of it, depending on the current theme and/or human interface policies. It may not help in *all* the cases (it's always possible to write bad GUIs and bad applications), but it *does* give an additional value that free software can't offer (yet).

One of the actual examples of how XAML/Avalon could work is given by... XUL (that uses the Mozilla rendering engine, Gecko, to apply CSS-like styles and transformations to XML-defined GUIs).

XAML is something like XUL, but applied to native widgets and themes, with a complete system integration (via the .NET framework) and a broader support for scripting languages (while XUL only supports Javascript, XAML supports all the languages of the .NET framework). In other words: XAML/Avalon are nothing new, but it promises to be very powerful and (as of today) free software competitors simply don't exist. See the Edd Dumbill's article I've pointed out for further details: http://usefulinc.com/edd/blog/contents/2004/03/03-gnomeui/read

Sorry, I was unclear. XAML is not production quality, yet - but corporations and developers may start now their planning abut thecnologies to be used in future projects (and that's the whole point of the articles being published on MSDN: they want to influence these choices).

We can't answer to these articles just by saying "I've done the same with Qt and KDevelop", because it really takes into account one of the points (the RAD issue), and completely misses the long-term maintainability and system integration points.

(from the article:) XAML also seems to allow for transformation (e.g. rotation) of widgets. Many systems have provided this facility in the past few decades but as yet I haven't seen it used by any applications. There are some games which use slightly rotated buttons for menus, though, so perhaps game developers will find this feature useful. I'm not sure how you handle resizable layout when you have rotated widgets, though. (end)

XAML is a way of expressing parts of C# classes in XML. That's all. It's compiled into the application and run by the CLR. What most people are seeing of XAML is its application to the Avalon framework. That's what concerns me, most. With the release of Longhorn, Avalon will become the primary gui development toolkit for Windows. It has all the power that you've been gawping over on the Mac, plus a hell of integration work to make it easy to use and develop for.

This is serious, folks. Everything's done with vectors, now. The bitmapped raster ways of the past have gone forever, and in its place is something approximating the capabilities of postscript or pdf. You can do great effects, rotation, shadows, transparency, scaling... and it'll all be hardware accelerated because Microsoft have the power to demand it.

On UNIX platforms we're stuck with bitmaps. You can't put even put a button in your average canvas. Nothing's scalable and nothing's fun to develop awesome user interfaces in. If the Avalon threat goes unanswered we'll be back to the bad old days when you know you're running a unix app because of how crappy it looks. QT must evolve to take advantage of the new features available on Avalon and Quartz, and in doing so it must either bring X11 up to scratch or find something better. The clock is ticking. Everyone has working code but us.

"You can do great effects, rotation, shadows, transparency, scaling..."

That's just eye candy. While you want an interface to look good, you don't want it to look like a Hollywood special effects bonanza. That stuff does nothing to improve the usability of the interface. Hint: the usability improvements of Aqua over OS9 had nothing to do with its transparencies and animations. Those were just to get the media types to pay attention.

If the Avalon threat goes unanswered we'll be back to the bad old days when you know you're running a unix app because of how crappy it looks.

Unix looks crappy? Then you aren't running KDE. Plastik looks better than anything Microsoft offers, and you get to use real color schemes as well. Baghira simply rocks. You can't to anything like this in Windows.

I need scaling and rotation on every-day widgets for my real-world safety-related and well-established work-related problem area. If you can't scale interactive diagrams that describe the state of your power station you don't get out of the starting blocks. Don't try and tell me that it's just eye-candy.

Then go and look at Max OSX. A few minutes of using that and you'll be saying "I wish my user interface was as engaging as this for average users". While low-eyecandy GUIs are good and important in many areas, you can't say that having a toolkit that simply can't do it is a competitive advantage.

Unix used to look crappy? Yes. Five years ago you always knew whether you were running a UNIX app. If we're still where we are now in five years (assuming the longhorn ship date slips a few...) you'll again know you're running a UNIX app. There are places where the toolkits just have to be able to keep up.

For those without broadband, the video shows Avalon with a video playing in the background with transparent buttons and text boxes sitting on-top, rotated, and scaled to a size appropriate for the monitor. This is done by embedding the widgets (and some in-line text) in a text-flow layout, which in turn sits within a transform layout, which sits alongside the video playing in the same position within a canvas.

QT needs to adapt to be able to put everything in a canvas. There can't be any concept of a canvas item that is different from a regular widget. That, at least, needs to be done before Longhorn's release. If we ignore what is possible on other platforms we limit ourselves in where we can go with what we have.

Eh? Being able to scale an interactive diagram has nothing to do with the widget set used for standard applications. I would be very surprised if you could build such an interface with real widgets and have it practically usable - you'd be much better off writing a custom widget, just like you would now. These kind of special purpose diagramming applications have been built for years, without any of the things that Microsoft is proposing.

I'm not suggesting that some of these things aren't nice, but if you think they are absolutely necessary right now (and for mission-critical applications no less!) then I think you've been letting Microsoft whisper into your ear too long.

That's nonsense. Windows default style looks as good as Plastik, wether it is Luna, Win2000 Style oder 2003-Style. The Windows gimmicks (eye candy) work usually better because of higher graphics performance.
Btw, plastik looks good. But KDE (kdeartwork) is shipped with ~ 20 styles with 17 of them are made for trash can or aren't fully implemented. They should be dropped.

"Hint: the usability improvements of Aqua over OS9 had nothing to do with its transparencies and animations. Those were just to get the media types to pay attention."

I beg to differ. All the eye candy in Aqua is not as useless as people make it.

1.Icons: Large icons are easier to hit and click than small ones. The big icons in Aqua makes this possible (that they look good is a nice side effect). The realistic look of the icons makes them easier and faster to identify. In the old days the icons looked so bad often that you couldn't really make out what they represented or tell them apart.

That cartoon look is better than realistic ones is just bullshit. OS 9 use cartoon look on icons and I am much slower at identifying icons in OS 9 than OS X.

2.Valuable visual cues: When you minimize windows you clearly see where the window goes. This should help newbies figuring out where their windows went. It even helps power users sometimes. For instance when you close a palette window in Word for OS X its window is sucked into the button that toggles it. Makes it very easy to refind the button to redisplay it.

3.The vector graphics allows powerfull switching between windows alla Expose. Expose is really awsome. It is one of the great user interface inventions in many years.

4.The scaling effect in the dock allows you to more easily identify the minimized windows.

There are lots of other examples (like toolbars). The point is however that most of this eye candy serves a purpose. Often it gives valuable visual cues to the user about the effects of the operation he performed.

In fact I would argue that XP has useless eye candy and OS X does not. In XP the webish user interfaces often have bitmaps and such to pretty up dialogs. However the bitmaps can't be clicked, display no information or serve any other function than decor. In Aqua the eyecandy at least serve a purpose if not for all users.