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

List:       kde-freeqt
Subject:    Re: [freeqt] Future of Harmony
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       1998-11-23 18:31:23
[Download RAW message or body]

   Hi!

On Mon, Nov 23, 1998 at 04:07:16PM +0100, Stephan Kulow wrote:
> > 
> > Andy Tai wrote:
> > > 
> > > >
> > > > Well, I totally agree with that as a policy; I'd like gtk to speak KDE
> > > > as well as possible so you can produce a KDE app in gtk - perhaps that's
> > > > my next project? ;)
> > > 
> > > If so, that's different from Hayes' vision of "merging into one solution."
> > > There would still be two projects, but they can share more standards and
> > > interoperability.  (That's fine.) But Hayes' original  "resigning" letter is
> > > unjustified because it implies there is no point to work on Gnome and
> > > everyone should switch to KDE instead.
> > > 
> > > The way to go is not to have KDE absorbing GNOME developers, but to have the
> > > two projects be compatiblle in common protocols.
> > > Common protocols also allow the use of different toolkits.  Star Office
> > > supports KDE but it does not use Qt.
> > > 
> > 
> > I'd go even further. It would be nice if some of the libraries can be
> > shared between the two projects. One example would be using Imlib for
> > pixmaps in QT (kind of like Harmony does). Another would be if C++
> > wrappers could be built around Orbit and if Orbit can be made fully
> > CORBA compliant. That way more code could be shared between the two
> > projects and less work replicated between them.
> > 
> If Orbit becomes stable and is better than MICO in more than one
> respect (I know many are talking about C++ bloat and such stuff),
> I see no problem why KDE couldn't adopt it. MICO works fine and 
> works now.

I don't even think it matters in respect to interoperability which ORB
you are using. They are compatible by definition.

The problem is that compatibility breaks when the object models are
different. And thats just what has happened in respect to KOM - Baboon.
These are not doing different things. I also assume that in one year,
(if the current course continues), there won't be a clear winner, but
some things will be nicer in Baboon, some in KOM.

Oh please, there should be at least one or two programmers from the
gnome camp who would be willing to work on a common solution, which
still keeps Koffice (which has been around since long time) alive.

Now that would help interoperability more than wrapping toolkits or
changing ORBs.

I could try to work on KOM to make it happen, but if there is nobody
that will actually work on Baboon, thats pointless.

If a new dimension of Harmony (project) should be there in the future,
this would be an issue to care about (besides for instance writing KDE
apps with non-QT-Toolkits, which could be solved by making the KDE
api available over CORBA rather than C++ objects which derive from Qt).

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

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