On Mon, 2005-05-09 at 23:44 -0400, Owen Taylor wrote:
> I've been struggling for a while with naming issues for GDK/Cairo
> integration. I've had a motley collection of functions:
>
> cairo_t *gdk_drawable_create_cairo_context (GdkDrawable *drawable);
>
> void gdk_pixbuf_set_as_cairo_source (GdkPixbuf *pixbuf,
> cairo_t *cr,
> double pixbuf_x,
> double pixbuf_y);
>
> void gdk_cairo_set_source_color (cairo_t *cr,
> GdkColor *color);
>
> The general attempt is to keep stuff as methods on GDK objects
> for language binding convenience, but that is inconvenient for
> the above and worse for things I'd like to add like:
>
> void gdk_rectangle_add_to_cairo_path (GdkRectangle *rectangle,
> cairo_t *cr);
>
> Not only is it bad in C, but you lose the natural parallelism,
> gdk_rectangle_add_to_cairo_path() is just another form of
> cairo_rectangle (double x, double y, double width, double height);
>
> Tonight I had the idea (Java pseudocode)
>
> public class org.gtk.gdk.Context (org.cairographics.Context) {
> public void Context (Drawable drawable);
>
> public void setSource (Color color);
> public void setSource (Pixbuf pixbuf,
> double pixbuf_x,
> double pixbuf_y);
>
> public void rectangle (Rectangle rectangle);
> }
>
> And in C:
>
> cairo_t *gdk_cairo_create (GdkDrawable *drawable);
>
> void gdk_cairo_set_source_color (cairo_t *cr,
> GdkColor *color);
> void gdk_cairo_set_source_pixbuf (cairo_t *cr,
> GdkPixbuf *pixbuf,
> double pixbuf_x,
> double pixbuf_y);
>
> void gdk_cairo_rectangle (cairo_t *cr,
> GdkRectangle *rectangle);
>
> So, we map convenience functions in C into derivation in an
> object-oriented language. For those not familiar with Cairo
> language bindings, note that cairo_t maps into
>
> Cairo.Context
>
> in language bindings, not Cairo.<oops> or Cairo.Cairo
> I think this works quite nicely for convenience and naturalness
> in both GTK+ and Cairo.
>
> Possible problems:
>
> - Having Cairo.Context, Gdk.Context, and Pango.Context may be
> annoying in some object oriented languages. A saving grace
> for Java is that Pango.Context is fairly rare to manipulate
> directly, and you'll usually use Gdk.Context rather than
> Cairo.Context in a GDK program, so you should only have to
> import one in a source file.
>
> Alternate names I can come up with: Gdk.GdkContext,
> Gdk.CairoContext and Gdk.Cairo all have their own problems.
>
> - Manual intervention will be needed for language bindings ...
> there is no way to derive a GObject from a non-GObject
You can't derive a GObject from a non-GObject even in C. What are you
trying to say here? From your java pseudo-code:
public class org.gtk.gdk.Context (org.cairographics.Context) {
It seems that org.gtk.gdk.Context derives from
org.cairographics.Context, and since org.cairographics.Context is a
cairo_t (not GObject), org.gtk.gdk.Context cannot appear to be derived
from GObject, neither in C nor in language bindings.
> , even
> if I wanted people to write:
>
> gdk_cairo_rectangle (GDK_CONTEXT (cr), rectangle);
>
> - Similarly, things won't be great for introspection; it
> probably will be necessary to present everything as
> standalone functions.
For introspection you could use a different type name and attach
additional methods to such type, even if the corresponding C structure
is the same cairo_t. I don't see the problem.
The only problem is that the additional methods are present in the
cairo_t created by the gtk, while cairo_t created by cairo itself
appears to have less methods, when in reality even the "gtk-enhanced"
cairo context methods are usable in "plain-cairo" contexts. It's a
restriction, but it shouldn't worry programmers too much, I suppose.
>
> - Most or all of the gdk_cairo_* functions actually work fine
> on *any* cairo_t. Though I don't think people will want to
> use them that way very often.
>
> For the functions that are less just convenience it might be
> good to preserve the opposite version -
>
> drawable.createContext (drawable);
>
> as a parallel API, though that adds unpleasant duplication in the
> C API.
Yes, it's unpleasant. Which one is best? I don't know. I'd rather
have ctxt = drawable.createContext () if there can be only one cairo
context per drawable (new invocations return new reference of existing
context), although perhaps with the name getContext instead of
createContext. But if we can have multiple cairo contexts per drawable
(and that works sanely), then I'd rather have ctxt =
gdk.Context(drawable). A matter of taste, I guess..
>
> Anyways, I'd be interested to here reactions about the above proposal,
> especially from language binding authors. I'm pretty happy with it,
> but it clearly diverges a bit from the straight-and-narrow of bindable
> GTK+ APIs.
>
> Thanks,
> Owen
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature