Re: Those durn open API bugs

[Owen Taylor <otaylor redhat com>]

[ Most of the responses separated out, since I don't think it makes sense to
  discuss a dozen separate issues in a single thread ]

Tim Janik <timj gtk org> writes:

> > Misc GLib
> > =========
> > 57663  g_strsplit on empty string gives non-empty string vector [*]
> >   Notes: Just have to figure out exactly what it should do.   
> >   Puntable:
> >   Breakage: Yes.
> >   Time: 10 minutes
> 
> i didn't really follow this, but the fuction was intended to
> (say i split on ':'):
> 
> string		vector
> NULL		-> NULL
> ""		-> ( "" )
> "foo:bar"	-> ( "foo", "bar" )
> ":baz:"		-> ( "", "baz", "" )
> 
> isn't it working that way?

NULL has always been an error, and NULL => () wouldn't be particularly
useful because NULL isn't a string that you'd read out of a file....
Before this patch we had "" => ("") in HEAD, but GTK+-1.2 had "" =>
(), and changing that breaks a lot of stuff; also, a representation
for () is more important than (""). See the mail I sent out earlier
this week for a full description. This patch is applied now.
 
> > 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: 
> >   Breakage: Yes, lots of fixage.
> >   Time:     Couple hours
> 
> the breakage here isn't that huge of a deal, since nobody
> should actually include <gobject/*> except for some very
> rare cases, where <gobject/gobjectnotifyqueue.c> or
> <gobject/gvaluecollector.h> are required, and sed will
> do the work for us here.

Well, and just a few not not-so-rare cases where people include
glib-object.h, and refer to gobject-2.0.pc.in, and so forth.
It's a big change, and I think in a lot of people's opinions,
not one for the better.

> you left out two important things related to this:

You mean, you are suggesting two more additions :-) [ we did, after all, agree 
on the contents of this list at one point ]

> 1) gbsearcharray.[hc] should prolly be moved into glib/glib/
> 2) gmain.[hc] either need to move into glib/gobject/, or gmain.h
>    provides the necessary hooks to implement g_source_set_closure()
>    in glib/gobject/ (dunno if anything is required that is not public
>    gmain.h API).

OK, I've filed bugs for both. (#59543, #59544)

> > 51063  Weak references [Tim]
> >   Notes:    Remaining issue is last-unref notification, if we want
> >             that. A bad idea, but sometimes useful anyways.
> >   Puntable: No
> >   Breakage: ?
> >   Time:     ?
> 
> hm. i'd say this one is puntable, since providing hooks for last_unref
> notification can still be added post-2.0. the prime matter here is, if
> such a thing is really necessary. if people could bring up relevant
> usage cases, that might help us in deciding whether we want to provide
> such an API and what the desired semantics should be. i'm not currently
> opposed to or in favour of this, i just think this issue requires more
> detailed investigation.

I won't object to punting. The more things we can punt at this point the
better. I've closed the bug in bugzilla.
 
> > 50206  Some GObject methods take a gpointer [X]
> >   Notes:    Tim will review last mail I sent on subject and make final 
> >             decisions.
> >   Puntable: 
> >   Breakage: Some extra casts needed if done
> >   Time:      
> 
> hm, i once already went over functions here that we had adressed in
> an earlier irc meeting. maybe i left out some cases, please resent
> your email if you feel further changes are required.

Relevant mail (http://mail.gnome.org/archives/gtk-devel-list/2001-June/msg00099.html)
forwarded to you privately. (probably best if you respond on gtk-devel-list)
 
> > 59027 shadow vs. shadow_type properties [*]
> >   Notes: Question here is how to handle deprecated properties ... 
> >   Puntable:
> >   Breakage:   
> >   Time: 5 minutes
> 
> if we agree on what the canonical property name is here, i can handle
> the deprecation issue.

The canonical name is clearly "shadow_type" by 7 to 2. How would you
handle deprecation?
 
> > Resolved 5/25 - 5/29
> > ====================
> 
> > 50080  gdk_pixbuf_get_from_drawable() is hosed [P,Havoc]
> 
> how was that resolved? i never saw the final API for this.

GdkPixbuf *gdk_pixbuf_get_from_image    (GdkPixbuf   *dest,
                                         GdkImage    *src,
                                         GdkColormap *cmap,
                                         int          src_x,
                                         int          src_y,
                                         int          dest_x,
                                         int          dest_y,
                                         int          width,
                                         int          height);

Was added. Basically, the decision was to make the current API
work reliably, and to expose this so people didn't have to replicate
all the screen=>pixbuf code, but not to attempt to handle everything
that the desk-guide needs, because that's pretty darn specialized.

Regards,
                                        Owen