One of the hallmark problems of design-by-committee is that they extend languages for the sake of doing fun things, not because people need it.

While everyone needs containers (like vector/hashmap), nobody needs a simple graphics library. There is practically no hardware out there that doesn't have some sort of hardware accelerated graphics and simple operations just make no sense there.

So, my question really is why they are doing this? I'm betting the answer is not one where they have actual usecases in mind.

Qt has hundreds of committers from dozens of companies, if he can' t get his patches accepted, did you consider they were of low quality or in violation of the guidelines?

The Qt part left a bit of a bad taste in my mouth, so I did some research of my own.

The first thing to notice is that a normal Qt application has no attack surface, there is no need for any part of the application to use elevated privileges. So what was his point? The presenter went with the assumption that some applications can be started as a normal user but get root rights by being installed as suid-root.

I don't understand why he would attack that idea. Having a GUI app started by any user run as root is not good security policy. Having your app run as root and linking it to multi-megabytes of library that is not hardened for such a case is just plain silly.

The answer of the Qt guys makes a lot of sense, the library is not meant to be run with different privileges as the user that started it. He should have gotten the point when the Qt security experts made the point clear with the plugins. If I can start an app as root from my normal user, and I can specify which styling-plugin to run, I essentially can tell it to run my code. As root.

So, I'm fully satisfied with the answer that Qt is not wrong, it doesn't have an attack surface unless the app using it is doing something stupid.

His security report is akin to blaming the vim authors that it is a security concern if you install it as suid-root. Its blaming the wrong person for introducing the attack surface.

ps. his quoted Qt code never occurs in any of the Qt5 codebase as far as I can find.

This is true, just want to add that OVI opened up just a week or so ago to allow free personal uploads too.

The GP was a bit vague, I understood it differently from how you read it. From my point of view, it makes a lot of sense.

The point that I think makes a lot of sense it that Symbian is not dead because you can run Qt based applications on it. You can develop on your Windows/Linux box and deploy it on your Symbian device. You can also deploy the same app on a Meego device, if you want. Without rewriting it.

Saying an OS is dead in my mind means its not available anymore, or that there are no applications for it. The first is obviously false as there are still 100million devices with it with more coming from various vendors. The applications can be written using Qt (google for "Qt Quick") and as such the applications market is probably just going to get bigger, not smaller.

Symbian is not a goner just yet. But many will agree its going to be replaced eventually with things like Meego. Naturally, this is why developers should choose Qt as they can develop for both the current and the next generation at the same time.

most distributions dropped KDE 3 support.

They did, and they did that because their users screamed at them. Which is entirely silly to listen to, I mean, would your car dealer remove the doors if you really loudly asked for it? Hmm, maybe they would.

I'm just saying that the distros did this *against* the wishes of KDE.

I appreciate your opinion, and I even understand your point of view. Do you understand that releasing software may be something that is not just for your benefit? There are integrators, developers and others that need this release. And you should try it, you might even like it. Depending on how many features you actually use from an office suite.

Its a platform release. For developers and integrators. They want a release too, you know :)

End users are not the only reason to release software.

Thornnburg wrote;It would be nice if the KOffice site mentioned this.

Maybe you missed this in your quick reading of the linked article;
It is possible that the release of binaries for Windows and Macintosh will occur after some time if other packages that KOffice depend on need more time.

Not sure where you got the impression that a .0 version is a final "please use this for your mission critical work". That has never been true and nobody every claimed it to be the case. Remember Windows 3.0 ? I don't. I do remember 3.1

Anyway; this is a *platform* release. Distro's, integrators and developers can now get this and use it. There will be users that like it, but TFA is being brutally honest that its not for end users.
I don't understand why you seem to be upset.

Plugins and extensions as used by openoffice are quite less powerful than what firefox and koffice have. For example this is cool usecase that someone hacked already before we released; http://www.valdyas.org/fading/index.cgi/hacking/musicflake1.html

Its not so much that many must find Oxygen pretty, its much more that people that don't are not whining about it like the original poster did. They just use another style that looks better to them. Frankly; saying that a theming toolkit looks ugly is kind of silly. Especially since there is a native Windows look&feel as well as a native MacOSX l&f which, well, look native.

while you can't bind functors with Qt signals, you can mix boost and Qt signals without problems so there is no limitation.

As posted elsewhere in this story the Qt APIs promote a certain design that make your application and your code easier to maintain and read.

So to answer your point 1;

• || parent-child relationships are not enough in many cases where objects are shared across multiple domains.

The parent-child relationship is there for memory management purposes. Which directly links to having an owner of an object. If your object is owned by someone else, that someone is responsible for deleting it. This is free in Qt when you use QObject. If your object is not owned by one thing but shared between many you use a QSharedData based concept which immediately makes you stop using pointers too.

This makes it absolutely clear what is what in common usage of the code and you'll notice that memory leaks or crashes due to dangling pointers become very easy to avoid.

So, you may be right Qt is not as flexible as STL. But I don't mind a bit of structure. Less rope to hang myself.

Another point that probably needs clarification;

• || Introspection has nothing to do with signals and slots

I think it does, you can't have powerful signals/slots without introspection. The huge advantage of using introspection to do connections is that you don't need a pre-compiled interface to code to. Which then avoids a lot of nastyness in C++ with library loading and linking etc.

Which makes it possible to have a GUI designer as powerful as QtDesigner, among others.