Re: more gnome 2 proposal

[Maciej Stachowiak <mjs eazel com>]

Iain <tigermilk btinternet com> writes:

> (I hate things like this, well, I hate participating in them, because I
> don't have much to say, but I don't want
> to be left out, cos then I don't really have any reason to complain or
> say something in hindsight....or something like that.
> Maybe it's just Sunday afternoon,looking for a decent sampler boredom)
> 
> > 
> > Also, I would point out:
> >  - most people use packages
> 
> And so don't care about how big the packages are,
> just how many of them they have to download.
> 

Most people don't manually download a bunch of individual
packages. They either get the packages from their O/S distribution CD,
or via an auto-updater like ximian-update or Red Carpet or
up2date. With an updater, many small packages definitely give a better
user experience than a single big one. It's better for the first
install, because users get more of an idea of what's going on their
system. And it's definitely better for subsequent updates because they
only need to update the packages that actually have changes and the
parts that they care about, not some huge monolithic thing.

> There is a feeling already that to have a workable GNOME system you
> need to download about 20 packages, whereas with KDE it's a simple
> case of some big ones (from what I've read, I've not downloaded it
> myself).  And although most of this feeling is from the /. peanut
> gallery, I don't think you can dismiss them as easily as that.
> Well, not this time.

Honestly, I have not heard this much since auto-updaters became prevalent. 

> 
> And that things have to be updated seperately.
> As an example, 
> evolution:> ./configure
> *Configure failed, need new Bonobo*
> 
> Update Bonobo
> bonobo:> ./configure
> *Configure failed, need new Oaf*
> 
> *sigh*
> Update oaf
> oaf:> ./configure
> Wheeeee
> 
> bonobo:> ./configure
> *Configure failed: Need new GNOME-libs*
> ETC.
> 

This is a lot less likely to keep happening once GNOME 1.4 ships and
backwards compatibility is strictly required. Also, I never have this
problem, I just type `rebuild'. I had no idea people were still doing
that kind of stuff manually. We really need to publicize our
eazel-hacking package more.

> While I don't think one monolithic package is the right way, I also
> don't think splitting everything is the right way either.
> I would be happy to split gnome-libs into the libgnome, libgnomeui idea,
> libgnomecanvas, libzvt (it doesn't have dependancies on libgnomeui
> anyway does it?).

It sounds like you agree with a serious chunk of the splitting plan.

> I think Bonobo should be integrated as fully as we can, and
> personally, I don't care if that takes longer than we have till some
> July freeze, sod it. Bonobo is possibly the most important thing in
> GNOME and waiting until December 2002 before we have it fully
> integrated is just silly.

I agree with you we ought to have bonobo more widely deployed. In
fact, because of this and other work items, I initially thought we
shouldn't even try to ship this calendar year. But smart folks like
John Heard and Havoc and Jim Gettys convinced me that shipping
regularly is more important than any one feature.

But I'd also like to point out that specifically using bonobo features
inside gnome-libs, or integrating bonobo with gnome-libs itself, is
not likely to be the single greatest factor in spreading use of
Bonobo. Nautilus uses it fine, Evolution uses it fine, Gnumeric has a
port that works fine; I don't see how they'd hugely benefit from
libbonobo and libgnomeui being merged.

And finally, I'd like to point out that in Microsoft-land, COM is
separated from the other APIs - separate namesapce (Co), separate
DLLs, seaprate options in the IDE. And it's the most successful
component model ever in terms of actual deployment. But because
Microsoft kept it separated, they can now push their new component
model, the .NET shared runtime, and not have to carry along all the
baggage of COM for apps that use .NET. 

It's also worth pointing out that many people refused to use COM for a
lot of things when the primary easy API for using it was part of MFC -
they felt that a large general-purpose application framework library
like MFC was way too heavyweight to use in really simple
components. This is why ATL, a simple, lightweight library that
provided thin but easy wrappers for COM and only COM helped push the
success of COM so much further - suddenly it became

So I actually think Bonobo is far better off staying a separate
library if we want it to succeed and be wildly successful. There will
be places where bonobo is appropriate, and gnome-libs is not.

But this whole argument notwithstanding, tight integration work could
not possibly be done by the July freeze, and our proposal was written
with that in mind. If we are ready to throw out the goal of shipping
this calendar year (something that will make it harder for our new
friends at Sun and HP to fully adopt GNOME, and delay getting topnotch
internationalization and sane XRender support out for instance), then
we can go back to the drawing board and come up with different plans.

> So thats what I think, although I don't think I've added anything
> special...

I think you made some good points though I don't necessarily agree
with all of them.

 - Maciej