On Tue, 2005-05-10 at 18:39 +0100, Gustavo J. A. M. Carneiro wrote:
> On Mon, 2005-05-09 at 23:44 -0400, Owen Taylor wrote:
> >
> > 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);
> > }
[...]
> > - 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:
What I'm saying is manually intervention will be needed for language
bindings *because* there is no way to derive a GObject from a non-
GObject in C.
In C, there is no Gdk.Context ... but introducing it in language
bindings provides a natural way to extend Cairo.Context in an
object oriented language.
> 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.
Of course.
> > 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.
We could easily expose a Gdk.Context in the introspection information.
The problem is that this type has a set of operations defined in GDK
*plus* a set of operations that the cairo_t object already has.
Doing better would require adding the idea of "derivation of boxed
types" in the introspection information and not restrict derivation to
GObjects.
> 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.
That was my next point. Actually, one thing that occurred to me
later is that in most languages, there is no reason you can't
have a constructor for Gdk.Context that takes a cairo_surface_t
in addition to the one that takes the GdkDrawable.
If you do that, you can use all the convenience functionality
on the arbitrary surface.
> > - 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..
You can have multiple context for the same surface/drawable, though
there are some restrictions on interleaving usage of multiple contexts.
The standard pattern is:
def drawSomething(widget):
cr = gdk.Context(widget.window);
cr.move_to(0, 0)
cr.line_to(100, 100)
cr.stroke()
Honestly, why I want to move from gdk_drawable_create_context() to
gdk_cairo_create() is for C:
A) Less typing. This function gets used quite a bit.
B) Parallelism with cairo_create()
C) Avoid the introduction of the 'context' name into the C API,
where it isn't currently.
for a language binding, whether you write
cr = gdk.Context(widget.window)
or
cr = widget.window.createContext()
is less important.
Regards,
Owen
Attachment:
signature.asc
Description: This is a digitally signed message part