Re: more gnome 2 proposal



> > > 
> > > 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.
> 

Well, autoupdaters are fine, but it still sucks ass for tarballs. 

> I had no idea people were still doing
> that kind of stuff manually. We really need to publicize our
> eazel-hacking package more.

Of course they are still doing this, and shouldn't be crippled/annoyed
because of it.

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

I agree that things that should be split off should be split, but I also
think that some of the 
currently seperate things should be merged. I think getting some of the
gnome-vfs stuff in as well might be nice.
Which I know is set for 2.2 (?) but I still think these should be better
integrated like the original plan was however long
ago was.

I would like that we can be proud of gnome 2.0, without saying "Hold on
till 2.2, look at all the stuff that'll be in it".


> 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.
> 

With it in gnome-libs it will be installed on every system. Therefore
one/two less dependancies for people using obsolete methods
of obtaining software (Downloading tarballs, or RPMs manually!!!!!!!!).
With it still as an optional extra people who want to minimise
their dependancies (remember the whole gtkhtml is evil because it needs
3 extra libraries crap?) will not feel so reluctant to use it.

> And it's the most successful
> component model ever in terms of actual deployment. 

Because you didn't really get a choice if it was installed or not?

> 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.
> 

I think we're misunderstanding each other.
By tightly integrated I mean that gnome-libs depends on it, but it can
still be a seperate thing. Kinda like
libgnome <- libbonobo <- libgnomeui <- libbonoboui (or libbonoboX or
whatever)
Or possibly even libgnome and libbonobo could be merged (although thats
an totally unthought about idea...)

This way, Bonobo gets installed on every gnome system, and we still keep
the seperate packages. If this is what
you were advocating, I apologise for being stupid :)

> 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.

I still think July is too soon. I know we're trying to emulate the KDE
release schedule with a release every 6 months,
but how long did they have between the last 1.x and 2.0? I thought it
was around a year, although I've not found anything
to confirm it.

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


Why, thank you :)
iain


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]