Re: Outsanding GLib/GTK+ API bugs
- From: Owen Taylor <otaylor redhat com>
- To: <timj redhat com>
- Cc: gtk-devel-list gnome org, gnome-2-0-list gnome org
- Subject: Re: Outsanding GLib/GTK+ API bugs
- Date: 30 Aug 2001 00:47:52 -0400
<timj redhat com> writes:
> some fixups, partly based on results from the last irc meeting:
>
> On 29 Aug 2001, Owen Taylor wrote:
>
> > 59543 Move gbsearcharray to GLib [Owen]
> > Notes: Owen will move to glib, not install header, and fix GTK+
> > to not use gbsearcharray.
> > Puntable: Yes
> > Breakage: No (binary on some platforms)
> > Time:
>
> you should first just send out a patch for the gtk+ changes and post it
> for review.
Done.
> > GObject
> > =======
> > 50877 Rename libgobject to libgruntime??? [X]
> > Notes: Most people would like to stay with GObject. Tim
> > feels strongly that having libgobject and GObject
> > is confusing.
> > Puntable:
> this one is not puntable.
The decision may not be puntable, but the right decision may
well be not to do it at all.
> > Breakage: Yes, lots of fixage.
>
> the breakage here isn't right, it should involve just changing the
> -lgobject arg to glib's .pc files. if more breakage results, that means
> people are including <gobject/*> in the first place which is wrong and
> needs to be fixed.
And rename the pc files, and fix all uses of them, and of AM_* macros,
and fix up glib-gobject.h, and fix spec files, and reanme bugzila
categories, and so forth....
I've done most of the restructuring so far, and "couple of hours"
is a conservative estimate, even not considering breakages downstream
of GTK+. When you start moving things around and renaming things,
it takes a while to catch everything that got missed.
> > Time: Couple hours
>
> probably not, a CVS copy of the directory is required, then cvs remove of the
> gobject/ dir.
> > 55908 Need a function to know if a GBoxed type is reference counte [?]
> > Notes: Consensus was that if you cared for a particular GBoxed type, then
> > the GBoxed should be a GObject. Some open question about whether
> > the is-refcounted parameter to g_boxed_register_static was
> > necessary.
> > Puntable: Yes. Worst that happens it that g_boxed_register_static()
> > is a little more confusing
> > Breakage: Yes, small amount of fixage.
> > Time: 0.5 hours
>
> this one you wanted to find some on to do the is_refcounted argument removal patch.
I wasn't sure here if we had come to a final decision about the
closely related issue of init_func, which if we were changing should
be changed at the same time. I'd have to say it makes me nervous that:
g_value_set_boxed (&value, NULL);
g_assert (g_value_get_boxed (&value) == NULL);
can fail for some boxed types.
If init_func is ever actually used, I think that will could back to
haunt us; and in any case init_func is at best a seldom-useful feature
that I think makes creating your own boxed type a fair bit harder to
figure out.
If we're happy about the status-quo there, then yes, this is just
an easy-to-do mechanical fix at this point.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]