[Gtk-sharp-list] Pixbuf API observations.
Miguel de Icaza
19 Feb 2003 00:46:25 -0500
> 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
Yes, a static Subpixbuf method, which makes it obvious what the
operation is. Maybe it is not necessary though.