Re: [g-a-devel] Re: gok broken with new libwnck

On Tue, 22 Feb 2005 16:50:49 +0000, Bill Haneman <Bill Haneman sun com> wrote:
> We still have the problem that we are 6 days from code freeze with a
> change in API which we depend on.  So the solution proposed below
> (re-implementing the libwnck calls) is not a runner for us.

Why?  I can implement the solution for you within a couple hours--at most.

> I still think that keeping the old API around and marking it deprecated
> is a reasonable compromise given the timing of the change.  I don't even
> mind if it's removed post-2.10, if your concern is "encouraging its use"
> for too long.

I know it really sucks to be dependent on an unstable library, but you
did acknowledge yourself that you did so.  Near the top of
gok/gok/gok-windowlister.c is the following few lines of code:
  /* we will need to keep an eye on libwnck */

I know the position you're in sucks, but I'm willing to help you out
with it.  Note that Anders Carlsson changed API in libwnck for
wnck_window_close in an identical fashion *during* the 2.6 stable
series.  Given that kind of precedent, I don't think it's unreasonable
to change API during the unstable series.  Doing so leaves you with
two choices: (a) use the new API and require people using older
versions of libwnck to use corresponding older versions of gok (i.e.
what gnome-panel did and which the developers of an unstable library
expect all users to do), or (b) cut-and-paste two really short
functions that provide the functionality you need.  Requiring
backwards API & ABI compatibility when you have written "#define
WNCK_I_KNOW_THIS_IS_UNSTABLE" in gok/gok/gok-windowlister.c is bound
to cause problems.

> I also think that re-implementing libwnck functionality in multiple
> modules is a clear sign that we need stable API in this area.

Yes, but the right stable API.  ;-)  The reason libwnck is unstable is
because we couldn't yet guarantee stable API/ABI.  I would like to
make it stable too.  But the way to do that is to test things out well
enough that we know what API is right and that we can support.

Hope that helps,

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]