The qt port (--enable-toolkit-qt) has been busted since the 0.9.9 timeframe (~9 months at this point) and numerous times before that. The port also lacks a maintainer which would explain its tendency to bitrot. I've sent mail to drivers, m.builds, m.unix & m.qt concerning the problem. If we don't have a working port by the time the tree closes for moz1.3beta (~10 weeks), the port should be removed.

Let's not let this happen! Let's get qt working again, then I will be maintainer if nobody else will.

I haven't seen any patches to get it going again. Tick...tick...tick...

blizzard: In n.p.m.qt there is an ongoing discussion about why the current patch has problems, and Esben seems to find out more about it almost daily. It seems he also found a/the key why it got problems currently. Well, we'll see.

Sigh. Modern people are in such hurry :-P If this is so urgent, please direct me to some info which shows how the autoloading/registering works. Because the QT gfx factories aren't called. Not at all. So when the first widget (i.e. window) is constructed, it cannot get the device context. This, apparantly, is not considered an error, an execution continues regardless. But with no device context, nothing really happens. More details in the qt newsgroup, which are quite low traffic :) (scurries off to read through the developer info)

Hi, I have been following this port for a while now. Basically I've read all the postings. Tried the patches. No luck yet though. If I get my name in lights I'm very keen to be "one of the admins" of this port. My knowledge of C++ and qt and even C is laughable. But I know how to patch, compile and fiddle. I check email every day ('cept weekends). I'm also happy to get my hands dirty. From what I have seen on the newsgroup Esben is really the man for the job. I'd like to nominate him or second his nomination ;) and I'd like to help him out. I use KDE as my desktop and mozilla as my browser. I'd really like to play together nicely.

Is it possible for this project to get some space on mozilla.org or somewhere to put up a web page detailing what is happening. I'm happy to do a bit of HTMLing. There is also Esben's patch that will probably be the starting point of this reincarnation of the project and it would be nice to redirect people to this page to get the patch and start fiddling. I have sourceforge membership if we need to go there.

It seems Esben has something that compiles! We just need some way to share work. Why not check it in, the current CVS state of gfx/qt is broken anyway. If it compiles, more people can start to work on it.

I'd volunteer to check in Esben's patches whenever needed, as I have a CVS write account and it's not built by default, so it's not that bad when I don't know the real code too good. Of course, I'll build (and use when it works) the code myself, and of course I need to know what review requirements there are for this parts of the code. cls, any advice for that? btw, I change the summary to state that we have two ways: remove it - or get it working :)

review requirements: ports need port owner review and have an "automatic" sr=blizzard. now, if there is only one module owner and he wants to check something in, I do not know what's the policy :)

I'll clean up the code I have an attach it to this bug shortly or tomorrow. I'm currently trying to get it to show the ProfileManager (because it's simple --- just one modal dialog.) For some reason nsWidget::Show() isn't called, which seems strange to me, but what do I know :)

I'm going to jump in. I've started to play with Qt/KDE recentely and very like it. I was always wondering why Mozilla wasn't already using qt instead of GTK ;-) I'm not interested in the main role thought. I'll get the tree and see how I can patch and get Qt/Mozilla working.

Same with me. I'll try to help.

We use gtk instead of qt because of qt's licensing.

Is there still issues with the Qt Free Edition License? Can the code written to interface to the lib be made MPL/GPL etc... if we don't link? This should be clarified before we commit stuff no?

AFAIK the point is that mozilla is not a strictly free software (it is used by AOL/Netscape as commercialware). This could mean that they have to buy qt licenses if qt is not just a module but the standard toolkit. Additionally, I think the decision for gtk was made before there was a gpl'ed qt. I think the maintainers have had their thoughts on that before they let anyone commit qt-based code into the repository. No problems should arise. Apart from that, again AFAIK, Troll supported the first port to qt and is definitely well-informed about how much qt is in mozilla. Please correct me if i'm wrong. ;-)

Yes, the original port was made after mozilla was open sourced (April 2001) by 5 trolls and 2 netscape employees: The QtMozilla team members are: Warwick Allison, Kalle Dalheimer, Eirik Eng, Matthias Ettrich, Arnt Gulbrandsen, Haavard Nord and Paul Olav Tvete. The animated "spinning globe" button was created by Brodd Nesset. Animal wrangler: Eirik Aavitsland (from http://www.trolltech.com/qtmozilla/) As long as you use the Qt free edition, it is available under the GPL. There should be no issues with licensing.

Heiko, what Netscape (and others) do and do not is of no relevance here, as it is (imho) highly unlikely that they'd make a Qt version of their Mozilla distributions. So - Netscape is not allowed to ship a Netscape version with the free version of Qt, because it is neither GPL nor the source is available. Mozilla, on the other hand, may use Qt under the QPL, aiui. Not under the GPL, because Mozilla is not yet fully tri-licensed, ie. most parts of Mozilla are not GPL yet. yes, I also think that the decision for Qt was made before it was GPLed. but see above why mozilla can not use Qt under the GPL license. finally, IANAL.

Here's my current patch. Sorry about the delay --- I swear somebody was standing on the wire to America. To those who have unsuccessfully tried my older patches: This patch is *really* against the CVS head... which was untrue before. My bad :-(

I'm going to throw in my 2 cents on this one (and vote for this bug) because the Opie handheld enviroment for OpenZaurus can use a Mozilla/QTEmbedded browser.

*** Bug 183738 has been marked as a duplicate of this bug. ***

1. There are no issues with Qt licensing. 2. I voted for this bug, because it (was) one of Mozilla's nicer aspects -- you could build it against either toolkit you preferred. And if I have the choice I will take Qt over Gtk for all of my applications. 3. I appreciate anything you folks can do to get this working (and stable). Alas I don't have any money but you have my undying gratitude.

ok, i'm going to commit a version based on the patch here. i've gotten a window to load. things that don't work: plugins (macromedia.com was my first test page because i thought i was testing my xlib+nullplugin build) and images (mozilla.org was my second page).

CC -> self

It seems the basics are done now. Shouldn't we close this bug here and make small bugs for all the issues still there? Perhaps with a tracker for them?

ok so i can now run: mozilla -P foo http://www.mozilla.org and get a window. I'm using Qt3.0.4(mt) If you happen to have a system like phroggy's where you only have libqt-mt.so or if you happen to have a system w/ libqt2.so / libqt3.so (freebsd)? then you'll need some configure.in hackery. for now, people who want to do work and don't want to debug the profile manager problem (iow people who would prefer to work on menus and images) should use -P or make sure there's only one profile. next steps: contact paper/biesi on #mozilla about imagelib (gif frames never have their append method called so they assert when asked for the first [one based] frame -- stacks showing what calls this method under xlib and gtk should help debug the problem) contact pocemit and netscape's plugin team about plugins contact someone about random crashes in Qt land. or use valgrind. figure out why the profilemanager doesn't display (this is a maze of twisty messes all annoying). Bug 79120 already tracks my Qt work. I'd encourage people interested in Qt to look through the bugs in its tree and add bugs to it as they encounter them.

fwiw: I believe the imagelib problem is that qt's gfxImageFrame's init or construction is failing, and the gif decoder has no way to let that error bubble up, so it asserts later. but I have no data to back that assertion up. I'll investigate sometime.

Err. You're jumping the gun here. Nothing's checked in or has been verified to work. Show me the build and stop hijacking bugs.

cls: There was something checked in today, and it seems to be working basically - though with still a bunch of problems left.

*** Bug 144216 has been marked as a duplicate of this bug. ***

What "configure" options should one use to compile?

use ./configure --enable-toolkit-qt --enable-default-toolkit=qt this is from memory, but it should work. you might want additional options like --disable-debug --enable-crypto note that it doesn't fully work yet... for me, it doesn't even start. but feel free to try.

FWIW I compiled with qt and main window showed up but the menus doesnt work at all...

FYI I was able to compile it with QT 3.1 (qt-x11-free-3.1.0, selfcompiled) However, I had to add the compile flag -DQT_NO_STL, because there was some strange interference between stl and mozilla headers (notably "string"). As a start, I put the flag into config/autoconf.mk at MOZ_QT_CFLAGS. Of course this file gets overwritten by configure...

I forgot to say that mozilla loads and displays the main window. Icons and menus are broken.

see bug 185621 for the QT_NO_STL issue

*** Bug 189110 has been marked as a duplicate of this bug. ***

*** Bug 189110 has been marked as a duplicate of this bug. ***

Status report: -------------- We now have (at least) three people working at the code (=biesi, timeless and gisburn), a bunch of contributors, a couple of Qt-related checkins per week and the code is mainly working now: - Code builds on various versions of Linux and Solaris with both Qt 2.x and Qt 3.x (verification that it builds on AIX 5.x is on the way...) - Startup/Shutdown works properly, incl. profile manager - Browsing using Mouse and Keyboard works Remaining issues to get the port in sync with GTK+ and Xlib ports are: - Menus do not work in Qt 3.x (however we have reports that they work in Qt 2.x, we have to verify that and check what was changed between Qt 2.x and Qt 3.x) - Minor glitches with events which seem to cause issues with bookmark loading/handling (the same issues seems to confuse text input widget focus in rare cases when Qt 3.x is used) - X-remote does not work - BiDi and CTL(=Complex Text Layout) support has not been implemented yet, I am going to work on that once smontagu is back from his vacation (technically easy to implement, but I have to ask a bunch of questions) Given the above progress (I know we are little bit slow - but the GTK+ and Xlib toolkits had three years time to become mature - trying to catch-up this development time within 10weeks was illusory from the beginning), we request that the Qt port *not* be removed (if you want a target milestone - what about 1.5beta freeze ?).

> We now have (at least) three people working at the code (=biesi, > timeless and gisburn), a bunch of contributors, a couple of Qt-related > checkins per week and the code is mainly working now: Is it working well enough to pass the smoketests? And are these people working on the code actually committed to taking it the rest of the way or am I going to continue to get responses of "I'm not working on Qt now" when I ask about some Qt-related bustage? This was exactly what I was afraid of. People putting enough effort in to get the port hobbling but not really committed to making it work like a true port should. > (I know we are little bit slow - but the GTK+ > and Xlib toolkits had three years time to become mature - trying to > catch-up this development time within 10weeks was illusory from the > beginning), That's blatantly misleading. The Qt port had the *same* 3 years to become mature that the other toolkits had. The fact that no one bothered make the port work again until it was on its deathbed says something all by itself. > we request that the Qt port *not* be removed (if you want a > target milestone - what about 1.5beta freeze ?). 1.5b is a *long* ways away. If you're requesting an extension, 1.3 final or 1.4b would be more appropriate.

The deadline of 1.3b has passed. Last I heard it isn't useable. Does QT work? As much as I like the simplicity of the QT code, if it doesn't work now, I think it should be removed. If someone dedicated to the continual upkeep of QT comes around, they could always pull it from the attic/archives/wherever removed stuff goes.

My build from earlier today would not have passed the smoketests. Menus don't work properly and the profile manager appears to not work at all. There are obvious repaint issues and certain keybindings do not work (eg. cannot use F9 to close the sidebar). The QT_LAST_RITES static tag has been created. Use: cvs -z3 co -r QT_LAST_RITES mozilla/client.mk make -f client.mk pull_all to pull the old tree. If anyone wants to continue the work, they should start by pulling that tag and then, optionally, making a branch to work on.

In addition to the changes in this patch, we need to 'cvs remove' all of the files under mozilla/gfx/src/qt and mozilla/widget/src/qt .

cls: 1. I still like to work on the Qt toolkit and others like to work in it, too. 2. I need the gfx/src/qt stuff as basis for the QPrinter work for Mozilla I do not see a reason why we should remove something where people are still working on.

Christopher Seawood wrote: > My build from earlier today would not have passed the smoketests. Menus don't > work properly Known problem, likely due a difference in between Qt 2.x and Qt 3.x > and the profile manager appears to not work at all. There is a patch to get it working. > There are > obvious repaint issues Also known problem that we have problems with clipping and invalidation. I am working on that. > and certain keybindings do not work (eg. cannot use F9 > to close the sidebar). the widget/src/qt/ keycode translation code simply needs to be updated

Comment on attachment 114180 [details] [diff] [review] Remove qt from tree Restoring bryner's r= & approval request.

Hi, from a user perspective (sorry, I don't help out resolving the Qt issues, yet), I'd like to ask to either a) postpone the removal of Qt or b) setup a Mozilla subproject that tries to create an external Qt patch on the Mozilla tree with the goal of re-inclusion at a later point. However, I *do* wish to see Qt toolkit version of Mozilla again and hope that Qt developers will get it back in a working state again. Thanks to everyone working on this, Hanno

Hanno Mueller wrote: > b) setup a Mozilla subproject that tries to create an external Qt patch on the > Mozilla tree with the goal of re-inclusion at a later point. Based on my experience in the last three years I'd say such a project would have zero chanches. Once we remove Qt from the mozilla tree it's support will be dead. forever. We really should think about doing this step (Qt removal) since it will be final.

Not to sound like a whiner and such, but I've seen this pattern before: The decision is IMHO already made, the qt support will be removed whatever you do. That's why I quit working on this since comment 39... but at that point I wasn't in sufficient black mood to say this. Note the short deadline, the funny arguments "The Qt port had the *same* 3 years to become mature that the other toolkits had. The fact that no one bothered make the port work again until it was on its deathbed says something all by itself." Until a year or two ago, /Mozilla/ was barely hobbling along --- working on additional toolkits seemed a waste of time. During these three years checkins that broke the gtk tookkit was certainly fixed or backed out, but breaking the qt toolkit... Also note that there is little valid reason to remove the support in any case, except maybe saving a few kbytes in download. Now, if nobody wanted to be maintainer of this, it would be a different story. Bah, I'll stop this rambling.

Esben Mose Hansen wrote: > Not to sound like a whiner and such, but I've seen this pattern before: The > decision is IMHO already made, the qt support will be removed whatever you do. > > That's why I quit working on this since comment 39... but at that point I > wasn't in sufficient black mood to say this. > > Note the short deadline, the funny arguments > > "The Qt port had the *same* 3 years to become > mature that the other toolkits had. Another point about this issue: I am involved with the Qt port since only a few weeks. I did not had the "three years" of time which are quoted here a lot. To get the QT toolkit in sync with all the features of the GTK+v1 toolkit it will need at least(!!) one year (assuming one engineer is working on it. Multiple people _may_ be faster. -->"MAY"<-- ). Take a look at the GTK+v2 work - they are working on it since a year and they are still not in sync with the GTK+v1 toolkit. > Also note that there is little valid reason to remove the support in any case, > except maybe saving a few kbytes in download. cls@seawood.org's argument is a different - the existance of the Qt toolkit may indicate that mozilla.org support it (if I understand him correctly). Based on that we could simple add a huge 'echo "## not officially supported by mozilla.org nor is this code ready for production usage." into "configure.in" to indicate that this code is for developers only. > Now, if nobody wanted to be > maintainer of this, it would be a different story. We have at least two people (one if them is my person itself... :) who are willing to maintain it if noone else with more time has time to do it - so there is the gurantee that there will be a maintainer. And finally: I'd like to create a new project based on the gfx/src/qt/ toolkit - "QPrinter" - a print module based on the libQt QPrinter API for printing (the PostScript module is mainly dead now but unfortunatley RedHat blocks Xprint which was targeted as replacement for the PostScript module. Unless RedHat stops their blockade we may need a 3rd print module which gets accepted by all vendors (the final QPrinter module will likely not a match for the Xprint module (Xprint is simply more powerfull than QPrinter :) but at least a far better working alternative to the PostScript module)). The problem is - we need to share/borrow lots of code from gfx/src/qt/ for gfx/src/qprinter/ (like gfx/src/xprint shares ~~90% of it's code with gfx/src/xlib) to avoid that we have to reinvent the wheel for QPrinter support. The removal of the gfx/src/qt code would be the death of the gfx/src/qprinter project as well.

> Note the short deadline, the funny arguments Yes, I wondered about that. But I guess the real issue is: > Now, if nobody wanted to be maintainer of > this, it would be a different story. Well yeah, _who_ is the maintainer of the Qt port? I presume the Mozilla folks complain that nobody is. If someone actually walked forward and took the responsibility, the port would have much better chances of survival.

Hanno: If you don't want Qt to be removed, then why are you voting for this bug?

Robert O'Callahan wrote: > Hanno: If you don't want Qt to be removed, then why are you voting for this > bug? Because the summary of this bug ("Remove qt toolkit support from the tree or get qt toolkit working again") is _horribly_ confusing. I hope that most people voted for the 2nd part of the summary ("... get qt toolkit working again") :))

Roland: 1 & 2) Use a branch. Esben: Not that I want to encourage more whining but afaik, the decision has not been made, hence the removal requests. Your arguments themselves are quite ... "funny". The "short deadline" as you refers to it was nothing of the sort. The desire to remove the qt port was first mentioned in July when the port *did not compile for over 4 months* already! The port itself was in pretty sad shape and had been lacking an active maintainer for some time before that. John Griggs, the previous maintainer, stopped actively working on it in mid-2001? I posted to the newsgroups in September about needing an *active* maintainer and the deadline for removal was given 2 months after that. If there was *real* interest (where real is defined as doing the work not just talking about it), then it there would have been no need to open this bug to begin with. Mozilla was well beyond hobbling even as of 2 years ago. It may have lacked polish (still does in some aspects) and was sufferring from severe feature creep, but it was still a usable product. You make it sounds as though Mozilla 2 years ago was in the shape the current Qt port is. With the exception of transient bustage, the Mozilla was in far better condition. FYI, we did have additional toolkits working at that time. 2 years ago, the qt port was in better shape than it is now. The xlib port has managed to survive that so-called hobbling period as well. I haven't built the xlib port recently but from the bugs I've seen, it has an active maintainer (Roland) who fixes bugs and actually works on it other than when the someone complains about bustage. Also note, if there was qt bustage that wasn't fixed, exactly how important was the qt port to the qt community who is requesting that we retain this port? Even some of our fringe platforms (namely OpenVMS which is maintained by a single person) routinely do a milestone build at the end of each release cycle and contribute patches to fix problems that may have occurred in each cycle. Exactly how important to you expect people to believe the qt port is when it goes *several* milestone releases without even compiling? And I mean final releases, not the alpha/beta interim releases. The code was bitrotten. That should be reason enough to remove it. Additional reasons are the extra KBs of space and the extra time wasted doing cvs updates. And from a build maintainer perspective, we're advertising a feature (via ./configure --help / the build configurator page) that doesn't work. The Mozilla project has far enough maintainers in name only. We really need to get away from that. Show me the code.

> If you don't want Qt to be removed, then why are you voting for this bug? This is indeed confusing. I wanted to show my interest in this matter. A bug no user cares about is not a bug developers will take care of. I'll revoke my vote. Trouble is that there is no "I disagree" voting possibility.

Christopher Seawood wrote: > Roland: 1 & 2) Use a branch. As I stated above in this bug this procedure failed in the past (where is gfx/src/nanox/ ?). Why should it work now for the Qt toolkit ? BTW: All your argumentation applies to other code like gfx/src/ps/ as well (which has no maintainer and is half-defunct (print preview only 25% working, most printer hardware fails to process the generated postscript, etc.). If you are so hot to remove unmaintained code we should remove all unmaintained/nonworking code and not small parts where people are complaining loudly when we remove it without having a replacement in hand.

> As I stated above in this bug this procedure failed in the past (where is > gfx/src/nanox/ ?). Why should it work now for the Qt toolkit ? I have no idea what happened with nanox. The idea is that you work on the branch until your code is ready for the trunk then land it. If it never landed, then was the code never ready? Or did someone not push hard enough for it to be landed on the trunk? I don't see a parallel between nanox & qt as we've had plenty of projects start on branches and then land on the trunk *when they were ready*. > BTW: All your argumentation applies to other code like gfx/src/ps/ as well As I said on IRC, if you're so hot to replace postscript printing, then drive that effort. That has absolutely nothing to do with qt. Btw, postscript printing works for me. The qt port does not. > If you are so hot to remove unmaintained code we should remove all > unmaintained/nonworking code and not small parts where people are complaining > loudly when we remove it without having a replacement in hand. It's in some people's nature to whine. If not about this, then it'll be somethng else. If the whiners aren't producing code or otherwise facilitating the production of code, then don't see why I need to be overly concerned.

Mr. Seawood: This is leading nowhere. Can you answer this? Do you have any (realistic) criteria that would make you NOT remove the qt port? Please be exact. E.g: Qt build must be able to correcly display www.google.com and www.mozilla.org in 2 months + have a maintainer. Then everyone can decide what to do. This indecision is grating on everyone's nerves :-( Please? <end of slightly interesting part> Let me put my earlier comment in another way: I don't want to waste my time. In my humble opionion, the decision was already made 3 months ago when this bug was opened. At that time the author asked for, in 10 weeks, a working QT port. I, and others, assumed the author meant "prove that it will be brought to a working state", as believing that a team could be assembled and investigate and fix enough problems in the qt build to make it fully work in 10 weeks time was, well, unrealistic. In comment 39 the original intent was clarified as "if this port doesn't pass the smoketest, it is not working and will be removed." Asking this is IMHO asking the impossible, as the author would have to know: Thus, I conclude that the decision was already made three months ago. Now, don't get me wrong: mozilla.org has every right to make this decision. I just don't want to waste my time trying to make something work when it has been decided to remove it --- and I don't think anyone else wants to waste their time, either. Making a qt branch might be a solution, though this branch should probably be made from the 1.3 branch, right? No need to branch from a otherwise unstable build...

Using a branch is likely not a (good) solution. I do not have write access to cvs.mozilla.org (and what I have heared I will never get access to it) nor do have external contributors access to it. And checking-in into a branch is much more pain for the people who normally care about checking-in contributors patches so using a branch will make it _significant_ more problematic(=PAIN) to work on the Qt port. The barriers are already very high, using a branch will likely move it out of people's reach.

This doesn't block the release of 1.3.

mozilla.org already laid out the criteria for the main builds. Builds have to pass the smoketests, http://www.mozilla.org/quality/smoketests/index.html , or the tree will remained closed until the bugs are fixed. For me, the port should at least pass following smoketests for it can be considered "usable": profile manager, browser, editor & mail. And there should definitely be bugs filed on the other failed tests. That should have been done by the deadline proposed. There's no indecision on my part. The terms were given months ago. We've passed the deadline and the code should be removed. I don't have the authority to do that single-handedly so I'm waiting for the approval. Even if you had no idea what "working" meant, the others involved (namely Roland, timeless & biesi) are well aware of what is considered working and what's not. I don't think the terms were impossible if someone was truly intent on making the port work. Remember, the original port was done in 5 days by a dedicated group (albeit on a small tree & different codebase). The intent was clear when this bug was opened. I have stated a number of times that I'm not interested in people getting the port just barely running and then let it bitrot again due to neglect. I don't need proof that the port *can* be in a working state. We've seen that before when the port was actually maintained. It should *be* in a working state or not be there at all. The feeling of a waste of time goes both ways. It's a waste of my time to deal with people complaining about build features not working as well as dealing with people complaining when their pet feature is being removed because they neglected it. People want broken build features fixed or removed. People also want pet features fixed (usually by someone else) and given special exceptions so that the feature will stick around even though it can cause problems for others. You can see how those demands could case a problem, especially, when they aren't backed up by code to resolve the problem. This is why I'm not interested in talk about what *can* be done. I'd rather be shown code demonstrating what *is* being done. And you speak as though projects that aren't in the main mozilla tree aren't worth doing. There's an entire community at mozdev.org that would beg to differ. Contrary to Roland's ravings, a branch would be the way to go if you were seriously interested in getting the qt port working again with the intent of resubmitting the port to the main tree. You would avoid the issues mentioned before about the rest of the codebase changing around you, you could go at your own pace and those with checkin access do not need to ask permission to check in on a branch. Roland doesn't have checkin access (for good reason) but timeless & biesi do as do a number of other contributors. If these "maintainers" cannot take the time to check in a contributed patch on *the* qt branch, then they're not being maintainers and shouldn't be treated as such.

Today I get the information, that there is a QT port of mozilla so I'll try my best to help you. And I'm against removing from cvs. I would say if it doesn't hit a smoke test on mozilla1.4b then branch it.

Since a lot of people, in the past, have offered to help in different roles, its apparent there is a mass in favour of keeping the QT port. All that is needed is an organized effort to get this working, wouldn't it make sense to agree on a non-arbitrary deadline? I am willing to act as a daily build tester, and other general testing. I use Mozilla for all my work, and I have access to different boxes running old kde as well new. My current C++ and QT skills are not upto mark, but can pitch in with patches with due course.

people, feel free to create such a branch yourself. getting cvs access if you only want to check in on that branch should be quite easy, afaik. or ask others (cls might be willing to do it?) to create said branch I would be willing to check in patches into such a branch. timeless or gisburn might be willing to produce "nightly builds" of the qt branch (timeless could maybe make the builds of his tinderbox available) While I'm writing a comment... I'd like to officially state that I am not working on the qt port anymore. (and haven't in the last few weeks)

Please get qt toolkit working again. Come on guys, this looks like a religeous war. I use KDE and mozilla and would choose qt over gtk every time, but I don't go round advocating the death penalty for gtk. Linux is about choice.

I have taken care of getting back in touch with endico/cls to get a port page up and probably a branch as well. I don't see any real difference between having a branch or the trunk. I will try to put information about past works done on the qtmozilla and list people interested in works and who submit patches. Because I personnaly don't care about trunk/branches I'm leaving that political fight to others. More news will be post once I get the page up and the some of the first patch posted.

I'm willing to test builds of QT Mozilla. As is, I'd like to have it working so Phoenix can be ported over to the Sharp Zaurus.

> Take a look at the GTK+v2 work - they are working on it since a year and they > are still not in sync with the GTK+v1 toolkit. This is misleading. I use the Gtk2 build every single day for real work. It has bugs, but it will pass smoketests and it is usable by normal people. It also has multiple people working on it full time and a reasonably strong owner. > I'd like to create a new project based on the gfx/src/qt/ toolkit - "QPrinter" - > a print module based on the libQt QPrinter API for printing (the PostScript > module is mainly dead now but unfortunatley RedHat blocks Xprint which was > targeted as replacement for the PostScript module. Unless RedHat stops their > blockade we may need a 3rd print module which gets accepted by all vendors (the > final QPrinter module will likely not a match for the Xprint module (Xprint is > simply more powerfull than QPrinter :) but at least a far better working > alternative to the PostScript module)). Please take your conspiracy theories somewhere else. Red Hat (two words, not one) does not ship Xprint. Unless something magical happens, we probably won't ever do so. This means that Xprint is not appropriate for the builds for Red Hat Linux. That's it. There is no "blockade." In the long run I'm planning on using Xr for printing support.

> > As I stated above in this bug this procedure failed in the past (where is > gfx/src/nanox/ ?). Why should it work now for the Qt toolkit ? Where is the owner for nonox? Where are the teeming hordes of users screaming for its inclusion? > > BTW: All your argumentation applies to other code like gfx/src/ps/ as well > (which has no maintainer and is half-defunct (print preview only 25% working, > most printer hardware fails to process the generated postscript, etc.). The postscript module isn't perfect and may not have an active maintainer but people (including me and the Sun folks) will fix bugs if they come up. As for the hardware, it works pretty well on Linux where we have ghostscript in the middle. Still, not perfect, but decent.

I have setup a page http://mozilla.org/ports/qtmozilla/index.html. To track tasks and proceed to get that Qt thing working again. Those who are interested in joining let me know and join the mozilla-qt mailing list/newsgroup. If we get the working qt back to working level and with green colors for the smoke tests + continue to maintain it then I don't see why it would be removed. I can take the role and delegate tasks to whoever wanna help. I am no expert in Qt nor can I say that I am an expert at all with Mozilla. Therefore I can't estimate/guess how much time this may take. I just hope that I get something such as a patch out to proove that we're doing something before Blizzard apply his patch to remove qt so to keep the trunk advantage.

Woah, hang on there, it's not my patch. :)

Let's remove that bit of confusion from the topic. Let me also clarify for Peter Ruskin's benefit (or anyone else who buys into this pathetic piece of flamebait), this is not about the "war" between gtk & qt. If the gtk port ever becomes bitrotten to the point where it doesn't compile for months on end and when it does compile, it cannot pass our standard usability tests, then it will be slated for removal as well. When you have a usable port that can pass our smoketests, then talk to me about choice. A non-working port is not a choice. And given that choice works in both directions, we should have choice of not having non-working broken code in our tree. Goehl, not that I really think it'll make a difference either way, but how is your 1.4b deadline any less arbitrary than the previous one? FYI, this "apparent mass" of people offering to contribute to the port happened back in September and November as well. Take a look at the mozilla.builds & mozilla.qt newsgroups. We didn't get working port out of that "apparent mass" so what is going to make this time (another 10 weeks) any different?

Seawood: I did not say 1.4b, Alexander Opitz did. Personally, I dont know if 10 weeks is enough. Let's get a breather for this, as people are indeed coming forward for it, and getting organized was a void at the time of the comment. Since then a page has been setup or revitalized by Yannick Koehler. I am not against its removal from the tree for the time being, or make a branch, whatever. But once it works out, would it be smoothly integrated back in the tree? or the barrier to entry would be very high? as somebody else has said before. I have been following the posts on the newsgroup since September etc, and infact stopped building the tree with gtk since then. Sadly, as a result, I had to resort to pulling nightlies for my daily usage. Infact there was some discussion in Spetmber/November, At that time Esben was doing painful debugging and prior to that even loading was an issue. Ofcourse, you have also read the same. Then, It was individual effort from him and others. If we can get the right people togather this time, then it should work out. Shoot me for being an optimist. I am all for the QT port. You have already made this bug summary change to remove "the get it working again", so I guess, this port does need to go offline.

It seems (to me) that seawood is not willing to even entertain the dialogue to keep it in the tree. There is a lot of interest here, and for people not on the cc: list, to get qtmozilla working. However, with this kind of internal resistance and pushback, it probably won't succeed.

> It seems (to me) that seawood is not willing to even entertain the dialogue to keep it in the tree. It seems to me that people prefer to troll in bugs as opposed to actually contributing code to fix the problems mentioned. > However, with this kind of internal resistance and pushback, it probably won't succeed. Well, if you'd stop talking about what could be done with the port and start coding it, then there'd be no resistance or useless dialogue. FWIW, Yannick claims to have a patch that makes the port truly usable. I'm waiting for him to attach it to some bug so that the results can be publically evaluated.

Well you can throw away that claim. I had MOZILLA_FIVE_HOME set and the mozilla script started my gtk mozilla instead. I do have a patch that make the latest cvs tree compile. The patch was provided by timeless. I have not review the patch myself and timeless told me that it contains stuff that has not been tested yet which are not related to Qt. I will discuss with him today and post it if no issues show up. I have start the qt-mozilla with that patch and I now understand the bug about the menu and stuff. I am working and investigating what cause them and see how I can resolve them. Will post patch for the menu under the appropriate bug thought (I believe one of them is listed inside the "blocks" field. In any case, it seems to me that mozilla.org staff will make the call to keep or remove the port. I'd like to know when it is planned and their decision. But anyway the code will be post once it works can't do much meanwhile.

enough talk. I agree with cls. Yank it. If it gets fixed, we can put it back. in. QA to Yannick since I don't have time to wade through this noise.

mozilla.org made the decision months ago to support cls' call for a credible maintainer and to support his removing the qt from the tree if, in his judgement as the Mozilla build Module Owner, a credible maintainer did not emerge. There is no mozilla.org decision to be made. If cls has decided that it's time for qt to go then that's what will happen.

The patch has been checked in and the files have been removed. Use the QT_LAST_RITES tag to restore your tree to the last known "working" state to continue work on the port.

I must say cls you are an evil man. you come across as arrogant and pushy. there are people here who have offered to mantain the port let them do it. i am willing to test and code where i can. i use the gtk2 builds as there is no qt but would prefer qt. give the choice to develop properly.

Dennis: Please see http://www.mozilla.org/ports/qtmozilla/ . if you want to work on the qt mozilla, get the qt branch and work on it.