glib in kdesupport: yes or no?
hp at redhat.com
Mon Mar 10 05:12:12 GMT 2003
On Sun, Mar 09, 2003 at 06:34:02PM -0500, Adam Treat wrote:
> On Sunday 09 March 2003 11:02 pm, Havoc Pennington wrote:
> > My feeling is that Qt would be fine in anything that is a separate
> > process. I don't think GNOME would be willing to accept GPL libraries
> > into a piece of platform all apps had to link to, though.
> Why? GNOME is a GNU project after all and the stated policy of the GNU
> project *prefers* GPL'd libraries. When you say that GNOME would not be
> willing then could you please explain how GNOME makes these decisions? It
> seems to me if GNOME wishes to share common infrastructure then they will
> have to get over the issue OR KDE will have to move away from using Qt for
> some very core parts.
Some core, but relatively small/isolated parts.
The GNU project was involved in the decision to LGPL the GNOME
libraries, and agreed with the rationale for doing so. Which is
essentially that it promotes adoption of the software.
GNOME made this decision historically basically the same way any free
software project makes a big decision - in fun threads like this
I'm not speaking for GNOME; I don't know whether it would change its
mind. However the way I approach getting interoperability work done is
that I just assume no one is going to change their fundamental goals
or big-picture views on what we need to do to succeed, but that people
are probably willing to make relatively easy compromises in order to
achieve the benefits of interoperability.
Because I think most of those benefits can be gained (and are being
gained - we have plenty of successes already) with relatively easy
compromises, I think we can solve the problems.
> Hey, I think common specs are fine as long as the spec is good. We will
> probably still run into some fundamental differences though. However, I
> don't think you should play down the implementation details. Can you even
> tell us if you guys are willing to use C++ for any of this?
Yes, I forgot to mention; GNOME already has a C++ dependency via FAM,
if nothing else. I don't think it's a problem to use C++, though I'm
sure there would be some discussion, I doubt anyone cares as long as
the code is maintained.
> The stuff on your list that is not specs: config, sound system,
> component/runtime, VFS and KIO are not trivial pieces. I don't want
> KDE to abandon a successful strategy where we use Qt as an
> underlying basis.
Note that my list is mostly the hardest stuff; the easy things are
already in-progress or done and just need maintenance over time.
More information about the kde-core-devel