java-gnome-hackers

[java-gnome-hackers] Create a Nautilus binding

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

Hi guys,

I was thinking about creating a Nautilus binding, but couldn't find any
tutorial about how to get started with writing my own binding.  I read some
source code and tried putting some .defs files (created by 'demux
nautilus.defs') in the src/defs directory.  The new files got picked up and
I saw some .c and .java source files created in the 'generated' directory.
First it complained about some nautilus types are not defined, I figured
that 'import-header' was missing from the .defs files.  It seemed that I was
on the right track, but I got stuck at one particular file
'generated/bindings/org/gnome/nautilus/NautilusFileInfo.c' complaining
"NautilusFileInfo undeclared".  I looked at the generated .c file, it
doesn't have the #include line generated for the header file that I added to
its .defs file.  Other generated .c files all have the proper header files
included according to their .defs files, but not this one.  So my questions
are:

1) Is there a tutorial for creating bindings?
2) Am I on the right track?
3) Why the header file isn't included?


Thanks in advance!


Jack Hong

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

[Andrew C. <an...@op...>]

On Fri, 2008-07-25 at 14:11 -0400, Jack Hong wrote:
> I was thinking about creating a Nautilus binding

Terrific.

> 2) Am I on the right track?

It sounds like it, but without seeing your code, it is rather hard to
say.

> 3) Why the header file isn't included?

I don't know.

  (import-header "whatever.h")

should work. It does work, or the rest of the library wouldn't build and
the unit tests wouldn't pass :/

So it's probably not that. You didn't forget to mark something as a
pointer, did you?

AfC
Sydney

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

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

Thanks very much Andrew!  It compiles happily if I change the .defs from
'define-interface' to 'define-object', but I'm not sure whether that's what
I should do or not.  I also noticed that some types (GList, GFile, etc.) are
generated as FIXME and the function implementations simply throw an error,
please advise what I should do with these unsupported types, thank you.

Jack



On Fri, Jul 25, 2008 at 6:57 PM, Andrew Cowie <
an...@op...> wrote:

> On Fri, 2008-07-25 at 14:11 -0400, Jack Hong wrote:
> > I was thinking about creating a Nautilus binding
>
> Terrific.
>
> > 2) Am I on the right track?
>
> It sounds like it, but without seeing your code, it is rather hard to
> say.
>
> > 3) Why the header file isn't included?
>
> I don't know.
>
>  (import-header "whatever.h")
>
> should work. It does work, or the rest of the library wouldn't build and
> the unit tests wouldn't pass :/
>
> So it's probably not that. You didn't forget to mark something as a
> pointer, did you?
>
> AfC
> Sydney
>
>
>
> -------------------------------------------------------------------------
> 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
>
>

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

[Andrew C. <an...@op...>]

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

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.

>  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

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.

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

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

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

[Andrew C. <an...@op...>]

On Mon, 2008-07-28 at 00:13 -0400, Jack Hong wrote:
> Hi AfC,

You can call me Andrew :)

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

So this is a complex area; for some related thoughts on a similar topic,
see http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1135 

I'll look into the rest of your ideas in the next day or two. Sounds
like you are barrelling along; if you've got a branch already I'd be
pleased to start looking at it.

>         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

Sorry, I meant Container.

AfC
Sydney

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

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

Hi Andrew,

On Mon, Jul 28, 2008 at 12:43 AM, Andrew Cowie <
an...@op...> wrote:

> On Mon, 2008-07-28 at 00:13 -0400, Jack Hong wrote:
> > Hi AfC,
>
> You can call me Andrew :)
>
> > 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;
>
> So this is a complex area; for some related thoughts on a similar topic,
> see http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1135
>
Thank god the nautilus extension API is not Bonobo based!


> I'll look into the rest of your ideas in the next day or two. Sounds
> like you are barrelling along; if you've got a branch already I'd be
> pleased to start looking at it.
>
I spent a few more hours hacking on my own branch this morning, I'll let you
know as soon as I have something ready for review.  I wrote a simple
implementation of the nautilus extension module piece and some binding
classes.  Now I just need to figure out how to instantiate a subclass of
GObject directly, I'm very close to having a working prototype.  In a common
scenario, a native object is either created by calling the something_new
constructor or retrieved by calling some other functions like
something_copy, etc., the generated part knows how to interact with the
native part and then the developer uses the better looking Java binding
class that calls the generated part.  In other words, you always have the
native object first.  In my case, I have to instantiate a Java object
directly and pass the pointer of the native part of that object to
Nautilus.  Is there an example for this?


>
> >         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
>
> Sorry, I meant Container.

Got it, now my GList* things are correctly generated!


>
>
> AfC
> Sydney
>
>
> -------------------------------------------------------------------------
> 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