Re: [java-gnome-hackers] Create a Nautilus binding

[Jack H. <jac...@gm...>]

Hi AfC,

On Sat, Jul 26, 2008 at 3:55 AM, Andrew Cowie <
an...@op...> wrote:

> On Fri, 2008-07-25 at 23:34 -0400, Jack Hong wrote:
> > Thanks very much Andrew!  It compiles happily if I change the .defs
> > from 'define-interface'
>
> The canonical (and original) interface implementation was
> org.gnome.gtk.FileChooser and GtkFileChooser.defs, which is the
> interface implemented by org.gnome.gtk.FileChooserButton and friends. I
> suggest you look at a method like FileChooserButton's setAction().

I will have a look at the FileChooser impl, thanks!


>
> However, you really need to discuss [with us] what interfaces you are
> trying to represent, how you plan to expose them, and what divergences,
> if any, you are anticipating to make the API more appropriate to Java
> developers.
>
> Arbitrarily changing something from an interface to an object in
> the .defs data sounds wildly inappropriate.
>
I was just telling you by changing it from an interface to an object in the
.defs, the generated .c did have the header file included, I knew that
wouldn't be the solution.  I started reading some code and writing some of
my own from last Friday and have only spent 3 hours so far.  I'm really new
to this project, so what I'm doing and saying may look and sound very silly
to you, please bear with me, your input is greatly appreciated!

Here are some quick thoughts about the nautilus binding that I'd like to
work on.
1) the nautilus binding will consist of 2 pieces: the binding piece and the
extension module;
2) the binding piece will be same as other JG bindings providing Java
interfaces and classes for Java developers to implement any nautilus
"provider" in Java.  All provider interfaces, namely NautilusColumnProvider,
NautilusInfoProvider, NautilusMenuProvider, NautilusPropertyPageProvider and
NautilusLocationWidgetProvider, shall be supported;
3) the extension module will be a standard nautilus extension module written
in C; it shall start a JVM, scan some dirs for Java-based "provider"
implementations, load and register them to the Nautilus instance;


> >  to 'define-object', but I'm not sure whether that's what I should do
> > or not.  I also noticed that some types (GList
>
> Coverage of GList* of things is implemented, though you need to mark up
> the .defs data slightly. See Widget's getChildren() and the
> corresponding data in  src/defs/GtkWidget.defs

I updated my local "mainline" directory but did not find the getChildren()
method you suggested in your email.  Is it not on mainline?


>
> AfC
> Sydney
>
> P.S. Please stop top posting. It is considered poor etiquette in the
> Open Source world. And I _am_ subscribed to the mailing list. You don't
> need to send me my own copy of each email you send.

My apologies.


>
>
> --
> 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. We actively
> carry out research and development in these areas on behalf of our
> clients, and enable successful use of open source in their mission
> critical enterprises, worldwide.
>
> http://www.operationaldynamics.com/
>
> Sydney   New York   Toronto   London
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>

Cheers,

Jack