Re: Bonobo - storage formats ...

[Havoc Pennington <hp redhat com>]

Jon Trowbridge <trow emccta com> writes:
> 
> As someone who is MSOffice-impaired, I'd be curious to know just how
> they are using components.  Just how fine-grained is the breakdown in
> an app like Word or Excel?  Is this level of granularity one that
> would be good to aim for in GNOME apps?
> 

I have never heard numbers for Word/Excel; also they may have written
bits of those in the pre-components era. The number I've heard for
Internet Explorer is something like 50, that number is probably from
Miguel. Cc'd Blizzard, he can say how many for Mozilla and what
guidelines they use for whether to make an object a component. The
OpenOffice people can probably give an estimate of how many OpenOffice
uses.

The thing is, with COM and XPCOM and C++, using a component instead of
a regular object is almost zero additional overhead, both space and
time wise, and writing a component is also totally trivial (there's
close to zero extra typing involved). So the overhead of a component
vs. a C++ class is negligible, both from a CPU/memory/diskspace
standpoint and a programmer time standpoint. With C#, writing or using
a component is even easier than in C++. Basically any time you would
use a pure virtual interface you can instead use a component.
And once you make something a component, it's automatically available
from any language you want to write code in.

It seems to me that we're only using components significantly to embed
one large app in another as a control, we aren't using nongraphical
components to structure the internals of the application
itself. Signing up to get flamed, I might suggest that this is because
of a qualitative difference in ease-of-use and overhead between COM
and Bonobo, and also because our lack of a cross-language runtime,
language bindings, etc. as found in .NET makes components a good bit
less useful and leaves us stuck in low level C hell for apps that
really should be using Java and Python for much of the higher-level
code, specifically the GUI. Also part of the problem is no doubt the
fact that we don't have a stable release of the entire core component
system (BonoboUnknown, ORBit, and OAF approximately), and we don't
have very good docs on the system as a whole (docs on GtkObject really
upped its usage, for example). So we have a lot of work to do here.

Havoc