Re: GNOME ABI review

[Christophe Fergeau <teuf gnome org>]

Hi,

> ===
> Third, how would we deploy ABI fixes without breaking the ABI?
> 
> I believe we would do it as follows:
> 
>  - introduce fixed ABIs in parallel, keeping current ABI working
> 

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?

> 5. All UI/widget stuff above GTK+
> 
>  Many, many GNOME developers want to wholesale deprecate the UI stuff
>  above the GTK+ level. This is nearly feasible with GTK+ 2.4, with
>  only session management and possibly the menu system missing.  GTK+
>  2.6 should make it fully feasible.
> 
>  We should not be letting people use something we know we're going to
>  kill off. The flamewar needs to be had and the decision made.

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, and potentially stuff like
gconf-aware widgets. Some HIG ready widgets  would also be really
helpful..


Christophe