Re: [java-gnome-hackers] Function pointers

[Mark H. <mh...@ti...>]

The java code for this looks kindof klunky - the 'signal' is really an
internal detail of TreeModelFilter rather than an external signal.
Would it be possible to define TreeModelFilter as an abstract class
with an abstract boolean isVisible(row) method. Implementations of
custom tree model filters would be concrete implementations of this.

I don't have time to investigate the implementation unfortunately, but
a simple hack might be to use the current signal mechanisms but with a
single handler for the signal in TreeModelFilter which delegates to
the abstract method?



On Jan 24, 2008 10:30 PM, Andrew Cowie <an...@op...> wrote:
> GtkTreeModelFilter revolves around using
> gtk_tree_model_filter_set_visible_func() to register a callback to a
> function of signature (*GtkTreeModelVisibleFilterVisibleFunc). As most
> of you know, we don't have a general mechanism for handling function
> pointers, and indeed blacklist any method with one as an argument.
>
> We already have a very powerful C to Java callback mechanism, and that's
> the marshaling code used to deal with GObject signals. I've long had
> bigger plans for that code, because it works well, and doing the C to
> Java thing is ninja voodoo as it is, and nasty when you consider it in
> the general case.
>
> That observed, my general strategy for some time for dealing with non
> signal callbacks has been to merely find a way to turn it into a signal
> emission and then deal with it down the existing code path.
>
> It took a lot of futzing to find the magic incantation necessary, but
> I've worked something out for TreeModelFilter which C side registers a
> custom signal and then the function which meets
> (*GtkTreeModelVisibleFilterVisibleFunc) "simply" emits the signal.
>
> It's all done by hand, of course, and I'm not sure how amenable this
> will be to code generation (indeed, we don't have the required
> signatures in our .defs data), but it seems to work fairly well. The
> public API Java side looks right:
> http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeModelFilter.html
>
> and here is the implementing C code:
> http://research.operationaldynamics.com/bzr/java-gnome/mainline/src/bindings/org/gnome/gtk/GtkTreeModelFilterOverride.c
>
> The real trick was the insight that we didn't need to figure out the
> marshaling function when registering the signal after all - which is
> where I'd been stuck before, because there wasn't an existing
> BOOLEAN:OBJECT,BOXED marshaller.
>
> AfC
> Sydney
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>