Re: Status of 2.0 API freeze bugs



On 3 Apr 2001, Owen Taylor wrote:

> 50205	gobject	glib	GCallback should not be a void pointer 
> 
>  Needs to be done.

fixed. 

> 50215	gobject glib	g_param_spec_string_c is a very cryptic function name 
>  
>  Simple rename to g_param_spec_identifier or removal.

make a call here, just consider GTK_TYPE_IDENTIFIER namingspace wise.

> 51746	gtk	gtk+	Notification of shadowing by gtk_grab_add 
> 
>  patch from otaylor exists, probably should just be applied.

sorry, haven't had time for a thorough review yet.

> Do after 2.0
> ============
> 
> 50080	gdk-pix	gtk+	gdk_pixbuf_get_from_drawable() is hosed 
> 
>  There are serious implementation bugs here that need to be fixed post API
>  freeze, but I think the API additions here can be punted.

the API additions here should go in:
- deskguide already contains the neccessary code
- serious uses require a full fledged API
- once you start fixing the code, adding the extra args is half an hour work
- i want to get rid of the code duplication in deskguide and avoid people
  doing the same thing (i.e. borrowing gtk code just to add extra features,
  or copying from deskguide)

> 50972	gobject	glib	g_enum_get_value_name() 
>  
>  A lot of disagreement about how to do this

the disagreement is more on a new general memory management scheme,
rather than enum/value_contents focussed. we should sit down at
GUADEC for this and see whether we can come up with something that we
all agree on and is suitable beyond this single function.

> 50980	gdk-pb	gtk+	revamp inlined pixbuf code 
> 
> 51731	gtk 	gtk+	Add an INACTIVE state 
> 51747	gtk	gtk+	Rethink GtkStateType 
> 
>  Sigh. Too much work to get done at this point. A GTK+-3.0 thing,
>  probably.

the inlined pixbuf thing should be in 2.0:
- the API is new, we should make our best effords to ship a good API
  and implementation in the first place
- i don't think huge API changes are involved, and the backend code
  for the revamp is already available in gimp's CSource plugin

i actuall plan to spend a day on this after guadec, it'S really not that hard.

on the INACTIVE state, i _strongly_ would have liked that to go in. if we
really won't have that for 2.0, we should at least add GTK_N_STATES=5 and
go over all gtk code to fix inlined 5s (what's the english plural of
a number? ;) and deprecate code that relies on 5 states, rather than
using GTK_N_STATES.

> 52574	gtk	gtk+	geometry parsing 
> 
>  Can be added compatibly in the future.

heck, you remember that this is a pre-1.2 todo item, right? ;)


i'd like you commenting on my API todos i posted recently.


---
ciaoTJ





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