[Gtk-sharp-list] Pixbuf API observations.

[Mike Kestner]

On Mon, 2003-02-17 at 19:41, Miguel de Icaza wrote:

>     I can fill bugs if people think it is appropriate once I get a
> go/no-go on the following changes:
> 
> * Problems
> 
> 	* Constructor based on: gdk_pixbuf_new_from_data
> 	  	The first argument should be a "byte *data", but instead
> 	 	the generator picks `byte data'.
> 
> 	* Constructor based on gdk_pixbuf_new_from_inline
> 		The first argument should be a "byte *data", but instead
> 	 	the geneator picks "byte data".
> 
> 	* Pixels property return value.
> 		The return value for this is `byte' instead of `byte *'

More examples of the infamous "pointer to simple type" bug.  I will get
around to fixing that some day.  Until then, feel free to overload the
methods in .custom files, like the dozens of other such cases.  Putting
a note on the bug would be good too so we can make sure its fix works
everywhere and can remove the hand customizations.

> 	* GdkRGB seems to be missing from the generated bindings.

Yep, since there's no Gdk.RGB type, there's nothing to assign the
methods to.  The parser is typedef driven, and we don't currently
include any methods not directly attributable to a type.  GdkRGB looks
like a candidate for a non-instantiable class with static methods.  I
suppose a bug report would be good to see that the parser handles this
case eventually.

> * Handling failure in constructors
> 
> 	* A few C constructors return null, should we probe for this,
> 	  and throw a no-memory exception in those cases? 

Well, technically any ctor could return NULL, so we should probably be
guarding all PInvoked ctors with a similar check.  The only question is
what exception to throw. Maybe a GLibSharp.ObjectConstructionException
or something like that. 10 minute hack to generator/Ctor.cs.

> * API Improvements.
> 
> 	* GetFromImage and GetFromDrawable both allow the first argument
> 	  to be NULL (ie, they are really factories for Pixbufs, but
> 	  we are exposing them as instance methods).
> 
> 	  If nobody minds, I can add the .custom changes to have Factory
> 	  versions of them.  The only problem is that the API would be
> 	  the same between instance and static versions of the method. 
> 	  So maybe they will need new names.
> 
> 	  I can do this if Mike does not mind.

Not at all. Please do.  :)

> 
> 	* Pixbuf.Copy should probably be Pixbuf.Clone, and we could have
> 	  Pixbuf implement the IClonable interface.

I'd leave Copy alone and have Clone call it.

> 	* Overloads for methods taking color argumnets.
> 
> 	  Currently colors are specified with uint32 colors in a few
> 	  places.  We could make the API more C#-ish, if we used the
> 	  System.Drawing Colors as arguments.  We could have overloads
> 	  for this.

Another good customization.

> * Wish items:
> 
> 	I can do this if Mike does not mind:
> 
> 	Constructor based on gdk_pixbuf_new_subpixbuf 
> 		Currently the API requires a Pixbuf to be
> 		created first, and then this function can be invoked.
> 
> 		It is not entirely obvious, I would like to have
> 		a Subpixbuf method that would achieve the same.

Not exactly sure what you're getting at here.  A static Subpixbuf
method?

Feel free to open bugs, send patches, etc for any/all of the above.

Thanks for the nice analysis of Gdk.Pixbuf.  :)

-- 
Mike Kestner <mkestner@speakeasy.net>