[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-qt
Subject:    Re: Question
From:       "John C. Griggs" <jcgriggs () sympatico ! ca>
Date:       2001-06-25 13:35:57
[Download RAW message or body]

dwader wrote:

> Nobody can answer this? What was the goal when Qt-Mozilla was started?
> Or was it just a proof of concept deal?
>
> dwader wrote:
>
> > When the qt port is ready, what will be the advantage over the GTK+ port?
> >
> > Standard disclaimer: not intended as a flame, I'm just curious.
> >

No offense, but I have more important things to do than to justify this port's
existence 8^).

But since you insist:

- Choice is a GOOD thing - the goal is not necessarily to make the Qt port
"better" than the Gtk port.  It is inevitable that each port will have its own
advantages and drawbacks (e.g. right now, the Qt port supports the use of
anti-aliased fonts from XFree's XFT extension - if compiled against Qt 2.3.x)
and having both will offer users, developers and integrators more options when
trying to match Mozilla technology to a given application.  To my mind, this is
one of the major advantages of Open Source development over the
"only-one-can-live", "winner-take-all" situation that has evolved in the world
of proprietary software development.  Of course for this to work, the various
choices offered have to retain a high degree of interoperability and
compatibility (something that is actually discouraged by commercial
development, where deliberate incompatibilities - even between different
versions of the same application - are often used to drive sales.)

- Qt is the native toolkit for KDE, so the Qt port should fit a bit better into
that environment, requiring fewer extra libraries to be installed (and loaded
into memory, when the program runs).  I am also hopeful that, as the Qt port
matures, it will be possible to bridge Mozilla and KDE services at higher
levels within Mozilla (e.g. Mime support, Bookmark management) to better
integrate Mozilla into the desktop.  Using the native toolkit should make this
easier and less susceptible to unnecessary code-bloat.

- I hope that there will eventually be a QtMozEmbed module, analogous to the
GtkMozEmbed module, to allow Qt programmers to use Mozilla technology in their
projects.  Again, I think providing this choice will increase the use of
Mozilla technology in interesting projects.

- Supporting Qt/X11 alows for the possiblity that the base code could be ported
to other "flavours" of the Qt Toolkit - Qt/Embedded and Qt/Windows (and,
hopefully, Qt/Mac sometime in the future).  This in turn allows for an even
more consistent code base for projects designed to be portable across these
platforms - especially if/when a QtMozEmbed component becomes available.

- The Qt toolkit is "pure" C++, whereas GTK+ still has a C Language
underpinning at its lowest layers.  This isn't a big deal to me personally
(remember my Motif background), but is apparently important to some people.
Supporting a "pure" C++ toolkit on Linux/UNIX (and, eventually, on other
platforms) may encourage these people to use Mozilla technology.

I'm sure that there are more good reasons (hey, it's Monday morning and I'm
still on my first coffee 8^), but I think that's a good start.  If anyone else
can think of good reasons why this project should exist, I'd love to hear them
(I need all the encouragement I can get 8^)!!

BTW, I believe the original Qt port, done by TrollTech (developers of the Qt
Toolkit), was a proof-of-concept to demonstrate how easy it was to port a
project like Mozilla to Qt.  Unfortunately, this original code was not kept up
to date and the current Qt port is an almost complete re-write of this work.

I hope this answers your questions.

Regards,
    John Griggs

[prev in list] [next in list] [prev in thread] [next in thread]