Re: About symbols in gtkfilesystem.h

[Owen Taylor <otaylor redhat com>]

On Tue, 2006-02-28 at 13:45 +0200, Tommi Komulainen wrote:
> On Mon, 2006-02-27 at 13:33 +0800, ext James Henstridge wrote:
> > >GtkFileSystem  *_gtk_file_system_create (const char *file_system_name); 
> > >
> > >is not exported. So I cannot really load such a filesystem object in my
> > >program.
> > >
> > >  My question is that is it possible to export _gtk_file_system_create
> > >as semi-private symbol in gtk library??? Or is that any plan to make
> > >this head file more public?
> > >  
> > >
> > Those symbols are not exported because no commitment has been made to
> > keep them stable.  So if they were exported and you used them, your app
> > could break between versions 2.8.5 and 2.8.6, for instance.
> 
> Isn't it enough to have the whole header file guarded with the
> GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED ifdef? Why should
> _gtk_file_system_create() be even more private?

The stuff that is protected with ENABLE_UNSUPPORTED is meant for 
people implementing file systems ... which is the point of exporting
that header file semi-publically. _gtk_file_system_create() isn't
needed for that, so it's fully private.

> (In maemo we're exporting that symbol as hildon_gtk_file_system_create()
> since we need it in hildon-fm...)
> 
> There are other symbols intended for derived widgets to use, protected
> methods you could say, but as they're not exported you're confined to
> gtk only.

In the early days of GTK+ we were very relaxed about what we exported -
you could take just about any bit of GTK+ code inside GTK+ and compile
it outside of GTK+. That was great for writing add-on widgets, but a
horror for trying to maintain compatibility. "Protected" is
a bit of a crock, since protected interfaces are interfaces too and
need the same stability guarantees and careful design as public
interfaces.

Nowdays we tend to make things private by default and export them
only as we have use cases and requests to do so. Often publicly
exporting a private interface requires re-evaluating it and 
cleaning it up in significant ways.

There are a couple of concerns in particular about promoting 
GtkFileSystem to a publically exported interface.

 - We know that the problem domain of "virtual file systems" is big
   and hard. GtkFileSystem is kept manageable by defining it as
   *exactly* what the file chooser needs. If GtkFileSystem were
   public, then it would be very hard to know on what grounds to accept
   or reject RFE's until it became a gnome-vfs clone. And GtkFileSystem
   isn't not designed how I'd design a VFS for general consumption.

 - We still (two years later) aren't quite satisfied with how
   GtkFileSystem ... see Kris's outstanding changes.

> Interestingly enough I just noticed none of the private _gtk_* symbols
> have 'visibility("hidden")' attribute. Is libtool really doing to right
> thing here, or should the private symbols be hidden properly?

Look a bit closer and you'll find extreme complexity. (We used to rely
on libtool doing the right thing, and with some coaxing, patches
submitted upstream, and so forth, it did, but there's a lot more going
on these days.)
				
						Owen