Re: libwnck status & gnome-core
- From: Michael Meeks <michael ximian com>
- To: Havoc Pennington <hp redhat com>
- Cc: gnome-hackers gnome org, Release Team <gnome2-release-team gnome org>, George <jirka 5z com>, Jacob Berkman <jacob ximian com>, Mark McLoughlin <mark skynet ie>
- Subject: Re: libwnck status & gnome-core
- Date: 18 Jan 2002 18:35:30 +0000
Hi Havoc,
On Fri, 2002-01-18 at 17:20, Havoc Pennington wrote:
> We can change it to
> WNCK_I_KNOW_THIS_IS_PRIVATE_AND_HAS_NO_ABI_GUARANTEES which is what
> UNSTABLE means here. It doesn't mean the code is buggy or
> untested. The README is I suppose outdated since it has now been
> tested in gnome-core and certainly works at least as well as
> gnome-core itself. ;-)
:-) 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, don't do that. It's deliberately (on my part) an installed
> library, because for GNOME 1 we had cut-and-pasted the equivalent
> functionality all over creation, because procman wanted to use it, and
> because I want to encourage some experimentation on the pager/tasklist
> front (application-based instead of window-based tasklist/appmenu for
> example would be neat).
Ok - but I have two questions:
a) Do you recommend packagers to package this separately or
included with the packages that use it - with particular
reference to distributions.
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.
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 ?
> The -D is simply to clarify its non-platform API-unfrozen status. I
> think all non-platform libs should consider such a -D to keep users
> from accidentally hosing themselves.
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.
Regards,
Michael.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]