Closed Bug 178987 (moz-Qt) Opened 22 years ago Closed 21 years ago

Remove qt toolkit support from the tree

Categories

(SeaMonkey :: Build Config, defect, P3)

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.4alpha

People

(Reporter: netscape, Assigned: netscape)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.3beta
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 :)
Summary: Remove qt toolkit support from the tree → Remove qt toolkit support from the tree or get it working again
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.

Alias: moz-Qt
*** 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).
Assignee: seawood → timeless
Status: ASSIGNED → NEW
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.
Blocks: qt
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Summary: Remove qt toolkit support from the tree or get it working again → Get qt toolkit working again
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Get qt toolkit working again → Remove qt toolkit support from the tree or get qt toolkit working again
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.
*** Bug 189110 has been marked as a duplicate of this bug. ***
*** Bug 189110 has been marked as a duplicate of this bug. ***
Depends on: 186483
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.


Assignee: timeless → seawood
Status: REOPENED → NEW
Flags: blocking1.3?
Target Milestone: mozilla1.3beta → mozilla1.3final
Attached patch Remove qt from tree — — Splinter Review
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 .
Attachment #107719 - Attachment is obsolete: true
Attachment #114180 - Flags: review?(bryner)
Attachment #114180 - Flags: review?(bryner) → review+
Attachment #114180 - Flags: approval1.3?
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.
Attachment #114180 - Flags: review+
Attachment #114180 - Flags: approval1.3?
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.
Attachment #114180 - Flags: review+
Attachment #114180 - Flags: approval1.3?
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.
Flags: blocking1.3? → blocking1.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.
Flags: blocking1.3- → blocking1.3?
Flags: blocking1.3? → blocking1.3-
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.
Blocks: 193152
> 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?
Summary: Remove qt toolkit support from the tree or get qt toolkit working again → Remove qt toolkit support from the tree
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.
QA Contact: granrose → ykoehler
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.

Status: NEW → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.3final → mozilla1.4alpha
Attachment #114180 - Flags: approval1.3?
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.