Re: libwnck status & gnome-core

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes: 
> 	:-) well - sure, but gnome-core to some extent is application code and
> not installing headers - and where it has done has had a fairly good go
> at keeping them compatible [AFAIK]. Is this the case for libwnk? - given
> that I just updated it and the API was source incompatible - and the
> library version is not bumped off 0.1 to check this in gnome-core's
> configure - it seems unlikely.

No, libwnck has no compat guarantees. It is AFAIK like GtkHTML2 or GAL
in that respect. However we do need to be sure procman and gnome-core
and other components still build (and fix them as required) anytime
the API is broken. I'm only going to care about stuff on the module
list at developer.gnome.org/dotplan/modules for this.
 
> 	a) Do you recommend packagers to package this separately or
> 	   included with the packages that use it - with particular
> 	   reference to distributions.

I am probably going to package it separately, because it simplifies
package maintenance, and avoids a procman->gnome-core dependency.

> 	b) When/if will the API stop changing / breaking - and/or what
> 	   scope do you anticipate for the library - eg. just procman
> 	   and gnome-core? or more things.

I intend only desktop bits to use it, though if someone else wants to
use it I can't stop them obviously (I just want them to
-DSCREW_ME_PLEASE so they know what they are getting into).

> 	c) If the scope is limited, and given that it isn't much code:
> 	   ~3000 lines, does not including it within these 2 modules
> 	   make sane packaging easier, and help ensure use doesn't
> 	   spread to places we don't expect ?

I think splitting it out makes maintenance/packaging simpler, yes.

I don't think putting it in gnome-core really affects whether it's
used, if we still install headers, which we would need to do for
procman.

I don't consider it a huge problem if people use it, as long as they
understand its status and are not expecting it to be a fixed
API/ABI. (As I said I actually want to encourage people to fool around
with application-based or other funky desktop navigation gizmos.)
Thus the -D requirement so you are forced to read the little #error
before you get much code written.
 
> 	Well - whatever, I'm not particularly eager to do the work - but it
> would be nice if when the API changes and gnome-core is updated that the
> configure version could be bumped and checks kept in sync - if that's
> possible.

Sure I don't have a problem with that. This should at least happen
when we make tarballs, traditionally we haven't bumped soname on each
CVS commit however.

Havoc