Re: GNOME & KOM/OP

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Thu, Aug 06, 1998 at 02:16:11PM -0500, Miguel de Icaza wrote:
> 
> > I can't see why not for technical reasons. It would be a shame if we 
> > ended up with two different, incompatible object component models on 
> > the same desktop.
> > 
> > Or is there some _technical_ reason why this would be impractical? 
> 
> Yes.  KOM is just a hack to get a document model (OpenParts) to work.
> 
> We are doing it correctly :-)

If there are design flaws, couldn't then KOM be changed, while still
maintaining a way to use it for the existing application like KOffice?
It's open source after all.

Another way would be - if there are too wide gaps, to restart from scratch,
while ensuring that reasonable bindings to Qt & KDE exist from the
beginning. Then there should be active cooperation, to ensure, that
the KOffice developers will actually switch to the GNU Object Model
as soon as possible.


I don't see another way here than active future planning. I can tell you
how the story will continue if we don't fix this now:

KDE will expand it's KOffice functionality on top of KOM/OP, and start
integrating KOM (and it's OPControls) in other programs like KPanel,
KFM, ...

Gnome will in some months have a usable component model (Gtk+ only, and
no active C++ support). Then - by the end of 1998, the great GOffice is
started, a thing like KOffice, just on top of the GNU Component Model.

The GNU Component Model will not support KDE/Qt (the license is not
acceptable), and the KDE developers see no reason to switch from KOM,
since this is easy to use with C++ and well integrated in all KDE apps.
Perhaps most of the serious design flaws of KOM will be fixed by the
end of 1998 as well.

Eventually, some day harmony will be finished, but it will be useless,
because KDE and Gnome applications are not interoperable anyway, and
will never be.


And me? I am just trying to develop a synthesizer for linux. Not only
that I have to think about two desktops. I practically can implement
all visual elements twice, once for Gtk+ and once for Qt, since the
desktop models disallow other toolkits. And all plugins for the
synthesizer have to do the same.

Or I have to implement my own object model, which can from the beginning
run onto the GNU Object Model, and the KDE Object Model.

And my synthesizer has to use two entierly different APIs for about
everything, from configuration to virtual filesystem.


And the Gimp? Lyx? All other applications?

Please - the purpose of a desktop is to HELP the application programmer
and the user. I laugh about a war between emacs and vi, because it does
no harm. But if virtually _all_ work has to be done twice, and _every_
application has to be written twice, then it's not funny any more.

I would be able to spend some time making this less painfull for everybody,
for instance merging the different VFS implementations. But if all I hear
is we do it better than them, so join us and forget them, there is no way.


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