On Fri, 2010-10-01 at 23:45 +0200, Daniel Tschernatsch wrote:
> Hello Java-Gnome developers,
>
> i'd like to use 2D graphics to interact with the user in my application.
> Some pieces of my Cairo drawings (complex paths extracted from SVG)
> should react when the mouse hovers over them or when they receive mouse
> clicks. But I think there is one essential function missing from
> Java-Gnome to accomplish this: cairo_in_fill: It...
>
> "Tests whether the given point is inside the area that would be affected
> by a cairo_fill() operation given the current path and filling
> parameters."
>
> Is it very hard to implement it in java-gnome?
So, in general [when things are working :)], the answer is "no, it's not
hard at all"
The internal layers of java-gnome are generated; we start with ".defs
data" (which are scheme-ish definitions of each type, enum, function,
method, etc in the various GNOME libraries) [1] and generate various
layers of code.
The part we do NOT generate is the outside edge, the public API. That we
leave to humans to decide what to expose, and how.
Most of the time, though, exposing additional coverage is straight
forward. For instance, the method you're looking for is
cairo_in_fill()
which really ought to be called
cairo_context_in_fill()
Assuming we had defs data for this method [2], our code generator would
output a package visible method in org.freedesktop.cairo.CairoContext:
static boolean inFill(Context self) {
return cairo_in_fill(pointerOf(self));
}
private native boolean cairo_in_fill(long self);
and then there's a C part which implements that native declaration and
calls the actual function.
That's all already there.
The part that a human has to do, if they so choose because they need it,
like you do, is to expose the public API ("write the binding"). In this
case, too easy:
In [org.freedesktop.cairo] Context,
public boolean inFill() {
return CairoContext.inFill(this);
}
and that's it. You'll note that you get a REALLY BIG HINT as to what the
public method should be called by what was generated, but that's where
the humans come in - to decide what, in fact, the signature should be.
Actually, it's not it - you need to write me some JavaDoc :) but you get
the idea. And in an IDE like Eclipse, you'll have code completion and so
can write this in seconds.
A unit test would be good, too :)
More info at
http://java-gnome.sourceforge.net/4.0/doc/design/START.html
especially
http://java-gnome.sourceforge.net/4.0/doc/design/5a-Architecture.html
If you want to try this yourself, let me know. I'd be happy to help get
you started.
AfC
New York
[1] Serkan is working on a parser for GIR .xml data, so soon we'll have
up to date data for even more types!
[2] Cairo is a bit more work, because we didn't have .defs information
for its functions ahead of time. So someone has to write it, to then.
But that's not too hard.
[3] This sort of thing really belongs on the java-gnome-hackers mailing
list, since we're [now] talking about engineering. Reply to there :)
--
Andrew Frederick Cowie
Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.
http://www.operationaldynamics.com/
Sydney New York Toronto London
|
