Re: GNOME & KOM/OP

[Phil Dawes <philipd parallax co uk>]

Stefan Westerfeld wrote:
> 
>    Hi!
> 
> On Fri, Aug 07, 1998 at 04:04:59PM +0100, Phil Dawes wrote:
> > On the other hand we have KOM/OpenParts. This has already been
> > implemented, however AFAIK none of us in the gnome group have used it
> > yet. I would love to read more about it but haven't found anything other
> > than the slides from the kde pages (which don't say much). Stephan,
> > could you please email the group with the URLs of any information you
> > have on KOM/Openparts. (cheers)
> 
> I have found those URLs:
> 
>  - http://www-chaos.umd.edu/~dsweet/KDE/KTrans
>  - http://www.kde.org/whatiskde/openparts.html
>  - http://www.kde.org/whatiskde/koffice.html
> 

Thanks very much for doing that - I hadn't seen the top one.


> Of course, there are currently no "Inside KOM"-Books, as I have not
> seen many "Inside ORBit" books lately. So if you are looking for the
> technical details, you should grab the source and look at the IDL-
> files and the sources ;)
> 

Point taken - I'll grab the files tonight.

> As I already mentioned, KOM is based on CORBA, to be more specific,
> it's using mico. While the implementation is C++ and currently makes
> use of Qt's container classes, this should *not* be a licensing issue.
> 

hmmmm... ;-)


> Harmony has implemented these container classes, so it should be possible
> to build KOM/OP without using Qt. I have not tried that yet, though.
> 
> So the least thing I would expect is to have gOPControlFrame and gOPControl
> widgets for Gnome, to embed your-favourite-OP-control into a Gnome app.
> Having Parts available would be even better.
> 
> Note that this is only one way, so you could use stuff written for KOM/OP
> in Gnome, but not write. So I (and probably others too) would go on
> writing KOM/OP stuff (using Qt or Harmony), not Baboon or something else.
> 
> I'd appreciate of course if compatibility goes even further or the
> problem could be solved really elegant (building Baboon on KOM, or
> even better using KOM/OpenParts as well, and contributing the
> improvements to make it "perfect").
> 



Hokey dokey. 

If KOM is what I think it is (a COM-like layer on top of corba for
inproc objects) then I don't think we'll be using it - I think we can
make the real-time corba spec fit these requirements for inproc
communication.

However, if openparts is as good as people say, which it could very well
be since the author would have had access to the designs of both OLE and
opendoc, then we'll have it!

However, in order for it to be accepted wholesale into the gnome
community it would really need the following characteristics:

1) Written in C.  

I like C++ and use it every day at work, however for the rest of the
gnome community to accept it it really does need to be a C library with
ultra-thin wrappers for other languages. I don't agree with this point
of view wholesale, but I do understand and respect the reasons:

	a) All gnome developers understand C. C++ is a very hard language to
write well in - it's easy to overuse inheritence (and create tightly
coupled systems), and it's very easy to come unstuck with implicit code
generation (constructors, implicit operators). To be a good C++
programmer requires lots of money to be spent on books (effective C++,
stroustrup etc..) and a lot of experience to know what the compiler is
doing for you, especially when using recently implemented features like
exceptions and partial specialization. Unfortunately the majority of
gnome developers don't have either the books or the experience.

	b) Bad C++ code is bloated and difficult to repair. Overuse of
templates, overuse of inheritance (see MFC, Java AWT) and bad design
tends to get out of control very fast. New C++ coders like playing with
features (as I have in the past) and the results are hazardous.

	c) C++ programs tend to be bigger. I know this is in theory a load of
crap (since in C++ you don't pay for the features you don't use), but in
practice it's true (due to bad use of features and naive compiler
implementations of things like exceptions and templates).

	d) C++ programs which overuse features are hard to port. This will get
better as compilers become more standardised, but at the moment it's
certainly the case.

However, if openparts is the best we're gonna get, then I'd be glad to
help port the code to object oriented C. I'm just finishing off a set of
OO C 'wizards' which generate object oriented C skeletons, and a load of
example design patterns implemented in C. The C++ code would then be
just a set of inline wrappers to the C OP kernel.


2) Free of all QT code - it's not standard, and not fair to expect
gnome-only desktops to require it just for a set of collection classes
(which we already have in glib). 

3) Better than OLE, OpenDoc and anything else we can pinch ideas from. I
really hope it is!

BTW thanks very much for your participation in the gnome groups -
without you we probably wouldn't be talking about openparts at all -
Desktop politics eh, don't you just love it!

Cheers,

Phil.

BTW I don't speak with any officiality for the gnome project. I hope my
opinions reflect those of the others involved in development.

-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.