Qt Toolkit Support Likely to be Dropped from MozillaWednesday February 12th, 2003dasx writes: "Looks like the Qt port of Moz is going under. It's been stricken from the 1.3b branch — which probably means it's gone for good. Hopefully, some of us can bring it back to life." Please don't spam the bug with useless comments or whining. Update! A page describing the current efforts to get the Qt port back to a working state has been posted. And for that matter, don't spam any bug with useless comments or whining. I know I should not spam any bugs with useless comments or whining, but please please please fix them all ASAP. They prevent me from using mozilla. I cannot believe that so many bugs have been around for so long without anybody fixing them. If I knew how to program, I would definately help solve them all. Mozilla hackers are weenies. Until all the bugs have been fixed my only option is to use IE and steal candy from children and worship the devil. As cls says in the bug, it's not about bringing to life. It's about _keeping_ alive. Being a port maintainer requires a constant investment of time. You have to make a commitment to do it. Could somebody in the knows explain what the qt port is and what it is needed for? Obviously we can have Mozilla without it, so what is the idea of this? The idea is to use the QT toolkit instead of the GTK one (that's the one the mozilla.org Linux nightlies use). This would allow better intergration with KDE (in the QT port), including support for the current KDE theme when using the Classic theme, reuse of various QT components (QPrinter), use of the native QT filepicker (like other KDE apps) if desired, and so forth. AFAIK, the GTK filepicker etc is not used in Mozilla. It's all done with XUL, which uses GTK as its backend toolkiit. I wouldn't have thought that using QT would make much difference in this respect, unless the idea is to not use XUL for the interface. Anyone care to explain this better than I? > AFAIK, the GTK filepicker etc is not used in Mozilla That's because the GTK1 filepicker sucks a LOT (no useful support for non-Western chars). Once we switch to GTK2 we are likely to switch to the native GTK filepicker as well. I think it's good to drop this waste of resources. MacOS Classic goes down to ports and this never really working think is kept..? QT is already a port. No one is suggesting removal of MacOS Classic from the build completely yet, though if no maintainer appears for it it will have the same issues as QT does now. So, no wonder there is alot of bickering and talking. I downloaded the open source code last night and tried to do the 'gmake -f client.mk build' and it terminated with an error to GFX. Is there a workaround to this? Thanks!!! I don't get it. Has QT really been dropped from the branch? But seawood's patch to remove QT has not been approved for 1.3 and Asa remarked that resolving the situation- either removing QT or fixing it- doesn't have to happen in the 1.3 timeframe. If it had been removed, one would expect to see a comment on the bug stating as much and/or approval of the patch to remove QT. Anyway, here are my thoughts: "Hopefully, some of us can bring it back to life." That is what people have feared all along- that the decision to drop the QT code would be lamented and a bunch of people would try to get it to a state where it could be included in the tree but not really be interested in maintaining it, thus increasing overall breakage. If there were people who were really willing to maintain the QT port, with all the continuous year-round fixing and testing that entails, working to keep it just as up-to-speed with the latest patches as the GTK port, then people wouldn't be dropping the code. The question now is whether people have really stepped up to maintain it or if they are just trying to keep it in the tree. I still don't see any real reason for the existence of a QT port besides toolkit fanboyism. People may quote other ideas, but would they really get implemented? |