Re: Those durn open API bugs

[Tim Janik <timj gtk org>]

On 22 Aug 2001, Owen Taylor wrote:

> Here's the remaining open API bugs, that we need to resolve in some
> fashion before freezing the API
>  
>  P: We have code for this bug
>  X: There is disgreement over what to do for this bug
>  ?: This bug may be either a non-bug or something we'll can/need-to punt
>  *: New bug since last status report 
> 
> Names indicate people who "own" or are working on the particular bug.
> 
> Query with all these bugs is:
> 
>  http://bugzilla.gnome.org/buglist.cgi?product=glib&product=gtk%2B&product=gtk-engines&product=pango&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=1.0+API+freeze&target_milestone=2.0+API+freeze
> 
> Fields are:
> 
>  Notes: 
>  Puntable: Guess as to how badly it would hurt to not do it for 2.0.
>  Breakage: Affect of changes on people downstream
>  Time:     Time guesstimate.
> 
> 
> 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?

> 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.
you left out two important things related to this:
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).

> 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

the point in is_refcounted here is really to work around users erroneously
specifying G_SIGNAL_TYPE_STATIC_SCOPE for ref counted boxed types.
G_SIGNAL_TYPE_STATIC_SCOPE only makes sense for value-copied boxed types,
for refcounted boxed types it just defeats object consistency prevention
during signal emission. i basically see two ways of handling this:
1) get rid of gboolean is_refcounted in g_boxed_type_register_static() and
   hope all the best for signal creators to not screw the system
2) leave it as it is, but actually use the flag to puke on the user
   if he abuses G_SIGNAL_TYPE_STATIC_SCOPE as described above (currently
   we're silent which doesn't make too much sense)
this issue is not puntable however, since deciding to get rid of
gboolean is_refcounted affects public API and would impose huge breakage
in 2.2.


for another boxed issue, are there any opinions on:
  Date: Tue, 14 Aug 2001 11:07:14 +0200 (CEST)
  From: Tim Janik <timj gtk org>
  To: Gtk+ Developers <gtk-devel-list gnome org>
  Subject: Questioning non-NULL boxed types
if not, i'll make a final decision soon and apply changes if necessary.


> 50212  Copying param information is not necessary [X]
>   Notes:    Alex is looking into quantifying the wastage here.
>   Puntable: 
>   Breakage: Theoretical, probably not actual.
>   Time:     5 minutes + time to decide

the time estimated here is a gross misguess. issues involved:
1) API consistency, we don't take over user strings anywhere in
   our API without loud flagging of doing so, examples:
   g_quark_from_static_string(),
   g_value_set_string_take_ownership()
   so if we change current matters at all we basically have two options:
   - we silently assume that the strings passed into current API are
     static and don't duplicate them. this will raise millions of
     questions on why we don't do the same in other possible places.
     i.e. special flagging mentioned above (g_querk_from_static_string())
     becomes pointless, and duplicating strings passed in to
     gtk_type_unique(), g_type_register_static() or
     g_type_register_dynamic() also becomes pointless.
     especially the latter one will be an issue however, since frequently
     the string passed in to g_type_register_dynamic() will come from
     unloadable data sections.
   - we flag g_param_spec_int() and friends as in other API, this will
     produce monsters of function names however, e.g.:
     g_param_spec_int_static_strings()
     these could at least be provided in parallel to existing API
     g_param_spec_int() so change can occour gradually.
2) taking over static strings silently would be a major convention
   change, i don't apprechiate the idea for two reasons:
   - we're a little late in the game to say "suddenly we will assume
     strings you passed in to our functions remain valid". i.e. to
     break established conventions in such a major way
   - we already have means to handle taking over static strings, that
     of special name flagging of such function, so there's no actual
     need to break with established conventions and ruin API
     consistency once more
3) the breakage involved won't be huge for gtk proper i assume, but i
   guess there's a bunch of (plugin) code in beast that'll have to
   change if we broke semantics of currently existing functions

> 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.

> 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.

> Misc GTK+
> =========
> 53151  gtk_window_set_size(), gtk_window_set_location()
>   Notes:    API agreed upon now, patch exists
>   Puntable: No
>   Breakage: Some functions will be deprecated
>   Time:     ?

i think this one needs updating, we applied havoc's changes that resulted
from a prior irc meeting where we had consensus. or is there another patch
pending against current CVS that i missed?

> 56916 GtkModule fixes
>   Notes:    Tim should look at what I put in the bug description.
>             Seems to barely count as API issues.
>   Puntable: 
>   Breakage: Some
>   Time:     1 hour

this is really a small issue. all that's involved is someone implementing
code and Makefile.am stubs to:
- let gtk figure a gtk-specific directory in configure.in into which
  custom modules can install themselves
- search that gtk-specific module directory for modules passed in through
  GTK_MODULES= in gtk_main()
- put GtkModuleDir=... into gtk-2.0.pc
- implement means in pkg-config so custom module installers can do
  pkg-config --get-variable=GtkModuleDir gtk-2.0
  (or maybe pkg-config has such a thing already, dunno)

> 56917 Add corner widget to GtkScrolledWindow
>   Notes:    May be various issues with key navigation, theming
>             etc. Seems late to put in this kind of UI addition.
>   Puntable: Yes
>   Breakage: Possible binary incompat
>   Time:     ? 

i sent an email out on this and saw no replies about key navigation
or themeing issues, which as i mentioned in my email btw, will not
impose any problems. so is there actually anything pending that prevents
me from comitting the code?

> 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.

> 59032 activatable cell renderers API [*]
>   Notes:    
>   Puntable:
>   Breakage:   
>   Time:    

is this the ::can_activate vs. ::activatable issue i brought up?

> 59173 GtkTreeView code should use GtkSortType instead of GtkTreeSortOrder [*]
>   Notes:    
>   Puntable:
>   Breakage:   
>   Time:    

what about the GtkTreeSelectionMode vs. GtkSelectionMode issue i
also brought up?

> 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.

---
ciaoTJ