| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 2 | |
Thiago Macieira wrote: > The only difference between qt-copy and your own arguments (copy the class > into your project and modify it there) is that they're doing it inside Qt. What is an important difference, because when qt-copy becomes the default Qt library on a Linux distribution it affects all other Qt related applications as well. An incompatible fork would be a serious problem for all libraries, that like to support the commercial and the open source world. But isn't the number of bugs in Qt4 and the fact, that Trolltech isn't very good in fixing them in time the source of this problem. KDE seems to be able to maintain and release its own Qt fork, but what about smaller projects or all commercial applications ? I also agree with Arvid, that a dominating project like KDE with the philosophy to create its own biotope has a bad effect on the availability of Qt addons. Speaking for myself as author of the Qwt library, I'm not aware of being ever in contact with someone writing a KDE application. Qwt is a widget library for scientific applications and there are many of them in KDE, so isn't this surprising ? Uwe -- [ signature omitted ]
On Tuesday 11 March 2008 15:55:49 Uwe Rathmann wrote: > Speaking for myself as author of the Qwt library, I'm not > aware of being ever in contact with someone writing a KDE application. > Qwt is a widget library for scientific applications and there are many of > them in KDE, so isn't this surprising ? Fun. i started Qxt. same target group, just different classes. Might explain why you see at least a few things like me. On Tuesday 11 March 2008 15:57:02 Thiago Macieira wrote: > On Tuesday 11 March 2008 15:41:04 Arvid Ephraim Picciani wrote: > > should be patched upstream. if that didn't happen, Trolltech is to blame. > > Hey, that's exactly what KDE developers think. > [...] > Unfortunately, there are only so many hands and eyes in Trolltech. thats why you give up controll over the open source community into kde hands. i know that. and to be honest i would have done the same. But for now i am standing on the side that suffers from that. On Tuesday 11 March 2008 16:02:35 Andreas Pakulat wrote: >... sorry, but you mainly point out that qt-copy isnt broken. You're right, for now. But that wasnt my issue at all. On Tuesday 11 March 2008 15:51:40 Andreas Pakulat wrote: > I don't see how calling the svn folder qt-kde instead of qt-copy would > make any difference. that wasnt the point. it doesnt matter how you call it as long as it isnt mixed up with Qt. > Changes that I'd like to do to any of the classes at the top of the > class hierarchy, thats QMetaObject, QObject, QWidget, QAbstractItemView > and whatnot. You can't change any of those classes without patching Qt > and in particular you can't change any of those classes and inject the > result into the class hierarchy so that other classes in Qt benefit from > them. Which means whenever you take a class from a non-leaf node in the > hierarchy you possibly have to replicate the rest of the class hierarchy > yourself. you can do that. we've done that. its just more work. And again, i dont opose doing that. i just opose calling it "Qt". > I hope you are aware that only stable releases can be considered > official and so far I can't find any qt-copy release tarball here: > ftp://ftp.kde.org/pub/kde/stable/ right. got your point. > Why is any distro forced into using qt-copy tpowa, archlinux qt dev, told me he must patch qt in order for kde to complile. maybe i got wrong information here. At least thiago statet that this is not the case. So if it IS, it is at least not intentionally. Proves my point anyway, that distros start patching Qt, rather then kde. > (besides I doubt they do, > see my other mail)? Except if they want to have a linux distribution out > that supports a certain feature or has a certain bugfix. You have to > admit that its a lot easier to simply pull a patch from somebody else > than develop it yourself. again not the point. if distros decide to patch, thats a problem, but not kdes fault. what IS kde and Trolltechs fault is the grey mix of kde and qt that qt has become. > And thats perfectly fine. The average user should then complain to his > distribution and they can find out which end is the faulty one. > Specifically those people know which exact changes they've done to their everyone who does big open source software will disagree with you here. thats what simply isnt the case in reallife. people blame Trolltech for Kde looking ugly by default, THATS reallity. > Yes and the reason for that opinion is (as far as I can see) not coming > from nowhere. Things are improving wrt. No. But it seems there will never be any statement from any Trolltech developer (who is not in kde) on that. I received various private messages on IRC, but never anything i would dare to quote in reallife (maybe they loose their jobs if they opose kde?) > You should do your homework ;) Thiago is a TT employee and as such I > expect his statements on this list to be that from the TT employee and > not from the KDE developer. Which is exactly my problem. -- [ signature omitted ]
On Tuesday 11 March 2008 16:15:03 Arvid Ephraim Picciani wrote: > > Why is any distro forced into using qt-copy > > tpowa, archlinux qt dev, told me he must patch qt in order for kde to > complile. maybe i got wrong information here. At least thiago statet that > this is not the case. So if it IS, it is at least not intentionally. Proves > my point anyway, that distros start patching Qt, rather then kde. He must be severely mistaken. I build KDE every now and then with a stock Qt, straight out of our Perforce repositories. No patches from KDE applied (in fact, I stopped using qt-copy altogether 2 years ago when I started at Trolltech). -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On 11.03.08 16:15:03, Arvid Ephraim Picciani wrote: > On Tuesday 11 March 2008 15:55:49 Uwe Rathmann wrote: > > And thats perfectly fine. The average user should then complain to his > > distribution and they can find out which end is the faulty one. > > Specifically those people know which exact changes they've done to their > everyone who does big open source software will disagree with you here. thats > what simply isnt the case in reallife. people blame Trolltech for Kde looking > ugly by default, THATS reallity. Sure, but for this kind of people you have mostly two choices: a) ignore them, they won't even try to learn the truth b) try to educate them and at the end of the day feel that you completely wasted your time. But thats the same thing in any project that I've participated so far. There are always those that just want to blame somebody if anything doesn't go as they'd like and almost always they pick the first person they find. Andreas -- [ signature omitted ]
Arvid Ephraim Picciani wrote: > tpowa, archlinux qt dev, told me he must patch qt in order for kde to > complile. maybe i got wrong information here. At least thiago statet that > this is not the case. So if it IS, it is at least not intentionally. Proves > my point anyway, that distros start patching Qt, rather then kde. He was probably talking about KDE from trunk, which sometimes depends on patches in qt-copy that are going into later Qt versions but not any released snapshots yet. In short, this never happens, unless simply to further development faster if an official TT bug release isn't out yet. --Jeff -- [ signature omitted ]
On 11.03.08 15:55:49, Uwe Rathmann wrote: > Thiago Macieira wrote: > > > The only difference between qt-copy and your own arguments (copy the class > > into your project and modify it there) is that they're doing it inside Qt. > > What is an important difference, because when qt-copy becomes the default Qt > library on a Linux distribution it affects all other Qt related > applications as well. It shouldn't. If it does, report to the distribution. qt-copy cannot contain incompatible changes (except if TT added them already to the official sources and the release of that is simply too far away still). > I also agree with Arvid, that a dominating project like KDE with the > philosophy to create its own biotope has a bad effect on the availability > of Qt addons. Speaking for myself as author of the Qwt library, I'm not > aware of being ever in contact with someone writing a KDE application. > Qwt is a widget library for scientific applications and there are many of > them in KDE, so isn't this surprising ? So are these apps using all their own implementation for widgets that Qwt provides? How old are these apps? How old is Qwt? Do these apps share a common library which maybe not only provides the widgets but more stuff? In general application authors try to keep the dependencies small and if an app can depend on foo instead of bar+baz it most probably chooses foo. Andreas -- [ signature omitted ]
Andreas Pakulat wrote: > So are these apps using all their own implementation for widgets that > Qwt provides? AFAIK, yes. ( But looking at the answer of Pau, it seems, that some KDE applications started to use Qwt ). > How old are these apps? How old is Qwt? The first Qwt release is from 1997 for Qt 1.0. > Do these apps > share a common library which maybe not only provides the widgets but > more stuff? In general application authors try to keep the dependencies > small and if an app can depend on foo instead of bar+baz it most > probably chooses foo. Qwt doesn't need any libraries beside Qt, but of course an application doesn't need all classes of Qwt like it doesn't need all classes of the kdelibs. Uwe -- [ signature omitted ]
Quoting Uwe Rathmann <Uwe.Rathmann@xxxxxxxxxxx>: > Thiago Macieira wrote: > >> The only difference between qt-copy and your own arguments (copy the class >> into your project and modify it there) is that they're doing it inside Qt. > > What is an important difference, because when qt-copy becomes the default Qt > library on a Linux distribution it affects all other Qt related > applications as well. An incompatible fork would be a serious problem for > all libraries, that like to support the commercial and the open source > world. > > But isn't the number of bugs in Qt4 and the fact, that Trolltech isn't very > good in fixing them in time the source of this problem. KDE seems to be > able to maintain and release its own Qt fork, but what about smaller > projects or all commercial applications ? > > I also agree with Arvid, that a dominating project like KDE with the > philosophy to create its own biotope has a bad effect on the availability > of Qt addons. Speaking for myself as author of the Qwt library, I'm not > aware of being ever in contact with someone writing a KDE application. > Qwt is a widget library for scientific applications and there are many of > them in KDE, so isn't this surprising ? > > Uwe I believe Arvid and you are quite wrong in most of your complaints and/or observations. Facts: * KDE is the most prominent project using Qt and no other project is anywhere near * KDE maintains qt-copy but no distribution packages it and KDE discourages its use. What most distributions do is to apply some patches, from qt-copy or produced by their own developers, to adapt Qt to their philosophy, feelings, political reasons or just fix some outstanding bugs (mostly, security bugs) * I have not heard any "scream" from any open source or commercial project to GPLv3 Qt. Sorry but the only requests I've known of were from KDE developers. * Qwt IS used in KDE, for example in Akonadi. In fact, the KDE-bindings people also provide Qwt bindings to Ruby, PHP, C# and some other languages. Therefore: * When any project achieves a popularity comparable by, say, two or three orders of magnitude, to KDE, your requests and complaints will be listened to. This is not Trolltech's fault but the way things work in every company. * Use the stock Qt version. My distribution (Kubuntu) ships with stock Qt + some patches but it's certainly not qt-copy. Saying Linux distributors package qt-copy instead of Qt is, at the very least, inaccurate. * Make yourself and your projects more visible. By the way, I'd say leaving qt-interest and Freenode is not going to improve your visibility. -- [ signature omitted ]
Pau Garcia i Quiles wrote: > * KDE is the most prominent project using Qt ... Absolutely and I will be very happy, when KDE4 will be a success. > ... and no other project is anywhere near And this exactly is a problem. There are almost no addons, that are worth to mention. Of course it's not a business of the KDE development, but please note, that we are on a Qt list here and this might be an issue for all others, who are writing Qt applications ( including the commercial world, which in the end pays for the development of Qt ). KDE has by far more money and manpower, than all other Qt projects together, but I'm not aware of many spin offs, that one could expect from such a huge project. I absolutely don't want to offend in any direction, but maybe it is worth to be aware of this. > * When any project achieves a popularity comparable by, say, two or > three orders of magnitude, to KDE, your requests and complaints will > be listened to. This is not Trolltech's fault but the way things work > in every company I don't have any good statistics, but from the traffic on the Qwt support channels I guess 50% of the 5000 downloads of my latest release are commercial users. I don't know its effect on selling commercial Qt licenses, but it should be important enough. Qwt always had a good acceptance in the commercial environment, but most open source applications didn't want to use it, because it was not part of the major distributions. But to become part of a distribution, you need an application, that uses it. Finally for Qwt it was QtiPlot (not KDE), that could break this fatal dependency. Uwe -- [ signature omitted ]
Uwe Rathmann wrote: > And this exactly is a problem. > > There are almost no addons, that are worth to mention. Of course it's not a > business of the KDE development, but please note, that we are on a Qt list > here and this might be an issue for all others, who are writing Qt > applications ( including the commercial world, which in the end pays for > the development of Qt ). > > I don't have any good statistics, but from the traffic on the Qwt support > channels I guess 50% of the 5000 downloads of my latest release are > commercial users. I don't know its effect on selling commercial Qt > licenses, but it should be important enough. > > Qwt always had a good acceptance in the commercial environment, but most > open source applications didn't want to use it, because it was not part of > the major distributions. But to become part of a distribution, you need an > application, that uses it. Finally for Qwt it was QtiPlot (not KDE), that > could break this fatal dependency. > I will also offer this: at least in my experience, a project that is at least LGPL or something else a little less restrictive than straight GPL will get a lot more usage than one which is straight GPL. I am happy - excited - to contribute my changes to an open-source project back... but in my day-to-day usage, I can rarely touch straight GPL code, unless it is something truly standalone (like SYSLINUX and friends). I greatly prefer a license that requires contributions *to the project* to be returned to the project, but still allows the usage of the library in a non-GPL environment. My only issue that I've ever had with the LGPL is that there should be an exception made for static linkage on platforms/situations where dynamic linking is *impossible* - for instance, I did a lot of work under DJGPP/DOS, which simply does not support solibs. My viewpoint of GPL vs. LGPL for libraries is this: if you are trying to push for the "open-source or bust!" agenda, then go for straight GPL... but don't whine if your project has a lower rate of usage than you would like. (Note that I am not saying I disagree with that tactic - merely not to take issue with it if people then won't/can't use it.) If you still want to get contributions to your source code and get fixes from the outside world to your project, consider something at least a little less restrictive. -- [ signature omitted ]
Quoting Uwe Rathmann <Uwe.Rathmann@xxxxxxxxxxx>: > Absolutely and I will be very happy, when KDE4 will be a success. > >> ... and no other project is anywhere near > > And this exactly is a problem. > > There are almost no addons, that are worth to mention. Of course it's not a > business of the KDE development, but please note, that we are on a Qt list > here and this might be an issue for all others, who are writing Qt > applications ( including the commercial world, which in the end pays for > the development of Qt ). > > KDE has by far more money and manpower, than all other Qt projects together, > but I'm not aware of many spin offs, that one could expect from such a huge > project. > > I absolutely don't want to offend in any direction, but maybe it is worth to > be aware of this. The lack of add-ons is certainly a huge gap in Qt. I'd love to see components like DevExpress (http://www.devexpress.com/) for Qt. KDAB's and most of the KDE "components" are laughable compared with them. Jeez, just take a look at their grids! This is, probably, a matter of size again: the market for Qt components is tiny compared to the market for C# or even Delphi. >> * When any project achieves a popularity comparable by, say, two or >> three orders of magnitude, to KDE, your requests and complaints will >> be listened to. This is not Trolltech's fault but the way things work >> in every company > > I don't have any good statistics, but from the traffic on the Qwt support > channels I guess 50% of the 5000 downloads of my latest release are > commercial users. I don't know its effect on selling commercial Qt > licenses, but it should be important enough. We use Qwt for commercial software here. We decided to use Qwt after deciding to go with Qt. > Qwt always had a good acceptance in the commercial environment, but most > open source applications didn't want to use it, because it was not part of > the major distributions. But to become part of a distribution, you need an > application, that uses it. Finally for Qwt it was QtiPlot (not KDE), that > could break this fatal dependency. Chicken-and-egg problem but you cannot avoid that. Once again, popularity is key. If I would have been you, I would have developed some small KDE application which used Qwt and tried to make it part of the official KDE stack (like games in the kdegames module, for instance). Qwt would have been included instantly into all major Linux and *BSD distributions. -- [ signature omitted ]
Pau Garcia i Quiles wrote: > The lack of add-ons is certainly a huge gap in Qt. I'd love to see > components like DevExpress (http://www.devexpress.com/) for Qt. KDAB's > and most of the KDE "components" are laughable compared with them. > Jeez, just take a look at their grids! > > This is, probably, a matter of size again: the market for Qt > components is tiny compared to the market for C# or even Delphi. I'll argue that one: our team is ditching Delphi, mostly over lack of support, for C++/Qt. Delphi might - perhaps - have more support than Qt specifically... but certainly not than C++. And once you're in the same language, the rest is far easier. (I am not ignoring non-C++ Qt programmers here, but then you are again in the round of "what does your language offer in terms of third-party libraries?" -- [ signature omitted ]
On Tuesday 11 March 2008, Uwe Rathmann wrote: > KDE has by far more money and manpower, than all other Qt projects > together, but I'm not aware of many spin offs, that one could expect from > such a huge project. Holy crap, KDE has more money and manpower than Skype and Adobe put together, not to mention the thousands of other commercial entities that license Qt, plus the who knows how many non-commercial entities using Qt for their code? You'd think with this kind of money and manpower all of the KDE hackers could quit their real jobs and focus on KDE all the time. Alas, for some reason they don't. --Jeff -- [ signature omitted ]
On Tuesday 11 March 2008 15:55:49 Uwe Rathmann wrote: > What is an important difference, because when qt-copy becomes the default > Qt library on a Linux distribution it affects all other Qt related > applications as well. An incompatible fork would be a serious problem for > all libraries, that like to support the commercial and the open source > world. We're aware of that. It's a big deal that qt-copy patches can introduce regressions and bugs that aren't in the official Qt releases. The problem is that Linux distributions and other system integrators aren't aware of the issue. One of the reasons for it is that our test suite isn't public. Another is that Trolltech developers are employed to work full-time on Qt, whereas KDE developers (or any other kind of developer for that matter) aren't. So we in Trolltech put a lot of effort into making a kick-ass Qt that KDE developers simply cannot afford in their spare time. This is actually the main reason why people get annoyed at us not including their patches, feature suggestions and bug fixes. There are only so many hours in the day and only so many hands working in Qt. That doesn't stop anyone from having the right of patching Qt as they see fit and publish those patches however they see fit. Heck, you could change QString to use 4-byte QChars and publish that too. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira wrote: > I also know for a fact that many of our paying clients do modify Qt > internally. And they even ship those modified Qt in their applications > (static builds, for instance). > *waves* http://trolltech.com/developer/task-tracker/index_html?method=entry&id=199583 In fact, we're even using DLLs - but of course they live in our local application directory. -- [ signature omitted ]