[Gtk-sharp-list] Pixbuf API observations.

[Miguel de Icaza]

Hello,

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

Thanks for the information.  I have added a couple of new .custom
constructors, and updated the docs.

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

Well, I am not sure it is worth the pain to implement, but it would be
good to have its methods exposed.  I will file a bug to have a ".custom"
or some file to include it.


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

I think that we should only do this for constructors that have a high
degree of probability in failing.   For example, a couple of the Pixbuf
ones might fail due to memory requirements.

> > 	* 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.  :)

I created and documented a new method CreateFromDrawable.

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

I implemented and documented, but how do I make the Pixbuf class list
"ICloneable" as an interface it implements?


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

Perfect!  Just added two method overloads, and documented them.

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

Yes, a static Subpixbuf method, which makes it obvious what the
operation is.  Maybe it is not necessary though.

Miguel