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.
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.
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.
Huh. Sorry, that's complete bullshit. While everyone knows that a.0 version may have bugs, it's also expected that a.0 version *will* be ready for prime time. If it's not, it should have an alpha or beta moniker.
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.
I agree with the GP, labeling a release 2.0.0 (without saying "Beta" or "RC") and then saying it's not ready for daily use by end users is kind of stupid.
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.
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.
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.
The QtUiTools is not meant to be linked against, its a library that is shipped with designer (an development-application) so its kind of odd to judge all of Qt on a bundled application.
Perhaps you should try to move the classes you require from this library into QtGui. You may want to file a feature request or even do the work yourself (this post is about the repos being open!!).
The tools-library you seem to want to use is not for major consumption, doesn't have binary compatibility and all that. So its great that you *can* use it, but maybe you are expecting a bit too much to get it without any investment at all;)
the shared_ptr equivalent in Qt is QSharedPointer (surprise!) not QPointer which is something quite different.
I do suggest not using shared_ptr as the Qt version has better cross-platform support and is easier to use and like most Qt things has better readability.
I'm looking forward to giving it another shot (as I do with nearly every major release)
Great:)
Just make sure you don't base your opinions for the next couple of years on a first (or even second) release. KDE4.0 is a platform, not meant to be the end-all for the user. That will grow better and better of the lifetime of the 4 series.
If the KOffice guys want to not import ooxml then they're making their program less useful to their users.
This, naturally, is a red herring. I could easily turn this around by saying that if the AbiWord guys don't want to support the open and long time ISO standard doing the same thing, but for more people, they are making their program less useful to their users too. But I won't.
Why do I refer to your statement as a red herring? Because you are ignoring the fact that supporting OOXML doesn't just allow users to have some interaction with the propriatairy MS format it also validates it as being relevant. And you are doing not only your users but the rest of the world a disservice with that.
OOXML is only relevant for maintaining the MSOffice lock-in, as I, and many others, have made clear in various other places on the internet. The fact that you and other gnome people apparantly think its going to be the new standard for all office documents no matter how hard people push for a real open standard is what is wrong here.
You assume that since its an MS standard, it will be successful, and by supporting their work you are actually helping to make that a reality.
If, however, you put down the glasses of ms-standard bias you will see that a huge chunk of the world has realized the problems with MS standards and there is a real process going on to move towards ODF. This invalidates your assertion that whatever comes from MS will be successful.
On top of that, the momentum that the hundreds companies and thousands of people put into ODF is only being countered by clear Microsoft backers. Until Gnome and Jeff started doing their thing.
I hope you can see how this looks from the outside and why any points stating Jeff is not actually backing OOXML sound hollow to put it mildly.
If Abiword developers believe in open source and freedom in software they will have to clearly and noisily make clear they distance themselves from OOXML and Microsoft standards in general.
Always doing good, well, it depends on your definition of whats good I guess.
Leading a country to be industrialized and within an overseeable number of years belong to the world economy is surely a definition of good that I'd be able to think Gates has.
I mean; its lead by the wealthiest man in the world, who grew up in America. What do you expect his position to be?
Beside the point; if it came out that Bush indeed invaded Irak under false pretences there would also be zero reason to tell the world of this truth? Lest it devastate his life?
The point is not the hurt that comes from revealing the truth, it comes from the fact that the lies that have been hold back can no longer be told. And if you can be told only certain truths, it follows that you can be told what to think and do. That's why we have freedom of the press.
Slashdot Mirror
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 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.
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.
Huh. Sorry, that's complete bullshit. While everyone knows that a .0 version may have bugs, it's also expected that a .0 version *will* be ready for prime time. If it's not, it should have an alpha or beta moniker.
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.
I agree with the GP, labeling a release 2.0.0 (without saying "Beta" or "RC") and then saying it's not ready for daily use by end users is kind of stupid.
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.
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;
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;
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.
The QtUiTools is not meant to be linked against, its a library that is shipped with designer (an development-application) so its kind of odd to judge all of Qt on a bundled application. Perhaps you should try to move the classes you require from this library into QtGui. You may want to file a feature request or even do the work yourself (this post is about the repos being open!!). The tools-library you seem to want to use is not for major consumption, doesn't have binary compatibility and all that. So its great that you *can* use it, but maybe you are expecting a bit too much to get it without any investment at all ;)
by using native GTK theming that Qt supplies :) http://labs.trolltech.com/blogs/2008/09/05/qgtkstyle-now-part-of-qt/
the shared_ptr equivalent in Qt is QSharedPointer (surprise!) not QPointer which is something quite different. I do suggest not using shared_ptr as the Qt version has better cross-platform support and is easier to use and like most Qt things has better readability.
The screenshots have just been made with a bad theme, in vista it looks native.
Great :)
Just make sure you don't base your opinions for the next couple of years on a first (or even second) release. KDE4.0 is a platform, not meant to be the end-all for the user. That will grow better and better of the lifetime of the 4 series.
This, naturally, is a red herring. I could easily turn this around by saying that if the AbiWord guys don't want to support the open and long time ISO standard doing the same thing, but for more people, they are making their program less useful to their users too. But I won't.
Why do I refer to your statement as a red herring? Because you are ignoring the fact that supporting OOXML doesn't just allow users to have some interaction with the propriatairy MS format it also validates it as being relevant. And you are doing not only your users but the rest of the world a disservice with that.
OOXML is only relevant for maintaining the MSOffice lock-in, as I, and many others, have made clear in various other places on the internet. The fact that you and other gnome people apparantly think its going to be the new standard for all office documents no matter how hard people push for a real open standard is what is wrong here.
You assume that since its an MS standard, it will be successful, and by supporting their work you are actually helping to make that a reality.
If, however, you put down the glasses of ms-standard bias you will see that a huge chunk of the world has realized the problems with MS standards and there is a real process going on to move towards ODF. This invalidates your assertion that whatever comes from MS will be successful. On top of that, the momentum that the hundreds companies and thousands of people put into ODF is only being countered by clear Microsoft backers. Until Gnome and Jeff started doing their thing.
I hope you can see how this looks from the outside and why any points stating Jeff is not actually backing OOXML sound hollow to put it mildly.
If Abiword developers believe in open source and freedom in software they will have to clearly and noisily make clear they distance themselves from OOXML and Microsoft standards in general.
Thomas Zander, core KWord developer
I'd love to hear your opinion about the oxygen style (to be finalized before the kde4.0 release). :)
Obviously not someone with an ID as high as yours, newbie. LOL, yeah, yours naturally is sooo much lower
We used to have a "Postgres rocks" banner at the bottom of each page :)
Always doing good, well, it depends on your definition of whats good I guess. Leading a country to be industrialized and within an overseeable number of years belong to the world economy is surely a definition of good that I'd be able to think Gates has.
I mean; its lead by the wealthiest man in the world, who grew up in America. What do you expect his position to be?
> And for what?
Beside the point; if it came out that Bush indeed invaded Irak under false pretences there would also be zero reason to tell the world of this truth? Lest it devastate his life?
The point is not the hurt that comes from revealing the truth, it comes from the fact that the lies that have been hold back can no longer be told.
And if you can be told only certain truths, it follows that you can be told what to think and do. That's why we have freedom of the press.