Hello, Allow me to highlight the discussion going on over at the KDE Dot News site kicked off by Rik Hemsley's XAML versus Qt tech paper.
fprog26 comments under the heading "Re: Qt can even support no-compilation": KaXUL looks promising... 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. Hopefully, the future looks promising... Dominic Chambers comments under the heading "Re: 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. Full story @ http://dot.kde.org/1080235389 What's your take on it? Any thoughts? Any comments? - Gerald ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
