Re: [GNOME VFS] gob inside gnome-vfs ...
- From: Alex Graveley <alex ximian com>
- To: Michael Meeks <michael ximian com>
- Cc: Ian McKellar <ian mckellar org>, Seth Nickell <snickell stanford edu>, vfs <gnome-vfs ximian com>, gnome-hackers gnome org
- Subject: Re: [GNOME VFS] gob inside gnome-vfs ...
- Date: 21 Jun 2002 13:53:20 -0400
Hi,
On Fri, 2002-06-21 at 12:13, Michael Meeks wrote:
> Hi Alex,
>
> On Fri, 2002-06-21 at 16:22, Alex Graveley wrote:
> > Internal module usage of other modules is near nil, and there seems to
> > be little shared code between the modules that would be helped by a
> > GObject switch.
>
> The fact that few modules use each other, is not an argument for this
> not happening in future. Also, there are some quite good cleanliness,
> and standardization arguments - if this can all be done with minimal API
> additions etc. That is if GObject instantiation is fast enough - which
> it can probably be made. There's no need to use signals for anything, so
> GObject would just formalize & standarize the existing structure which
> is a great improvement to my mind.
Yes, it is. Modules can already use the public gnome-vfs api to talk to
other modules. GObject-izing is a big chunk of work, won't bring any
cleanliness to existing code, and is going to be the cause for many
subtle races, I suspect.
Besides, 2.x is about user-visible changes. What is user-visible about
this work [1]?
-Alex
[1] Instead, why isn't time being spent on things apps can actually use
to make visible changes... a capabilities api, a metadata api outside of
nautilus, a file searching interface, fixing the http module, cleaning
the existing disgusting code, GThread-izing, security-auditing, *archive
support*, blah blah blah blah... [2]
[2] Forgive the random bitching.
--
"I don't find excessive sanity a virtue."
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]