Slashdot Mirror

QML has expressive power that makes legacy frameworks look almost silly.

Examples? It really means little to hear people throw out buzzwords and provide no examples of how it is more this or that.

Look at any of the demos that come with it. Say the corkboard. Then implement using "bare" Qt.

I have ported a database-driven application to QML, and I can't feel any speed difference between the declarative UI rendering the views and the QWidget views. There are perhaps problems when too many things are moving about at once, but I'm not trying to do that. The only motion is in following the mouse and doing flicks, and this performs as it should.

This can quite easily be solved by using a macro.

http://doc.trolltech.com/latest/containers.html#the-foreach-keyword

Qt is not fully owned by Nokia right now, and is moving to be a fully openly governed project. And Qt has now Qt Quick, which is a system for developing apps using a declarative language, and can be mixed with C++ very nicely. I've been playing with it lately, and is a great product.

http://doc.trolltech.com/4.7/supported-platforms.html

it's very important to have almost realtime javascript
this is needed so i can play chess 3d

http://html5games.com/2010/08/html5-chess/
or quake 2 in the browser

http://www.osnews.com/story/23097/Quake_II_Ported_to_HTML5

there is only one thing they shuold scrap from the browser to make it speedier svg and all that is xml related, all the interface should be painted in opengl with data residing in json format, something like QML

http://labs.trolltech.com/blogs/2010/08/12/a-guide-to-writing-games-with-qml/

Nokia (yeah, remember Nokia?) is working on QTQuick and QML: a Qt/Javascript/CSS fusion language. (Formerly called Kinetic, now called QtQuick, and QML (the JS/CSS language)

It does everything that Flash does and is completely open source. What's more is it is not byte-code interpreted. The QML file is loaded into the QtDeclarativeEngine and evaluates and runs in native code. (Aside from Javascript, but Apple isn't arguing about JavaScript use)

*FULLY* open source, not interpreted (beyond JS), And damn easy to use... It will be a part of Qt 4.7 (next month?)

...And documentation where trying to figure out the class hierarchy of OO libraries is an exercise in frustration. Compare these two: Typical MSDN page (scroll down to Inheritance) and a typical Qt documentation page.

The Qt page has members, methods, properties and general description on one nicely formatted page, along with derived and parent classes. Also, functions are organized into groups and the entry for each function has "see also" links to other similar functions.

The MSDN page on the other hand, has no ref links for easy navigation or linking, a useless set of declarations for that class in various languages, no explanation of the components of the class being described, and no members list (you have to go to another page for that). The members list in itself is equally bad: it's just a long list of members, with no grouping or indeed, any ordering beyond breaking it up into properties/methods/events.

Honestly, when working on Windows, I wish I had something like man pages!

...And documentation where trying to figure out the class hierarchy of OO libraries is an exercise in frustration. Compare these two: Typical MSDN page (scroll down to Inheritance) and a typical Qt documentation page.

The Qt page has members, methods, properties and general description on one nicely formatted page, along with derived and parent classes. Also, functions are organized into groups and the entry for each function has "see also" links to other similar functions.

The MSDN page on the other hand, has no ref links for easy navigation or linking, a useless set of declarations for that class in various languages, no explanation of the components of the class being described, and no members list (you have to go to another page for that). The members list in itself is equally bad: it's just a long list of members, with no grouping or indeed, any ordering beyond breaking it up into properties/methods/events.

Honestly, when working on Windows, I wish I had something like man pages!

This guy explains it better than I can. I ripped the post from another board, link is at the bottom.

To go directly to the point, I think that the "linux desktop" needs a small, fast, fully-featured graphical backend. This backend should provide basic drawing primitives, input device event handling, network transparency, but should not involve itself with higher-level graphical interface design (like buttons and menus). So far, I suspect that most of the above posters would agree with this notion. Here is where we diverge: I do not think that X11 is small, fast, or fully-featured. And I think that there are fundamental aspects of the X11 protocol which will prevent any implementation from working well.

The first fundamental problem is that X11 is implemented using an asynchronous model. In other words, to raise a window one cannot simply call XMapWindow to map a window. One must call XMapWindow, which will transmit that command to the server, then one waits for the server to respond with a MapNotify event, and then one can proceed. When running over a network this potentially allows the client to send off multiple commands before waiting for the response to a single command, allowing improved performance. But when run on the local machine, this requires a great deal of round-trip communication that produces latency that causes many users to perceive X11 programs as "slow." This problem has been reduced somewhat through the use of shared memory, but still hinders performance. The asynchronous model was an excellent decision for the 1980s when most programs ran over the network. But in the current day, the backend is optimized for a use-case that is rarely used.

Beyond performance issues, the asynchronous model is also the root cause of much of the flickering that occurs on the desktop. As widgets are moved around, the asynchronous model causes repaints to occur while the windows are still in flux resulting in flickering. The developers at QT have effectively already abandoned X11 (or at least a good part of the design) by moving all of the event handling into the QT library to circumvent this flickering (see http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the-end-of-all- flicker).

A second fundamental problem with X11 is the absence of resolution independence. X11 describes all coordinates using integers that represent pixel positions. As screen sizes change and pixels become smaller (or less likely larger), then the display begins to appear pixelated. In a resolution independent scheme, all coordinates are described using floating-point values so that display is rendered correctly regardless of the screen size. Again, going with integers positions was an excellent design decision for the 1980s but is no longer an effective design. In the 1980s many of machines shipped without a math co-processor, so that floating-point operations were much much slower than integer operations and the quality of the graphical output was arguably less important. Today, virtually any modern processor has a math co-processor that can perform multiple floating-point operations per clock cycle. The difference in performance that would result from the use of integers rather than floating-point values is gone, the only thing that remains is the pixelation.

The last main problem with X11 is the profound lack of functionality. Some of the above posters have claimed that now that X11 has compositing it has pretty much everything quartz has. To be blunt, this is very very far from the truth. Competing graphical backends (e.g., Quartz) provide much stronger support for anti-aliased drawing (not just text but lines and polygons), gradients, transforms, shadows, patterns, transparency, font selection, color spaces, and data output (to screen, PDF, or Postscript). Modern linux programs compensate for the inadequacies of the X11 protocol by performing this rendering within the toolkit. GTK use

If Linux's X apps were created with an application's equivalent of HTML's "CSS" then perhaps applications could be tremendously more adaptable to different user environments.

Sounds like the QML (Declarative UI) portion of Qt Kinetic (and Qt Style Sheets have been around for a while).

Safari isn't the only browser to support 3D CSS transforms. QtWebkit also added support for accelerated transforms a little while ago. Yes, that's only two browsers, but it's a rather hard thing to implement considering how complex it makes drawing code (and in its implementation, might use OpenGL). See http://labs.trolltech.com/blogs/2010/05/17/qtwebkit-now-accelerates-css-animations-3d-transforms/

I use Qt, write once (in C++), deploy on Windows, Mac, Linux, Symbian, and any number of embedded systems - with native look and feel, and C++ speed.

I worked for a "visionary" in 2006 who wanted to start an Objective-C shop, he didn't listen to me when I told him that assimilation into Windows was highly probable - it took 6 months before he realized resistance was futile (not to me, but to the industry at large.) Luckily, we stuck with Qt and the port from OS-X to Windows took about one man-week (lots of OpenGL code that wasn't 100% cross-platform).

Over the last 4 years, Qt has been stable enough that things I wrote to version 4.1 are still compiling (properly) with no modifications in 4.6... that's pretty impressive when compared to other development environments I have worked in.

No, I think what he means is just using Phonon from Qt. And it does, indeed, use native frameworks on all platforms that it runs on; to quote the documentation:

"The backends of Qt use the media systems DirectShow (which requires DirectX) on Windows, QuickTime on Mac, and GStreamer on Linux."

So it is a good point. If there already is a single common API that wraps the "big three" and lets one write portable code against them all - and Phonon looks like it's it - then why not use it?

I have set up many systems that dual boot windows and linux, in my experience, the GUI on the linux side is always much slower.

I found this post on the ubuntu forums, it explains some of the fundamental problems with the X11 architecture. It also cites a white paper which provide more detail.

404error wrote on the 13 Feb 09 at 01:52
I think that there has been a knee-jerk reaction to the original suggestion that is not necessarily founded on solid reasoning. Such a reaction is understandable, as a large, reasonably-functional piece of software should not simply be discarded without very strong motivation. And while the original post was well-intentioned, I do believe it could provide stronger arguments. While I have only modest experience programming directly in X11, I will do my best to explain why I also feel X11 should be replaced. If anyone has evidence that contradicts the following opinions, I would be most interested.

To go directly to the point, I think that the "linux desktop" needs a small, fast, fully-featured graphical backend. This backend should provide basic drawing primitives, input device event handling, network transparency, but should not involve itself with higher-level graphical interface design (like buttons and menus). So far, I suspect that most of the above posters would agree with this notion. Here is where we diverge: I do not think that X11 is small, fast, or fully-featured. And I think that there are fundamental aspects of the X11 protocol which will prevent any implementation from working well.

The first fundamental problem is that X11 is implemented using an asynchronous model. In other words, to raise a window one cannot simply call XMapWindow to map a window. One must call XMapWindow, which will transmit that command to the server, then one waits for the server to respond with a MapNotify event, and then one can proceed. When running over a network this potentially allows the client to send off multiple commands before waiting for the response to a single command, allowing improved performance. But when run on the local machine, this requires a great deal of round-trip communication that produces latency that causes many users to perceive X11 programs as "slow." This problem has been reduced somewhat through the use of shared memory, but still hinders performance. The asynchronous model was an excellent decision for the 1980s when most programs ran over the network. But in the current day, the backend is optimized for a use-case that is rarely used.

Beyond performance issues, the asynchronous model is also the root cause of much of the flickering that occurs on the desktop. As widgets are moved around, the asynchronous model causes repaints to occur while the windows are still in flux resulting in flickering. The developers at QT have effectively already abandoned X11 (or at least a good part of the design) by moving all of the event handling into the QT library to circumvent this flickering (see http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the-end-of-all- flicker).

A second fundamental problem with X11 is the absence of resolution independence. X11 describes all coordinates using integers that represent pixel positions. As screen sizes change and pixels become smaller (or less likely larger), then the display begins to appear pixelated. In a resolution independent scheme, all coordinates are described using floating-point values so that display is rendered correctly regardless of the screen size. Again, going with integers positions was an excellent design decision for the 1980s but is no longer an effective design. In the 1980s many of machines shipped without a math co-processor, so that floating-point operations were much much slower than integer operations and the quality of the graphical output was arguably less important. Today, virtually any modern processor has a math co-processor that can perform multipl

How exactly do you control spam posting more easily by abandoning usenet and stick to a web forum? After all, usenet is nothing but an interface to the data. There are plenty of cases where organizations, including private companies, manage fending off spam just fine although they offer support through not only newsgroups but also mailing lists and web forums. For example, Trolltech offers usenet and mailing list access to it's discussion forum and you don't get a drop of spam on it. So why does Microsoft declares itself incompetent and ignorant by claiming that spam is forcing the company to drop support for usenet access?

An overview of the native OS X ability of QT 4.5. Specific issues and differences.

An overview of the native OS X ability of QT 4.5. Specific issues and differences.

The upcoming release will be Qt 4.7 + QtMobility 1.0.0 + QtCreator 2.0

QtMobility is the API for accessing all the bits found on phones but sometimes on desktops. QtMobility has been released, just the other day. You can get it and run it against Qt 4.6
-Messaging (mail/SMS)
-Sensors
-Multimedia
-Services
-Bearer Management (Network management when connected via Cell & WIFI)

Qt 4.7 just went Beta status and should be expected soon.
This release bring in QML, which has been called "Declarative UI". This is the sexy Flash competitor with CSS-style interfaces, animations, and JavaScripting. That's all it adds.

Qt Creator 2.0 I believe is in Beta and will be released with Qt 4.7 as well.
This is the (optional) IDE. But its really good in its own right for Qt development. It features ability to cross-compile and remote debug. You can compile and have it load the app onto your phone and debug that way. It also has QML viewer and WYSIWYG GUI development (Integrated QtDesigner)

As a Qt developer and an n900 owner, Nokia's efforts to extend the Qt platform to portable devices is extremely exciting.

Don't forget that Qt has been an inspiring cross-platform toolkit for years and is the framework behind KDE.

Along with some great improvements to publish to phone support in Qt-Creator (Qt's LGPL IDE), we are getting expansions to the api which include: bearer management, contacts, location, messaging, multimedia, and sensors, among others.

For more info:
http://labs.trolltech.com/blogs/2010/04/27/nokia-qt-sdk-what-is-in-and-what-is-not-and%E2%80%A6-what-is-it/
http://qt.nokia.com/products/appdev/add-on-products/catalog/4/new-qt-apis/mobility

Honest question here. I understand why people would prefer to use a real news reader as opposed to mailing lists or web forums, as they are much better tools for the job.

Who says usenet and other media such as mailing lists and web forums are mutually exclusive? They aren't. They are nothing more than interfaces to access data. After all, there are services which offer access to the same content wether through mailing lists, web forums and also usenet server. For example, take a look at Trolltech's Qt lists. Every web forum and mailing list could as easily be accessible through a usenet interface. After all, in the end it's just that: an interface.

If C++ is really too fucking hard for you, you could always use the PyQt Python bindings, or the Ruby bindings.

If you really feel it's necessary to use XML to lay out your UIs, you can always create XML files using the same format as Qt Designer.

And you don't need to use HTTP for every possible network communication. Jesus, is that the only protocol that you idiots know?

Err, scoped locks that is (something like Qt's QMutexLocker: http://doc.trolltech.com/4.6/qmutexlocker.html).

IMHO A framework can help out a lot, especially when your just getting started. A framework can help get you up and going rather quickly without having to worry about configuring everything. I'd recommend Qt. Here are some great examples: http://doc.trolltech.com/4.6/examples-opengl.html

Even Qt has a MapReduce implementation...
http://doc.trolltech.com/4.6/qtconcurrentmap.html

Interestingly the Qt developers recently had a really good post on why they use OpenGL, its performance, the OpenGL core, etc. They also briefly mentioned OpenCL and DirectX in passing - to note why they didn't use it.

OpenGL is a lot more advanced than you realize, and far more extensible too. So while they may not update the core very often, the core does contain some really nifty stuff and the extensions can easily make up the differences. Comparatively, as others have been saying, DirectX only gets updated at Microsoft's discretion, with little ability of 3rd parties to extend it.

So, Trolltech was acquired by Nokia, but, IIRC, Trolltech has a kind of licence for QT that contains something dramatically labelled a "poison clause", or something like that. It's designed to prevent ever changing the license to a proprietary one, thereby closing the code. I'm not sure how it's done, but this blog post may be related.

Actually, I'd argue Java is also only in theory.

Insert Qt plug here.

I miss typesd what I meant to write was. The video playback could is probably more difficult to deal with but I have not looked at that code.
QT does help with that abstraction
http://doc.trolltech.com/4.4/phonon-videowidget.html
On Linux it uses Gstreamer on Windows DirectShow and on the Mac QuickTime so I doubt that it supports everything that VLC does but it is there.

No it would not. You are looking for ABI compatible, not source-level compatible (or even API compatible). And who the hell would want to duplicate the nightmare in OS X programming where Apple couldn't even decide if they were going to go with Carbon or Cacoa for 6t4-bit? Then of course, they axed one in-spite of what they were saying previously.

        http://labs.trolltech.com/blogs/2008/03/03/qtmac-cocoa-port-alpha-released/

It was not a this or that decision, Carbon is a legacy API that got left at 32-bit, and Cocoa was always the one to use going forward. In the end it forced developers like Trolltech to port to Cocoa which is A Good Thing TM.

Hi, I have tried different socket libraries for Windows and Linux applications. SharkEngine is a free C++ library for network, file and multi threading support. There are also higher level protocol classes so you don't need to reinvent HTTP and SMTP for example. Otherwise QT and Boost are obviously good choices, then there is "Alhem's C++ Sockets Library". I never used ACE, the documentation is confusing and I think John Snader warns in his TCP/IP Programming book about it. Here is a list with contenders:

* SharkEngine http://www.pichat.net/documentation/pichat_sdk_sharkengine
* QT http://doc.trolltech.com/2.3/network.html
* Boost http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio.html
* Alhem http://www.alhem.net/Sockets/

When it comes to small databases I know only SQLite, which is programmed in C and more powerfull than Berkeley-DB. See http://www.sqlite.org./

It works fine these days. Plus, composite helps a lot.

Do GTK and QT provide APIs for database access, network connectivity, HTML rendering, etc? No... you need Gnome or KDE for that, and they're still in flux.

I'm not sure about GTK, but Qt provides modules for network connectivity, HTML rendering, XML parsing, and database integration.

Do GTK and QT provide APIs for database access, network connectivity, HTML rendering, etc? No... you need Gnome or KDE for that, and they're still in flux.

I'm not sure about GTK, but Qt provides modules for network connectivity, HTML rendering, XML parsing, and database integration.

Do GTK and QT provide APIs for database access, network connectivity, HTML rendering, etc? No... you need Gnome or KDE for that, and they're still in flux.

I'm not sure about GTK, but Qt provides modules for network connectivity, HTML rendering, XML parsing, and database integration.

Do GTK and QT provide APIs for database access, network connectivity, HTML rendering, etc? No... you need Gnome or KDE for that, and they're still in flux.

I'm not sure about GTK, but Qt provides modules for network connectivity, HTML rendering, XML parsing, and database integration.

Where? I can't find that phrase either on this page or this page.

You should soon be able to use Qt for Symbian development.

Nokia own both Symbian and Qt, and the Qt labs blog is reporting Qt being ported to S60.

http://labs.trolltech.com/blogs/2009/06/29/port-of-qtwebkit-to-s60/

Note that Qt is an entire cross-platform library, not just for GUI - it includes stuff like threads, network comms, XML even WebKit!

Qt is written in C++ with non-standard add-ons to the core of the language which is passed through moc, a pre-processor, that converts those non-standard elements into compliant C++ code that gcc can process.

I fail to see how this is any different from macro expansion. Other than the simple fact that macro expansion is defined in the C++ standard and moc is not.

The "special-purpose nonsense pre-compiling tools" are there to make building your program easier. Besides, GTK+ not only came up with "special-purpose nonsense pre-compiling tools," they came up with a whole language to ease the development with their toolkit.

I'm not going to bash GNOME people for doing what they feel is needed to increase the productivity of their programmers, I'd hope you'd be kind enough to do the same for the Qt people. ;-)

Finally, you're not required to use the Qt signal-slot system. You can use any callback system you like sigc++, boost, etc... Same case with GTK+.

Qt is written in C++ with non-standard add-ons to the core of the language which is passed through moc, a pre-processor, that converts those non-standard elements into compliant C++ code that gcc can process.

I fail to see how this is any different from macro expansion. Other than the simple fact that macro expansion is defined in the C++ standard and moc is not.

The "special-purpose nonsense pre-compiling tools" are there to make building your program easier. Besides, GTK+ not only came up with "special-purpose nonsense pre-compiling tools," they came up with a whole language to ease the development with their toolkit.

I'm not going to bash GNOME people for doing what they feel is needed to increase the productivity of their programmers, I'd hope you'd be kind enough to do the same for the Qt people. ;-)

Finally, you're not required to use the Qt signal-slot system. You can use any callback system you like sigc++, boost, etc... Same case with GTK+.

Sounds like KDE modified Qt.

No. Qt has several event loops - it will default to the glib-based one if glib is available at compile time. It will fall back to the generic Unix event loop if glib is not found. You can also disable the glib event loop by setting the environment variable QT_NO_GLIB if you need to - for example debugging is simpler with the generic Unix main loop.

This was developed by Trolltech back in 2006, see here. Interesting quote: the ideal would be for all applications on the X11 desktop to use the same event dispatching mechanism. Here are Trolltech, we think the Glib main loop should be that mechanism...

This has the nice side-effect of being able to use gtk and Qt in the same process. This can be convenient at times, for example I have been developing a Qt-based user interface for the mupen64plus emulator. The glib event loop makes it possible to use plugins with gtk interfaces where no Qt interface exists yet. It also makes integrating glib-based things in general pretty much completely painless.

I know that RedHat is putting a lot of weight behind Java technology as one of the first and foremost distros for the OpenJDK. I can attest that the QT Java bindings are way better than the GNOME bindings. It would make sense for RedHat to toss weight behind QT. Google already uses QT for Google Earth. And KHTML is, sorta, WebKit which is Chrome. It all makes more sense to put our weight in QT.

Qt now includes a Webkit-based HTML renderer directly.

QtWebKit

Also, yes, WebKit grew out of the KHTML sourcecode, and Chrome is based on WebKit. Isn't Free software great?

I have no idea why GTK+ is still around since Qt went LGPL.

Qt has better documentation than GTK+.

As an example, you'd be hard pressed to find a widget in the QT documentation that is not documented. GTK+ has rough around the edges documentation for it's Canvas.

I know that RedHat is putting a lot of weight behind Java technology as one of the first and foremost distros for the OpenJDK. I can attest that the QT Java bindings are way better than the GNOME bindings. It would make sense for RedHat to toss weight behind QT. Google already uses QT for Google Earth. And KHTML is, sorta, WebKit which is Chrome. It all makes more sense to put our weight in QT.

I've got nothing but love for the GTK+ people. Also, don't kill QT just because of the KDE 4.0 issue. They've made good on their latest desktop, but don't knock a good Toolkit because of the DE.

My two cents.

by using native GTK theming that Qt supplies :) http://labs.trolltech.com/blogs/2008/09/05/qgtkstyle-now-part-of-qt/

Google is providing a standardized UI on top of Linux

Then let the better UI win. Will it be one that's Java-only, or one that can be used in its native C++ environment or with Python, Ruby, or even Java?

Symbian is dead.

Even if it were true, and with about half of the smartphones in the world running Symbian I don't think it is, what has that to do with Qt?

there is very little need for a specialized UI toolkit like Qt now that there are both fewer platforms for it to run

Huh? There are more platforms than ever for Qt to run. Do you mean Microsoft isn't delivering operating systems anymore?

For C++, I like Qt - with it, you can have your Linux server do "distributed builds" for your netbook. You can also host your code in git or svn and manage your project in trac - all very easily installable and maintainable on your Linux box - I have a setup running at home for my hobby stuff just because it was so easy to do again after setting up at work. The QtCreator IDE is showing promise, but not 100% released yet.

As for hardware, I bought an eeeBox (Atom desktop) to replace my wife's 8 year old e-mail and browser machine - it's awesome, quiet, tiny, cheap, and 2x more powerful than the already adequate machine it replaced. Since that machine is left on 24-7, the reduced 20W power draw (down from 65W in the old machine) will pay for the purchase price in a couple of years. I'm trying to resist further temptation at least until the Freescale netbooks drop - I might still buy an Atom N280, but I'd like to see some competitive offerings first.

The 4.4 moc documentation grudgingly admits these are totally broken, then tries to claim losing half of the language isn't a disaster.

QObjects cannot be template instantiations, so Alexandrescu's policy-based design is out. Actually I think almost all of his brilliant contributions to C/C++ Users Journal are out, which presumably nobody at Trolltech ever read.

A QObject cannot inherit from any other QObject, so mixins are out. If I recall correctly, this is because they make unportable assumptions about how your compiler might choose to lay out a subclass of QObject in memory. Vtables are an easy but generally not the best way to implement virtual methods, but now we're stuck with them because of stupid crap like this and COM.

There are various other omissions (moc can't figure out the qualified name of a type? what kind of excuse for a C++ parser are they using?) that have ugly workarounds but just generally indicate a nearly MySQL grade of sloppiness and apathy.

Do you have even the slightest clue about how "the themed stuff in Qt even works?

Qt doesn't have themes, Qt has widget styles, which are used in Plasma just like they're used everywhere else in KDE. Where that support ended we got to innovate, so Plasma provides a common appearance API so that widgets will look and feel the same across the whole desktop.

You mean something like this? It's already in HEAD and will ship with Qt 4.5.

Of course it was, it's the GPL, nothing more, nothing less.

No, the Gnu compiler collection does not require that every application compiled with it be licensed under the GPL, that would be absurd.

What you are referring to is a condition of the commercial license, (to prevent you from finally buying 1 single license to release your 20-man-years-application commercially). You are free to accept, reject, or try and renegotiate the conditions of this commercial license. If you don't like them, stick with the GPL, it's your choice.

No, as I mentioned before, I am referring to the restrictions on the Free edition.

The Qt API has QtScript, an ECMA scripting engine. While by default Qt isn't fully scriptable, there is a "bindings generator" that makes the whole Qt API available to the scripting engine.