[Gtk-sharp-list] My Very Own Wish List for Gtk#

Mike Kestner mkestner@ximian.com
08 Oct 2002 00:49:57 -0500

On Thu, 2002-10-03 at 23:35, Miguel de Icaza wrote:

> 	* Custom written ToString () methods for various classes to
> 	  represent interesting data types and generate useful
> 	  information.  Someone provided already some patches,
> 	  and I was lame enough not to commit them ;-)

If someone can locate the patches in the archives and open a bug with
links to them, they'll be more likely to get applied.

> 	* Color integration.  Every place where Gtk takes a color,
> 	  have an overloaded function that would take a
> 	  System.Drawing.Color, because there are plenty of useful
> 	  constants there that could be used.

A bug report would help make sure this doesn't get lost. I'd like to
automatically generate all Color, Point, Rectangle, etc... parameters to
expose System.Drawing types instead of Gdk types. So we're in agreement,
except for the "overloaded" part.

> 	* Documentation wise: currently the generator sticks some
> 	  /// <summary> tags all over the place.  In Mono we are 
> 	  going to use a different scheme for documenting APIs, 
> 	  so I would personally like those removed ;-)
> 	  And probably in the future we can have gtk-doc just
> 	  spit out the stuff that Mono Doc would use.

There's already a bug relating to automatic doc generation. Right now
the plan is to generate inline docs, but since Rachel has taken the most
interest in that, I'll let her comment on this if she likes.

> 	* Extra unrefs.  I discussed this shortly today with Rachel,
> 	  it is a bit hard to pin point which objects needs to have
> 	  their reference count returns flagged for fixing, as the
> 	  error does not always happen when the unref happens, but
> 	  sometime later, due to some other widget keeping a reference.
> 	  What we might want to have in the meantime is some debug
> 	  mode for a function called `my_object_unref', that would
> 	  poke into the GObject internal and reduce the refcount, but
> 	  not free the structure.

What we need is a deterministic method for detecting owned/unowned refs
in the entire gtk API.  Otherwise this will be a perpetual PITA. I
believe that Rachel had a conversation with Owen about this a while back
which boiled down to, "Nope, we're screwed." 

> 	  If my_object_unref ever runs into something that has a
> 	  refcount of zero, it could report a nice error, and maybe
> 	  even throw a handy exception that is later wrapped and
> 	  printed out.

I don't think this buys us anything. You still don't know which method
returned the ref that we don't own. Perhaps we need to start a dialog
with jamesh and owen about ref ownership.

> 	  Currently am running my gtk# without unrefs, because it
> 	  crashes the debugger.  I know, I know ;-)

Since you are the one that asked for Dispose, I guess this stuff isn't
going to get much attention if you've disabled it.  ;-)

> 	* text/length methods in gtk, like:

Also has an existing bug to track it.
Mike Kestner <mkestner@ximian.com>