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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list