| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 2 | |
Fellow hackers, i will be no more available on IRC. This is not a technical issue, rather then a matter of life energy. The freenode has unfortunately become a threat to my health, as i burn myself out with useless fights with people, who, like me, usually see the sunlight from home to work and back. My role within my company is changing too, as i am no longer writing code myself, other then libqxt, and will be put into more business related tasks. This doesn't mean Qxt is dead. In fact i might have more time to spend on it. As for our communication, i please you to use the mailing list more often, and i will see into a video chat solution for meetings. I am also sending this to the brave Trolltech warriors out there who face the IRC daily too. Please don't give up the fight for Qt and continue to spread your wisdom. Hopefully one day, freenode will be a place where Qt programmers aren't set equal to KDE programmers, and aren't ranted at everywhere as soon as they do their come out. I am bold enought to send this to some kde developers too. I know you hate me anyway, so what do i have too loose? I'm not blaiming you for all the hatred i received on IRC, devdays, linuxtag, etc. Maybe one day you will wake up, figuring you are stuck in a big bubble of grey paste. Maybe you already noticed, but don't know where else to dedicate your Qt skills to. Write me a mail. The Qt Desktop solution has found a lot of supporters and i would like to continue it. i hope that my absence from irc doesnt hinder spreading the word that there is more then KDE in the Qt open source scene. I know that you Trolls are as pissed and burnt out as i am, figthing for high code quality in a scene where most people have low or no social skills. I'm sorry to be a coward but i have to bail out before i damage myself. This is also a call for action. While i give up the fight on IRC, i won't give up fighting for Qt, for linux, and for open source. There are several projects i would like to make you aware of, and for the first time i will make my real attentions behind them public. Libqxt, the Qt extension library is built up on Qt. the website says "Qxt, the Qt eXTension library, provides a suite of cross-platform utility classes to add functionality not readily available in the Qt" In fact i built this project centered around the idea to make Trolltech aware that there are young people out there who are eager to work on extending Qt for no charge, as well as there are companies who would like to contribute back to Qt. I think we quiet suceeded building a big codeset with high class coders, companies, and a lots of users, and i hope that a few of your might find jobs at Trolltech, or jobs somewhere else while using Qxt as a reference. Hopefully we will be able to push some Qxt stuff into the mainstream some day. (we definately have some fine classes that are worth it) I'd love to talk about the new amazing technologies i am pushing like nodetalk and carrier, but i guess thats an extra mail some day. The Qt Desktop Solution (no name yet) as my fight with KDE began to be more and more pointless, i decided to found my own Desktop environment. The responses from the community where amazing. I didn't know there are _SO MANY_ people who opose the kde organisation, its code structure, or simply the way they threat high class Trolltech developers. I actually want a working desktop, but of course my intentions are never pure: I see this as the future of Qt in the open source world. Today i had a fight with the archlinux Qt maintainer. Archlinux was the last bastion of an unpatched Qt, becouse of its policy to not downstream patch. But as the founder retired, archlinux lost its way. The Qt maintainer has switched from Qt to Qt-copy without notice. My call for action is: we MUST gather non-kde developers and push non-kde applications hard, to regain attention for a clean unpatched Qt, as Trolltech made it, in the main distributions There are several projects and people that might form this alliance, and eventually form a desktop environment: cutebox, qdevelop, psi, communi, the qt demo browser, much of the Qt demos and examples. There is lot of work to do. For once code must be written. But also, the word has to be spread further. especially within Trolltech. the Qt examples are not fully developed. i would assume mostly becouse most Trolltech developers dont even know there are people on the linux platform who are sick and tired of KDE, and would apreachiate those applications. Please, wake up, start fighting, you are not alone. sincerely yours, Arvid
There's always gnome... Arvid Ephraim Picciani wrote: > Fellow hackers, > i will be no more available on IRC. > This is not a technical issue, rather then a matter of life energy. > The freenode has unfortunately become a threat to my health, as i burn > myself out with useless fights with people, who, like me, usually see the > sunlight from home to work and back. My role within my company is changing > too, as i am no longer writing code myself, other then libqxt, and will be > put into more business related tasks. This doesn't mean Qxt is dead. In > fact i might have more time to spend on it. As for our communication, i > please you to use the mailing list more often, and i will see into a video > chat solution for meetings. I am also sending this to the brave Trolltech > warriors out there who face the IRC daily too. Please don't give up the > fight for Qt and continue to spread your wisdom. Hopefully one day, > freenode will be a place where Qt programmers aren't set equal to KDE > programmers, and aren't ranted at everywhere as soon as they do their come > out. > I am bold enought to send this to some kde developers too. I know you hate > me anyway, so what do i have too loose? I'm not blaiming you for all the > hatred i received on IRC, devdays, linuxtag, etc. Maybe one day you will > wake up, figuring you are stuck in a big bubble of grey paste. Maybe you > already noticed, but don't know where else to dedicate your Qt skills to. > Write me a mail. > > The Qt Desktop solution has found a lot of supporters and i would like to > continue it. i hope that my absence from irc doesnt hinder spreading the > word that there is more then KDE in the Qt open source scene. I know that > you Trolls are as pissed and burnt out as i am, figthing for high code > quality in a scene where most people have low or no social skills. I'm > sorry to be a coward but i have to bail out before i damage myself. > > This is also a call for action. While i give up the fight on IRC, i won't > give up fighting for Qt, for linux, and for open source. There are several > projects i would like to make you aware of, and for the first time i will > make my real attentions behind them public. > > Libqxt, the Qt extension library is built up on Qt. the website says "Qxt, > the Qt eXTension library, provides a suite of cross-platform utility > classes to add functionality not readily available in the Qt" > In fact i built this project centered around the idea to make Trolltech > aware that there are young people out there who are eager to work on > extending Qt for no charge, as well as there are companies who would like > to contribute back to Qt. I think we quiet suceeded building a big codeset > with high class coders, companies, and a lots of users, and i hope that a > few of your might find jobs at Trolltech, or jobs somewhere else while > using Qxt as a reference. Hopefully we will be able to push some > Qxt stuff into the mainstream some day. (we definately have some fine > classes that are worth it) > I'd love to talk about the new amazing technologies i am pushing like > nodetalk and carrier, but i guess thats an extra mail some day. > > The Qt Desktop Solution (no name yet) > as my fight with KDE began to be more and more pointless, i decided to > found my own Desktop environment. The responses from the community where > amazing. I didn't know there are _SO MANY_ people who opose the kde > organisation, its code structure, or simply the way they threat high class > Trolltech developers. I actually want a working desktop, but of course my > intentions are never pure: I see this as the future of Qt in the open > source world. Today i had a fight with the archlinux Qt maintainer. > Archlinux was the last bastion of an unpatched Qt, becouse of its policy > to not downstream patch. But as the founder retired, archlinux lost its > way. The Qt maintainer has switched from Qt to Qt-copy without notice. > > My call for action is: we MUST gather non-kde developers and push non-kde > applications hard, to regain attention for a clean unpatched Qt, as > Trolltech made it, in the main distributions There are several projects > and people that might form this alliance, and eventually form a desktop > environment: > cutebox, qdevelop, psi, communi, the qt demo browser, much of the Qt > demos and examples. There is lot of work to do. For once code must be > written. But also, the word has to be spread further. especially within > Trolltech. the Qt examples are not fully developed. i would assume mostly > becouse most Trolltech developers dont even know there are people on the > linux platform who are sick and tired of KDE, and would apreachiate those > applications. > > Please, wake up, start fighting, you are not alone. > > sincerely yours, > Arvid -- [ signature omitted ]
On Monday 10 March 2008 12:02:00 Ryan Winter wrote: > There's always gnome... gnome is GTK. and i doubt _they_ would respect the ideas of Qt. -- [ signature omitted ]
Arvid Ephraim Picciani wrote: > > This doesn't mean Qxt is dead. In fact i might have more time to spend > on it. > This project had been under my radar before - it looks like there's some good stuff here! > > In fact i built this project centered around the idea to make > Trolltech aware that there are young people out there who are eager to > work on extending Qt for no charge, as well as there are companies who > would like to contribute back to Qt. I think we quiet suceeded > building a big codeset with high class coders, companies, and a lots > of users, and i hope that a few of your might find jobs at Trolltech, > or jobs somewhere else while using Qxt as a reference. Hopefully we > will be able to push some Qxt stuff into the mainstream some day. (we > definately have some fine classes that are worth it) > *sigh* This has been one of my biggest issues with Qt itself in the past. It appears to be extremely difficult in my experience to get code/fixes recontributed to Qt. This is something that seems to be changing, however; in the past several months this has been less of an issue. In the past, most of my work was regarding qmake itself, as I was the "build system guy", so I was trying to shore up what I saw as missing/incomplete functionality there - and none of my fixes ever made it back into Qt. > > Today i had a fight with the archlinux Qt maintainer. Archlinux was > the last bastion of an unpatched Qt, becouse of its policy to not > downstream patch. > > But as the founder retired, archlinux lost its way. The Qt maintainer > has switched from Qt to Qt-copy without notice. > > My call for action is: we MUST gather non-kde developers and push > non-kde applications hard, to regain attention for a clean unpatched > Qt, as Trolltech made it, in the main distributions > Well... so on that front, there is a decent chance that within my company, we will end up needing to use a "patched Qt" for our product, for the same reasons that I mentioned above. If you have found a limitation in Qt that Trolltech will not fix, you have two choices: maintain your own private branch of Qt with the fixes you need, or reimplement an entire class (and potentially a tree of classes, as we would have been facing - having found an issue with the Windows version of QFSFileEngine!) > > There are several projects and people that might form this alliance, > and eventually form a desktop environment: > *sigh* Don't misunderstand my issue here; I have some significant issues with KDE myself. But... I have two problems here. First, it is my experience that any project that gets big enough ends up having political problems, both internally and interacting with other groups. You might end up with a different set than someone else, but they'll be there nonetheless. And second... well, unless you're aiming for a different goal, I don't see the still-small Linux desktop arena being able to support three major environments, nor do I see a new entrant displacing either KDE or Gnome. I'm not trying to sound discouraging here, I'm trying to point out things to watch out for - if either of the above is your driving goal, then I'd urge you to think about how you can make that work out. -- [ signature omitted ]
On Monday 10 March 2008 15:23:51 Gordon Schumacher wrote: > *sigh* This has been one of my biggest issues with Qt itself in the > past. It appears to be extremely difficult in my experience to get > code/fixes recontributed to Qt. This is something that seems to be > changing, however; in the past several months this has been less of an > issue. In the past, most of my work was regarding qmake itself, as I > was the "build system guy", so I was trying to shore up what I saw as > missing/incomplete functionality there - and none of my fixes ever made > it back into Qt. > Well... so on that front, there is a decent chance that within my > company, we will end up needing to use a "patched Qt" for our product, > for the same reasons that I mentioned above. If you have found a > limitation in Qt that Trolltech will not fix, you have two choices: > maintain your own private branch of Qt with the fixes you need, or > reimplement an entire class (and potentially a tree of classes, as we > would have been facing - having found an issue with the Windows version > of QFSFileEngine!) qmake is a problem indeed, since it is fairly bad managed. But for the rest of Qt, a fork is absolutly not the way. If you require modifications to Qt classes, fork that specIfic class. ie copy it to your project and modify it there. And for more generic stuff there is Qxt. Forking and then calling it "Qt" again is NOT the way. > Don't misunderstand my issue here; I have some significant issues with > KDE myself. But... I have two problems here. First, it is my > experience that any project that gets big enough ends up having > political problems, both internally and interacting with other groups. > You might end up with a different set than someone else, but they'll be > there nonetheless. Thats my point. we dont need a big project. neither a central repository, central dependency. etc. > And second... well, unless you're aiming for a > different goal, I don't see the still-small Linux desktop arena being > able to support three major environments, nor do I see a new entrant > displacing either KDE or Gnome. you forgot xfce ;) > I'm not trying to sound discouraging here, I'm trying to point out > things to watch out for - if either of the above is your driving goal, > then I'd urge you to think about how you can make that work out. thanks for that. i can ensure you that this is not the case. -- [ signature omitted ]
Arvid Ephraim Picciani wrote: > qmake is a problem indeed, since it is fairly bad managed. But for the rest of > Qt, a fork is absolutly not the way. If you require modifications to Qt > classes, fork that specIfic class. ie copy it to your project and modify it > there. And for more generic stuff there is Qxt. Forking and then calling > it "Qt" again is NOT the way. > What if the class in question that needs to be modified is something like QFSFileEngine - how do you "teach" all the dependent classes (QFile, QFileInfo, and QDir, off the top of my head...) to use the changed class? That's why we took the route we did. > you forgot xfce ;) > I didn't forget - but when you are talking about the "big full-featured" WMs, you're really talking about Gnome and KDE. (For my Slax-based appliance system, I'm running blackbox, after all...) -- [ signature omitted ]
Arvid Ephraim Picciani wrote: > My call for action is: we MUST gather non-kde developers and push non-kde > applications hard, to regain attention for a clean unpatched Qt, as > Trolltech made it, in the main distributions I don't know the reason behind the qt-copy fork ( I didn't even know, that it exists ). But as we have this discussion here, could someone explain what it is about and why it is a problem for other Qt related projects ? Uwe -- [ signature omitted ]
On Tuesday 11 March 2008 11:20:29 Uwe Rathmann wrote: > I don't know the reason behind the qt-copy fork ( I didn't even know, that > it exists ). But as we have this discussion here, could someone explain > what it is about and why it is a problem for other Qt related projects ? qt-copy was originally created so that KDE developers could get the necessary Qt versions along with the rest of KDE: via the CVS or Subversion servers. It's also got a "patches" subdirectory, which are standalone patches created by the KDE community changing functionality or fixing bugs in Qt. Those patches are there mostly because they are not in the official Qt. (In a few cases, they are fixes created by us in Trolltech for the next version, but have been backported into the previous release) In general, the rule for qt-copy patches is that they must introduce no new API, must be behaviour compatible and must never break binary compatibility to the stock, released Qt. (The latter rule has been broken twice, but both cases were entirely by accident) There are many reasons why some of the patches exist in qt-copy but not in the latest Qt snapshots: - they have not been submitted to Trolltech, so we don't even know they exist - they have been submitted, but not yet processed [*] - they have been submitted and processed, but were rejected - they have been submitted and committed, but in a different form [*] pressing issues usually include the KDE Liaison contact to make sure issues are prioritised soon. Current patches are: http://websvn.kde.org/trunk/qt-copy/patches/ For example: 0184-dlopen-defaults-to-local.diff has: qt-bugs@ issue : N169965 Trolltech task ID : 170013 (status: fixed for Qt 4.4.0) whereas 0218-qassert-macro-fix.diff was lifted from snapshots because it was fixed after the 4.4.0 beta 1 was released. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Tuesday 11 March 2008 11:20:29 Uwe Rathmann wrote: > I don't know the reason behind the qt-copy fork ( I didn't even know, that > it exists ). But as we have this discussion here, could someone explain > what it is about and why it is a problem for other Qt related projects ? Thiago already answered the technical side of it, better then i could do. My issue with it, is that most "qt" binary packages in the main distros are now taken from the kde sources and not from trolltech any longer. This technicaly means it is a fork, but it is not flagged as such. The issue for Qt related projects is simply that we will further be pushed into the kde direction, although some projects want to clearly seperate themself from kde and build on Trolltech-qt. Actually i would expect Trolltech to be more concerned about their reputation in the Open Source community, but it seems they see KDE as the only people using qt anyway. This wrong assumption is what i try to change. -- [ signature omitted ]
On Tuesday 11 March 2008 13:14:54 Arvid Ephraim Picciani wrote: > Thiago already answered the technical side of it, better then i could do. > My issue with it, is that most "qt" binary packages in the main distros > are now taken from the kde sources and not from trolltech any longer. This > technicaly means it is a fork, but it is not flagged as such. The issue for > Qt related projects is simply that we will further be pushed into the kde > direction, although some projects want to clearly seperate themself from > kde and build on Trolltech-qt. That's the nature of Free Software. Anyone can make modifications and re-release. Being concerned about the effects of the model we chose would be kind of hypocritical. 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. For some of the classes, that's the only way, because they are interdependent with other Qt classes. Besides, one of the few requirements that the GPL imposes is that you clearly label your fork as such. And qt-copy does that. Never was it said that it is Qt. What's more: 1) KDE has *never* released a package called qt-copy with the patches applied 2) patches are not applied unless you *specifically* choose to 3) KDE applications *must* work with a stock Qt and not depend on any behaviour of the patches. 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). So, in summary, I don't find anything wrong with qt-copy. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Tuesday 11 March 2008 13:50:45 Thiago Macieira wrote: > That's the nature of Free Software. Anyone can make modifications and > re-release. Being concerned about the effects of the model we chose would > be kind of hypocritical. It's not the result of free software. Just name me one project that has done the same thing. oh yeah linux, but i opose novell too for calling their heavily patched linux, linux at all. becouse it isnt. other projects like xen do it the right way and just call their linux linux-xen. As kde should call their qt qt-kde. > 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. > For some of the classes, that's the only way, because they are > interdependent with other Qt classes. Name me a situation where you can't just get a copy of the qt class, make a new class from it, and patch that. I don't see any. > Besides, one of the few requirements that the GPL imposes is that you > clearly label your fork as such. And qt-copy does that. Never was it said > that it is Qt. What's more: it does. officially. you know very well, that people are even advertising qt-copy as qt in the irc channel (oh look, here are binary qt builds for msvc......), and i have to go explain people that this is NOT qt. everytime....., thats exhausting. Also the issue are distributions who are forced into that. The avarage user doesn't know why some qt based program doesnt work. They will assume the program is faulty. becouse kde works with this version of "qt". sad. > 1) KDE has *never* released a package called qt-copy with the patches > applied depends on who you call kde. of course YOU didn't. but kde other people do. even if not on the kde page, but in the distros, or their pages, or whatever. the general opinion inside kde is that they are doing the "good" qt, and that trolltech is just to slow and a big bad corp and whatnot (oh yeah, webkit discussion) > 2) patches are not applied unless you *specifically* choose to That's new to me. the build tutorial says clearly to use qt-copy, and distro packages dont let you choose between trolltech-qt and kde-qt. that would completly make me silent at once, if the user had the choice. and the developer, so we could flag our applications to depend on trolltech-qt > 3) KDE applications *must* work with a stock Qt and not depend on any > behaviour of the patches. yeah? whats the point of qt-copy then? > 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). static builds would be fine, becouse they don't add the illusion that the patched version is the original qt. I'm sure you would be pretty pissed and maybe even sue me if i'd rename MFC to Qt and distribute it on some major channel. (applications, distros, whetever). > So, in summary, I don't find anything wrong with qt-copy. Please be fair and add, that you are a major KDE developer. You have a clear position you have to defend. I'm pretty sure that if you where in my situation (developing high quality Qt applications rather then KDE) you would see things different. I know you opose bad quality. In almost all situations on IRC we clearly agreed how to implement specific software. Yet you defend a big repository of software that violates all this. -- [ signature omitted ]
Hello to all, I am a commercial user of QT 4 (windows), and had a look at this discussion, it looks like the religion wars of the last decades..... All the things, happening actually in the linux world, is more than crazy. Instead of working together, the linux people fight against each other.... Our company has decided, not to develop for linux, because of missing standards and streams to a thousand of directions..... People should understand, that a company which also have a commercial background cannot support everything, that sometimes was derived from qt and is now incompatible. If I deploy a software, I have to trust not alone the things, I programmed, but also things that comes from others, here Trolltech. No company can support a so wide range of patched software and also commercial devs cannot handle this. I only see it from the commercial point, and need staple dev. tools from trolltech. If I have a problem, found an error, both sides must have the same environment, to find the real error and not a side effect from a patched derived version. So only one "true" and "official" QT-release must exist ! As long as open source programmers work with the given rules (binary compatibility), and deploy their work not with DLLS, that have the same name as the original ones, everything is ok for me. So the linux people should find a solution for that chaotic situation or stop using official qt versions and write their own... Regards from germany, Peter Arvid Ephraim Picciani schrieb: > On Tuesday 11 March 2008 13:50:45 Thiago Macieira wrote: >> That's the nature of Free Software. Anyone can make modifications and >> re-release. Being concerned about the effects of the model we chose would >> be kind of hypocritical. > It's not the result of free software. Just name me one project that has done > the same thing. oh yeah linux, but i opose novell too for calling their > heavily patched linux, linux at all. becouse it isnt. other projects like > xen do it the right way and just call their linux linux-xen. As kde should > call their qt qt-kde. >> 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. >> For some of the classes, that's the only way, because they are >> interdependent with other Qt classes. > Name me a situation where you can't just get a copy of the qt class, make a > new class from it, and patch that. I don't see any. >> Besides, one of the few requirements that the GPL imposes is that you >> clearly label your fork as such. And qt-copy does that. Never was it said >> that it is Qt. What's more: > it does. officially. you know very well, that people are even advertising > qt-copy as qt in the irc channel (oh look, here are binary qt builds for > msvc......), and i have to go explain people that this is NOT qt. > everytime....., thats exhausting. Also the issue are distributions who are > forced into that. The avarage user doesn't know why some qt based program > doesnt work. They will assume the program is faulty. becouse kde works with > this version of "qt". sad. >> 1) KDE has *never* released a package called qt-copy with the patches >> applied > depends on who you call kde. of course YOU didn't. but kde other people do. > even if not on the kde page, but in the distros, or their pages, or whatever. > the general opinion inside kde is that they are doing the "good" qt, and that > trolltech is just to slow and a big bad corp and whatnot (oh yeah, webkit > discussion) >> 2) patches are not applied unless you *specifically* choose to > That's new to me. the build tutorial says clearly to use qt-copy, and distro > packages dont let you choose between trolltech-qt and kde-qt. that would > completly make me silent at once, if the user had the choice. and the > developer, so we could flag our applications to depend on trolltech-qt >> 3) KDE applications *must* work with a stock Qt and not depend on any >> behaviour of the patches. > yeah? whats the point of qt-copy then? >> 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). > static builds would be fine, becouse they don't add the illusion that the > patched version is the original qt. I'm sure you would be pretty pissed and > maybe even sue me if i'd rename MFC to Qt and distribute it on some major > channel. (applications, distros, whetever). >> So, in summary, I don't find anything wrong with qt-copy. > Please be fair and add, that you are a major KDE developer. You have a clear > position you have to defend. I'm pretty sure that if you where in my > situation (developing high quality Qt applications rather then KDE) you would > see things different. > I know you opose bad quality. In almost all situations on IRC we clearly > agreed how to implement specific software. Yet you defend a big repository of > software that violates all this. -- [ signature omitted ]
On Tuesday 11 March 2008 14:31:20 Arvid Ephraim Picciani wrote: > > So, in summary, I don't find anything wrong with qt-copy. > > Please be fair and add, that you are a major KDE developer. ÂYou have a > clear position you have to defend. That's right, I am a KDE developer. But I also don't use qt-copy. In fact, the only time I touch it is when I upload the new Qt release -- and I have the clear policy that I don't touch the patches. As for Linux distributions patching Qt... they do that to all packages! The only distribution I know to use pristine packages is Slackware. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On 11.03.08 14:31:20, Arvid Ephraim Picciani wrote: > On Tuesday 11 March 2008 13:50:45 Thiago Macieira wrote: > > That's the nature of Free Software. Anyone can make modifications and > > re-release. Being concerned about the effects of the model we chose would > > be kind of hypocritical. > It's not the result of free software. Just name me one project that has done > the same thing.> oh yeah linux, but i opose novell too for calling their > heavily patched linux, linux at all. becouse it isnt. other projects like > xen do it the right way and just call their linux linux-xen. As kde should > call their qt qt-kde. I don't see how calling the svn folder qt-kde instead of qt-copy would make any difference. > > 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. > > For some of the classes, that's the only way, because they are > > interdependent with other Qt classes. > Name me a situation where you can't just get a copy of the qt class, make a > new class from it, and patch that. I don't see any. 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. > > Besides, one of the few requirements that the GPL imposes is that you > > clearly label your fork as such. And qt-copy does that. Never was it said > > that it is Qt. What's more: > it does. It does not. > officially. 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/ > you know very well, that people are even advertising > qt-copy as qt in the irc channel (oh look, here are binary qt builds for > msvc......), and i have to go explain people that this is NOT qt. You don't have to do that, its your choice to do it. Besides, you can't do much about people that don't (want to) read anyway. They'll always be there and this is not only with Qt this way. Its the same thing about kde libraries and even stuff in the project I work on. People come into IRC and ask always the same questions, without even looking at the projects website and documentation. Thats a social problem, not a technical one. > everytime....., thats exhausting. Also the issue are distributions who are > forced into that. Why is any distro forced into using qt-copy (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. And distro's are known to patch the hell out of any project, if they see the need for it. > The avarage user doesn't know why some qt based program > doesnt work. They will assume the program is faulty. becouse kde works with > this version of "qt". sad. 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 > > 1) KDE has *never* released a package called qt-copy with the patches > > applied > depends on who you call kde. See above, KDE has a website where releases are announced and a fixed position on an ftp server where you can find the stable releases. Anything else is not official. > of course YOU didn't. but kde other people do. > even if not on the kde page, but in the distros, So, what the distro's do or don't do doesn't depend at all on what KDE does. They do what they do because their users want them to do it (for example having a Qt that works properly in an XRandR 1.2 environment). > or their pages, or whatever. Would you please point to the pages you've seen? > the general opinion inside kde is that they are doing the "good" qt, and that > trolltech is just to slow and a big bad corp and whatnot (oh yeah, webkit > discussion) Yes and the reason for that opinion is (as far as I can see) not coming from nowhere. Things are improving wrt. the code-interaction, but as far as I've heard (only been involved in this whole thing for about 2 years) this wasn't always the case. And thats been said by TT employees in public lists. > > 2) patches are not applied unless you *specifically* choose to > That's new to me. the build tutorial says clearly to use qt-copy, You should start reading the text and not just the headlines. It clearly says that if you don't want to use distro packages. > and distro packages dont let you choose between trolltech-qt and > kde-qt. The point of using a distribution is to actually not have to take care of patching the sources. Which is in some cases simply not avoidable. If you want to have clean upstream sources, use LFS. > that would completly make me silent at once, if the user had the > choice. Then the user needs to use a distro that doesn't patch Qt. But you won't get that for any major distro that sells their packages on CD's. Shipping a completely unpatched Qt doesn't sell any of these CD's. > and the developer, so we could flag our applications to depend on > trolltech-qt As Thiago said, neither binary compatibility, nor API nor behavioural changes are allowed in qt-copy. What distro's do is the choice of the Qt packagers in that distribution. If they screw up you should address that with proper bugreports for that distribution. Neither TT nor KDE can do anything about that. > > 3) KDE applications *must* work with a stock Qt and not depend on any > > behaviour of the patches. > yeah? whats the point of qt-copy then? Thiago already explained that, so please go up in the thread and re-read. > > 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). > static builds would be fine, becouse they don't add the illusion that the > patched version is the original qt. I'm sure you would be pretty pissed and > maybe even sue me if i'd rename MFC to Qt and distribute it on some major > channel. (applications, distros, whetever). Except that this would neither be binary nor source nor in any other way compatible. The thing is that you can simply _replace_ your TT-Qt with qt-copy and run your application against it and then get a couple of extra bugfixes which didn't (yet) make it into the official Qt. > > So, in summary, I don't find anything wrong with qt-copy. > Please be fair and add, that you are a major KDE developer. You have a clear > position you have to defend. I'm pretty sure that if you where in my > situation (developing high quality Qt applications rather then KDE) you would > see things different. 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. Besides, he didn't do that much in the last months in KDE anyway (code-wise) Andreas -- [ signature omitted ]
Andreas Pakulat wrote: > On 11.03.08 14:31:20, Arvid Ephraim Picciani wrote: > >> Name me a situation where you can't just get a copy of the qt class, make a >> new class from it, and patch that. I don't see any. >> > > 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. > Or any changes at the *bottom* of the hierarchy - any of the classes that you don't instantiate directly: QFSFileEngine, any of the PImpl classes, QDomElement... etc., etc. -- [ signature omitted ]