Re: GNOME ABI review

[Havoc Pennington <hp redhat com>]

On Thu, Aug 07, 2003 at 09:49:24AM +0200, Christophe Fergeau wrote: 
> I've been thinking about how the better way to introduce a new mime api,
> and I must admit that I didn't find a really satisfactory way to deal
> with that. A new mime api would involve both cleaning up (or rather
> redesigning) the current C api, and using the freedesktop spec to
> store/retrieve mime type information. 
> So we would have an old mime api, and a new one. If the old mime api
> functions are changed to call the new functions, things will mostly work
> but:
> * the behaviour of the old api will probably change in subtle ways and
> this could bite people using it
> * there are stuff in the old api which doesn't make much sense imo, and
> which I'd like to just drop in the new api
> 
> If the old api code is kept unmodified, there will be two different sets
> of files to store the mime type information, and depending on the api
> used by the app, the user won't see the same mime database, which sucks
> even more than the previous case.
> 
> Any thoughts how this could be handled?

I don't know in detail, jrb might have more insight. I'd expect you
want to introduce the new API in parallel, and then try to keep the 
old API as working as you can without actually changing it in ways
that would break apps...
 
> I don't know what there currently is in libgnomeui, so I won't talk
> about it, but I feel an ui library above GTK+ makes sense for things
> like the gnome-vfs authentication dialogs

It does at the moment, but then GTK+ should require gnome-vfs 
instead of vice-versa; the reason it doesn't is that gnome-vfs 
has a bunch of pretty serious problems. :-/

So this isn't really a long-term reason to have libgnomeui.

There may even be a nicer way to do auth dialogs. Consider this idea:
authentication is cached desktop-wide with a keyring daemon type of
thing; when authentication is needed, the daemon opens the dialog, not
the specific application.  This daemon can also handle IPSEC passwords
and things like that. gnome-vfs simply knows how to talk to the daemon
to get auth taken care of.

> and potentially stuff like gconf-aware widgets.

Same basic issue. GTK should be using the standard prefs system. 

Although, prefs-aware widgets may belong in a standalone "prefs
widgets" library or something anyhow.

> Some HIG ready widgets would also be really helpful..

GTK should simply be made HIG-ready. The easiest way is convenience
constructors, e.g. there's one in bugzilla for the alert windows with
primary/secondary text.

Havoc