Re: Gdk/Cairo integration thought

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 

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

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)
    cr = widget.window.createContext()

is less important.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]