The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
|
Over 40 comments listed.
Printing out index only. |
OK, own up....
by Paul on Thursday 25/Mar/2004, @10:22
|
Who else here rated the MSDN article at 1?
|
[
Reply To This | View ]
|
|
|
Qt can even support no-compilation
by George Staikos on Thursday 25/Mar/2004, @10:27
|
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. :-)
|
[
Reply To This | View ]
|
|
|
Talking efficiency
by Eric Laffoon on Thursday 25/Mar/2004, @10:49
|
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?
|
[
Reply To This | View ]
|
Except that Qt isn't native on the Mac
by Frodo on Thursday 25/Mar/2004, @11:02
|
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.
|
[
Reply To This | View ]
|
|
|
You GOT to be kidding me!!
by Mambo-Jumbo on Thursday 25/Mar/2004, @11:04
|
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.
|
[
Reply To This | View ]
|
|
|
Pointless
by David on Thursday 25/Mar/2004, @11:42
|
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.
|
[
Reply To This | View ]
|
|
|
Qt to the rescue!
by David Johnson on Thursday 25/Mar/2004, @12:58
|
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.
|
[
Reply To This | View ]
|
|
|
XAML
by Ez on Thursday 25/Mar/2004, @16:47
|
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...
|
[
Reply To This | View ]
|
Glade?
by Dan on Thursday 25/Mar/2004, @21:56
|
Isn't this what libGlade does for GTK? From the webpage:
"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."
Read it here: http://www.daa.com.au/~james/software/libglade/
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.
--
Daniel
|
[
Reply To This | View ]
|
|
|
Missing the point, really missing the point...
by Anonymous coward on Friday 26/Mar/2004, @01:31
|
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
GNOMErs seem to have taken this issue more seriously. See, for example, this interesting article: "What next for GNOME's user interface?" - http://usefulinc.com/edd/blog/contents/2004/03/03-gnomeui/read
|
[
Reply To This | View ]
|
|
|
XAML is good, but the threat is Avalon
by Benjamin. on Friday 26/Mar/2004, @02:49
|
(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.
Benjamin.
|
[
Reply To This | View ]
|
|
|
MFC
by Bert on Friday 26/Mar/2004, @03:54
|
MFC now compile using Wine/gcc. Is it possible to recompile MFC programs with qt.
Qts strength is documentation. However i learned that KDe is not Qt, you can easily watch this by having a look at qt programs such as Hbasic or sketch, they look outdated and different.
|
[
Reply To This | View ]
|
How is this different from ...
by Bruno on Wednesday 31/Mar/2004, @11:32
|
.. KXMLGUI?
http://developer.kde.org/documentation/library/3.2-api/kdeui/html/classKMainWindow.html#a9
|
[
Reply To This | View ]
|
|
|
Isn't it truly just re-inventing flash...
by Charles on Saturday 13/Jan/2007, @08:39
|
flash has been around for years - sadly everyone learnt to use it through an IDE, it really didn't take on the application style interaction untill more and more flash addicts started using it. -today you can build fully fledged applications (as long as the computer on the otherside can handle it) - so really, Microsoft is thinking about cornering and pushing adobe into doing different type of work, and to forget about it's Macromedia purchase, forget about PDF's and restricitng people from being able to work with them unless paying for thier products, I mean out of all the software vendors that make a profit according to volume of sales - adobe has to be up there in the 'rip off' category, eg. Corel Suite vs Adobe CS. -Adobe need to start thinking about merging thier software categories (I mean Ilustrator still can't do muti page layout - it's not like it's more than a couple of lines of code to give it the ability too)
-anyway I'm off topic
.net 3.0 is just a fancy Flash player, and Xaml is the new SWF (albeit an open version) and as the older browsers slowly become reduntant, the new era of networked interactivity will slowly warp the average joes abilty to understand -whether or not their modem is even connected to the net. - using your personal computer will seem more like a kiosk experience instead of the strict OS vendor -> connect to the net and view experience.
I really think it will be great... I just wonder where adobe and the linux community are going to go with it.
Hopefully PC's and other devices will consist of nothing more than framework, eg. Mono or .Net with xml files controlling whatever the framework has to offer (of course with permissions in mind) - I think it will be great - imagine building and stringing together whatever you want without having to compile or buy software, all you'll need is your text editor.
|
[
Reply To This | View ]
|
ACTUALLY better yet!!!
by Charles on Saturday 13/Jan/2007, @09:22
|
--Let's do this (if we had the time!)
set up a linux box that starts up with a MONO version of MSoft's Powershell...
-we'll call this the new DOS... this is the native state of the computer - no gui (or at least no content on the screen) - we do have a gui though just nothing rendered cause we haven't HKStartUI.software.mono.run. Anyway we do that... and the XML parser tells the WPF to load the Contents of HKstartUI - whalla , we have our Kiosk computer up and running , with everything from speech rec to touchscreen control. so as you can tell the future will be interesting when it comes to computing - security permissions will not need be set on things like file structures but instead on XML.net elements ,eg. don't want anyone to be able to draw new Forms on the screen - set the permission on System.Forms to no-more instances than now. -and whalla you can browse the internet and all the XAML elements it has to offer withou worrying about it starting up a million pop-up windows. better yet, you won't need special pop-up blocker software in the first place, you could just set the Sytem.Forms permission to - allow Form eleements from XAML downloads - 1 thread at a time.
anyway - I would really love to see a linux distro called 'The MonoBox' - forget kde and gnome - just throw them out the door. Get an interface started up that is totally dependent on the mono framework, with some sort of super C# compiler and a really open programmong network - one where each personal computer would show off to the world what kind of Framwork components it has to offer (new ones to be downloadable in binary or source code from the users own CVS - better yet make the whole .net framework binary totaly open to the world for downloading from each others computer ie .net framework would be open to p2p modifications - of course totally upto the users discretion depending on his permissions)
anyway - I beleive this is the dream of Microsoft - they are just taking it slowly - maybe the linux community could stop wasting time on drawing penguins and skip all the bull with gnome/kde and just make something that would really bring all programming/programmers ability together in a neat configurable format.
-the .net framework.
-no I'm not a MSOFT fanatic - but I have envisaged this day since the first day I saw Flash - it's taken a while, and I am surprised no-other giants have done it already. it would be an OP that would kick arse to Linux or anything else around.
imagine software consisting of nothing more than XML repositories - and you the programmer being able to mix and match XML declaratives between applications with nothing more than your already mixed and mathced amalgamted custom ide you made just for doing that.
-anyone want to start a PROJECT!
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
Posted by Rik Hemsley on Thursday 25/Mar/2004, @09:23