java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination

Re: [java-gnome-hackers] IconView selection methods

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

On Tue, 2009-12-29 at 19:53 +0100, Guillaume Mazoyer wrote:
> To suit my needs, I had to implement few methods into the IconView

Great. 

Have you got a test case or two? Maybe select a path and then make sure
it actually _is_ selected, something like that?

AfC
Sydney

[java-gnome-hackers] IconView selection methods

[Guillaume M. <res...@gm...>]

Hello,

To suit my needs, I had to implement few methods into the IconView
class. I had:

 * void selectPath(TreePath path)
 * void unselectPath(TreePath path)
 * void selectAll()
 * void unselectAll()

The branch which contains these methods can be found at:
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/guillaume/icon-view/

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[java-gnome-hackers] java-gnome 4.0.14 released

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

hack, hack, hack, RELEASE, hack, hack, hack...

The 'mainline' branch now identifies itself as 4.0.15-dev.

Cheers,

AfC
Sydney

Re: [java-gnome-hackers] Problem with glib 2.22.3

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

On Fri, 2009-12-04 at 21:14 +1100, Andrew Cowie wrote:
> This really needs some testing. I'll do 4.0.14-rc2 with this over the
> weekend

Release candidate 4.0.14-rc2 posted with these workarounds.

AfC
Sydney

[java-gnome-hackers] Problem with glib 2.22.3

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

There's a problem. If you 

        a) upgrade to glib 2.22.3
        
        b) use Glib.setProgramName()

Your application will crash due to glib now emitting a WARNING when
g_set_prgname() is called twice, which is fatal for us.
https://bugzilla.gnome.org/show_bug.cgi?id=603774

To deal with this, I've merged two change to 'mainline'

        1) remove our "helpful" call to g_set_prgname() from our
        GtkMain.gtk_init() JNI code.

        2) now allow you to call Glib.setPogramName() before Gtk.init()

revno 701.

This doesn't fix existing apps, of course.

This really needs some testing. I'll do 4.0.14-rc2 with this over the
weekend, but it would really help if people running 'mainline' or
hacking their own branches of java-gnome could check this.

AfC
Sydney

[java-gnome-hackers] SVG loading

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

Some time ago I did up the beginnings of coverage of librsvg. It's the
GNOME library for loading SVG image files, and you use it to draw onto a
Cairo surface.

I did a quick review of the branch this morning. On the one hand it's
fine, there's even the beginnings of a fun example, but I still have a
number of unresolved questions:

 - is it actually necessary to tell people to call Rsvg.init()?

 - in the ValidateVectorIllustrations.testHandleMethods() test, I tried
putting in a cr.moveTo() before drawing the SVG onto the Context, but it
didn't seem to have any effect. That's Weird™

 - how best to test this, actually? Perhaps load an image with this
code, and load an .svg image via gdk-pixbuf, and compare the two? Of
course, gdk-pixbuf uses librsvg, so that would be a good exercise of our
code somewhat isolated.

 - Handle's write() isn't finished; it and close() need testing once we
have a way to compare loaded images.

So. Obviously it's not ready for merging, but we might be able to clean
it up well in time for 4.0.15.

My branch is at 'hackers/andrew/librsvg' if you want to have a go.
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/librsvg/

Meanwhile, I think that was the last open item for considering. There's
a tentative NEWS entry for 4.0.14 up (that's on the 'website' branch,
gets merged to 'mainline' just before a release).
http://java-gnome.sourceforge.net/4.0/NEWS.html

AfC
Sydney


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

Re: [java-gnome-hackers] Potential issues with new closures in JDK 7

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

On Thu, 2009-11-19 at 10:15 -0500, Jacek Furmankiewicz wrote:
> As you've probably heard by now, looks like JDK 7 will be giving us
> closures/lambdas after all (as announced yesterday at Devoxx):

To be honest, I don't follow the politics of Java 1.7 development that
closely; but that's interesting to hear.

Speaking personally, I've never really missed closures as a language
concept in Java; proper function/method pointers would have been wizard
cool for us {10,4} years ago when we engineered java-gnome, but we don't
have them in Java, so {shrug} we don't.

And meanwhile the technique of implementing an interface and using that
in a callback (especially doing so via an anonymous inner class) has
been good enough. Modern IDE support means that the code appears click
swish bang! which makes it even more of a non-issue :)

...

> I would guess there would be no way for the compiler to figure out in
> this case whether it is a KeyPressEvent or KeyReleaseEvent, making JDK
> 7 closures
> potentially unusable with Java-GNOME.

Perhaps!

> Example:

> 
I've never written a callback that short, so I'm not sure I'd miss being
able to use closures.

That said, surely they've got some casting mechanism? ie, taking your
example and having done zero research about it, surely you can put a
cast in to tell the closure which overload of a method you are actually
trying to call?


> Maybe there will be a need for actual event-specific connect methods?

Perhaps. I rather like overloaded methods. I think they look good in
Java, our implementation has beautiful completion and type safety
properties, and it ties somewhat nicely with the underlying
g_signal_connect() API [though that is voodoo at the best of times]

++

Anyway, very interesting design question you've raised. We had similar
conversations when generics first came long, and enums too. Both turned
out to be not that interesting/helpful to us, but it still took
investigation to work that out.

It will be good to think about closures it over the coming years as Java
1.7 gets closer to being actually available out in the wild.

AfC
Sydney



> like this in Swing:
> 
P.S. "the way that Swing does it" doesn't count for all that much. Most
of us have a well-earned and now reflexive hatred for their API. Making
java-gnome appropriate Java is important. Solving design questions
specifically in order to end up with the same thing that {AWT, Swing,
SWT, etc} did is not.

[java-gnome-hackers] Potential issues with new closures in JDK 7

[Jacek F. <ja...@gm...>]

As you've probably heard by now, looks like JDK 7 will be giving us
closures/lambdas after all (as announced yesterday at Devoxx):

So, instead of a verbose listener like this in Swing:

button.addActionListener(
   new ActionListener() {
      public void actionPerformed(ActionEvent e) {
         System.out.println("Hi!"); } } );

we could have a much more concise:

button.addActionListener(#(ActionEvent e) System.out.println("Hi!));

As you can see, the new closures are designed to be backwards compatible,
i.e. able to be used in method that expect an interface with just one
method,
which makes them usable with existing APIs.

I am not sure however if this would work so well with the standard event
APIs in Java-GNOME. Let's look at these two examples:

* **connect(new Widget.KeyPressEvent() {*
* **public boolean onKeyPressEvent(Widget source, EventKey event) {*
* **return false;*
* **}*
* **});*
*        *
*        connect(new Widget.KeyReleaseEvent() {*
* **public boolean onKeyReleaseEvent(Widget source, EventKey event) {*
* **return false;*
* **}*
* **});*

With the new closure syntax both calls would look the same:

*connect(#(Widget source, EventKey event) return false);*

I would guess there would be no way for the compiler to figure out in this
case whether it is a KeyPressEvent or KeyReleaseEvent, making JDK 7 closures
potentially unusable with Java-GNOME. Maybe there will be a need for actual
event-specific connect methods?

Example:

*connectKeyPressEvent(#(Widget source, EventKey event) return false);*
*connectKeyReleaseEvent(#(Widget source, EventKey event) return false);*
*
*
Jacek

Re: [java-gnome-hackers] [Java-gnome-developer] (Hacked) version of 4.0.13 in Maven repo

[Jacek F. <ja...@gm...>]

Andrew, I was thinking that the easiest solution to this would be to allow
overriding the default .so prefix (i.e. "libgtkjni-") with a different one
via a command line property, e.g.

-DgnomePrefix=java-gnome-lib

or something along those lines. That way we could override the default
"libgtkjni" during development (in Maven or whatever else) and let it
fallback to the regular standard way
when the app is deployed on a distro.

I still like the approach of the .so embedded directly in the JAR, but if
you're strongly opposed to it I won't push it any further.

Cheers,
Jacek

On Wed, Nov 18, 2009 at 6:55 PM, Jacek Furmankiewicz <ja...@gm...>wrote:

> I understand your point of view, but Maven and Ant (regardless of how you
> feel about them) are very typical
> setups for any regular Java developer...the type of folks we would like to
> see more exposed to Java-GNOME
> and interested in using it for developing apps.
>
> I think we should maybe differentiate though between development time usage
> (Maven in my case) and deployment on distros (native packaging system).
> It would be great to use Maven for developing JG apps (the whole setup
> makes it so easy)...actually getting them deployed is a
> different issue altogether and could alleviate a lot of your security
> concerns.
>
> I will continue this on the hackers list, as per your suggestion.
>
> Cheers,
> Jacek
>
>
>
>
>

Re: [java-gnome-hackers] [Java-gnome-developer] (Hacked) version of 4.0.13 in Maven repo

[Jacek F. <ja...@gm...>]

I understand your point of view, but Maven and Ant (regardless of how you
feel about them) are very typical
setups for any regular Java developer...the type of folks we would like to
see more exposed to Java-GNOME
and interested in using it for developing apps.

I think we should maybe differentiate though between development time usage
(Maven in my case) and deployment on distros (native packaging system).
It would be great to use Maven for developing JG apps (the whole setup makes
it so easy)...actually getting them deployed is a
different issue altogether and could alleviate a lot of your security
concerns.

I will continue this on the hackers list, as per your suggestion.

Cheers,
Jacek

[java-gnome-hackers] Fwd: Considering Trove

[Leonardo <som...@gm...>]

---------- Forwarded message ----------
From: Leonardo <som...@gm...>
Date: 2009/10/23
Subject: Re: [java-gnome-hackers] Considering Trove
To: Andrew Cowie <an...@op...>


No Andrew,

Avoid to add another dependency,

See, java gnome is somewhat stable for some years in the java side,
just adding dependencies in the gtk land.

You will have a finite ammount of widgets, i don't believe that one
could do some nasty and stupid application able to blow the memory
just with buttons, :P

if use primitives for keys still a good idea after fine tests don't
add it as dependency, but extract it directly for java-gnome, and only
that class.

belive me when i say that add another jar is a lot bad.

2009/10/23 Andrew Cowie <an...@op...>:
> I have for some time been very carefully watching the knownProxies
> HashMap in [org.freedesktop.bindings] Plumbing.
>
> This is the heart of java-gnome, mapping between our strong Java object
> Proxy instances, and instantiated GObjects on the native side. Every
> object [Widget, etc] that is created is stored there, in a <long, Proxy>
> map.
>
> Now, of course, Java's general utility collections require boxing of
> keys which means every addition and every query into that table creates
> a Long object wrapping the long [pointer address] as key. Lot of
> allocations for nothing, really, not to mention all the Map.Entry
> objects that get created.
>
> We have had memory pressure there before (which is why we split Proxy
> into Proxy & Pointer, for example). And while it's not the largest
> hotspot we have right now, essentially *every single code path* in
> java-gnome goes through this table.
>
> As a result I have long speculated that we should replace the
> [java.util] HashMap with something a bit smarter, preferably something
> that takes long primitives as keys, not Long objects as keys.
>
> ++
>
> One possibility is the Trove project, a promising set of collections
> that use different algorithms to the [java.util] ones, and which offer
> sets and maps with native keys and/or values.
> http://trove4j.sourceforge.net/
>
> I did some experimentation and came up with a branch that uses their
> TLongObjectHashMap for the knownProxies map. I uploaded it to
> 'hackers/andrew/trove-external' so you can have a play if you're
> interested. It will configure and build if you're on Ubuntu Karmic.
> bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/trove-external/
>
> Works fine; I'm still trying to figure out if it's an improvement [or
> degradation] profiling wise (we need some better tools for this sort of
> thing); doing compartive studies of GUI application performance is
> notoriously hard, of course.
>
> ++
>
> Anyway, there is a bigger question: should we use this, and if we do,
> should we incur the cost of an external dependency?
>
> This is a non-trivial question. Not only would it mean "java-gnome build
> depends on trove4j", but of course *also* would mean requiring people to
> express the location of the trove jar when trying to run a program built
> with java-gnome; ie just to run a demo program I had to go from
>
> java -classpath /home/andrew/workspace/java-gnome/tmp/gtk-4.0.jar Experiment
>
> to
>
> java -classpath /usr/share/java/trove-2.0.4.jar:/home/andrew/workspace/java-gnome/tmp/gtk-4.0.jar Experiment
>
> {sigh}
>
> [Java's design is so desperately lacking in this regard it's not even
> funny; doing something about it is on my list of itches, but that's not
> something any of us are going to fix overnight]
>
> There is an alternative, and that would be to import the necessary
> [gnu.trove] classes (only) into java-gnome, placing it say in
> lib/dependencies/. I'm *not*a huge fan of this idea; I've spent enough
> time as a Gentoo Java person to know how much effort we usually have to
> spend ripping out embedded junits, jaxens, etc and how horrible static
> linking is, etc.
>
> Indeed, it's time Java people stopped being afraid of depending on each
> other's code, so perhaps I should just bite the bullet, say "too bad"
> and tell people that we now depend on this [or whichever] library. But
> given that it is essentially just one single piece of Trove  that we
> would be depending on, it is almost tempting to just embed it in our
> code base.
>
> ++
>
> Anyway, I'd welcome some discussion on all this, both on the topic of
> the suitability of Trove's [gnu.trove] TLongObjectHashMap as a
> replacement for Sun's [java.util] HashMap, and on the question of other
> Java libraries as dependencies.
>
> I'd like to thank Rob Eden, the current Trove maintainer, for his
> guidance and encouragement.
>
> AfC
> Sydney
>
>
> --
> 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
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>

[java-gnome-hackers] Release imminent

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

It's about time we did a java-gnome 4.0.14 release.

If you care about API additions, etc then grab current 'mainline' and
do:

$ bzr diff -r tag:v.4.0.13

and of course:

$ bzr log -r tag:v4.0.13..

will tell you in gory detail :)

++

Srichand has alerted us to a really hair problem to do with some Java
implementations being unable to differentiate between deprecated inner
interface Button.CLICKED and the replacement Button.Clicked. This is
mildly extraordinary.

Since these deprecations have been in place for well over a year [and
with assertions enabled you can't even use the code paths in question],
I'm willing to see the old code removed. The discussion just before
4.0.13 about API versions applies again, and although I was going to
remove this code when we bumped to 4.1, I'm not otherwise that worried
about it; no one with public code is using the old signatures and so I
think we can stick with 4.0

When we decide about this I'll cut a release candidate tarball.

++

If someone wants a bit of an easy challenge, maybe they could have a go
on the 'deprecated-2.16' work? See:
http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1330

AfC
Sydney

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

Re: [java-gnome-hackers] GtkWindow XID

[Goundy <go...@gm...>]

Emmanuel Rodriguez wrote:
>
> Edit the file  jni/bindings_java.h and add the following include after 
> the other ones already there:
> #include <gdk/gdkx.h>
>
>
> -- 
> Emmanuel Rodriguez
Emmanuel, You nailed it !
That worked \o/

Bad damn, I've been spending too much time for nothing... X is still 
giving a BadWindow...
Anyway I better digg a bit arround this :)

Thanks for help emmanuel ;)

Re: [java-gnome-hackers] GtkWindow XID

[Emmanuel R. <emm...@gm...>]

On Sun, Oct 25, 2009 at 3:59 PM, Goundy <go...@gm...> wrote:

> Goundy wrote:
> > and I have the following code in GdkDrawable.defs:
> >
> > (define-method get_xid
> >  (of-object "GdkDrawable")
> >  (c-name "gdk_x11_drawable_get_xid")
> >  (caller-owns-return #t)
> >  (return-type "long")
> > )
> >
>


> Am I missing something here ?
> > Thanks
> >
> Oh I get the correct one :P
> (define-method get_xid
>  (of-object "GdkDrawable")
>  (c-name "gdk_x11_drawable_get_xid")
>  (caller-owns-return #t)
>   (return-type "gulong")
> )
>
That fix the first problem: the function is now generated.


> Is fine, it gives:
>
>    static final long getXid(Drawable self) {
>         long result;
>
>        if (self == null) {
>            throw new IllegalArgumentException("self can't be null");
>        }
>
>        synchronized (lock) {
>             result = gdk_x11_drawable_get_xid(pointerOf(self));
>
>            return result;
>        }
>    }
>
>    private static native final long gdk_x11_drawable_get_xid(long self);
>
> But when I build java-gnome I get:
> generated/bindings/org/gnome/gdk/GdkDrawable.c: In function
> 'Java_org_gnome_gdk_GdkDrawable_gdk_1x11_1drawable_1get_1xid':
> generated/bindings/org/gnome/gdk/GdkDrawable.c:1044: error: implicit
> declaration of function 'gdk_x11_drawable_get_xid'
> compilation terminated due to -Wfatal-errors.
> make: *** [build-java] Error 1
>
> Which is really weird...
> Ideas are welcome :)
>
> Edit the file  jni/bindings_java.h and add the following include after the
other ones already there:
#include <gdk/gdkx.h>


-- 
Emmanuel Rodriguez

Re: [java-gnome-hackers] GtkWindow XID

[Goundy <go...@gm...>]

Goundy wrote:
> Emmanuel Rodriguez wrote:
>> On Sun, Oct 25, 2009 at 2:57 PM, Goundy <go...@gm... 
>> <mailto:go...@gm...>> wrote:
>>
>>     Emmanuel Rodriguez wrote:
>>
>>
>>         Are you sure then that eclipse is picking up the right
>>         gtkjini.so file?
>>         Did you install your new bindings?
>>
>>
>>     Oh my! when I rebuild my branch, actually my method is being
>>     erased as the GdkDrawable file gets replace by the new generated
>>     one which doesn't contain my method.
>>     I guess I have to edit the source .def file to keep my method 
>> right ?
>>
>> I think so, I haven't used the java-gnome bindings in a long time.
>> I wish that someone else that's using the bindings could help you :(
>>
>> -- 
>> Emmanuel Rodriguez
> Okay thank you Emmanuel, you helped a lot :P
>
> Well, the generator is giving me:
>
>    static final FIXME getXid(Drawable self) throws 
> BlacklistedMethodError {
>        throw new BlacklistedMethodError("long");
>    }
>
> and I have the following code in GdkDrawable.defs:
>
> (define-method get_xid
>  (of-object "GdkDrawable")
>  (c-name "gdk_x11_drawable_get_xid")
>  (caller-owns-return #t)
>  (return-type "long")
> )
>
> Am I missing something here ?
> Thanks
>
Oh I get the correct one :P
(define-method get_xid
  (of-object "GdkDrawable")
  (c-name "gdk_x11_drawable_get_xid")
  (caller-owns-return #t)
  (return-type "gulong")
)
Is fine, it gives:

    static final long getXid(Drawable self) {
        long result;

        if (self == null) {
            throw new IllegalArgumentException("self can't be null");
        }

        synchronized (lock) {
            result = gdk_x11_drawable_get_xid(pointerOf(self));

            return result;
        }
    }

    private static native final long gdk_x11_drawable_get_xid(long self);

But when I build java-gnome I get:
generated/bindings/org/gnome/gdk/GdkDrawable.c: In function 
'Java_org_gnome_gdk_GdkDrawable_gdk_1x11_1drawable_1get_1xid':
generated/bindings/org/gnome/gdk/GdkDrawable.c:1044: error: implicit 
declaration of function 'gdk_x11_drawable_get_xid'
compilation terminated due to -Wfatal-errors.
make: *** [build-java] Error 1

Which is really weird...
Ideas are welcome :)

Re: [java-gnome-hackers] GtkWindow XID

[Goundy <go...@gm...>]

Emmanuel Rodriguez wrote:
> On Sun, Oct 25, 2009 at 2:57 PM, Goundy <go...@gm... 
> <mailto:go...@gm...>> wrote:
>
>     Emmanuel Rodriguez wrote:
>
>
>         Are you sure then that eclipse is picking up the right
>         gtkjini.so file?
>         Did you install your new bindings?
>
>
>     Oh my! when I rebuild my branch, actually my method is being
>     erased as the GdkDrawable file gets replace by the new generated
>     one which doesn't contain my method.
>     I guess I have to edit the source .def file to keep my method right ?
>
> I think so, I haven't used the java-gnome bindings in a long time.
> I wish that someone else that's using the bindings could help you :(
>
> -- 
> Emmanuel Rodriguez
Okay thank you Emmanuel, you helped a lot :P

Well, the generator is giving me:

    static final FIXME getXid(Drawable self) throws BlacklistedMethodError {
        throw new BlacklistedMethodError("long");
    }

and I have the following code in GdkDrawable.defs:

(define-method get_xid
  (of-object "GdkDrawable")
  (c-name "gdk_x11_drawable_get_xid")
  (caller-owns-return #t)
  (return-type "long")
)

Am I missing something here ?
Thanks

Re: [java-gnome-hackers] GtkWindow XID

[Emmanuel R. <emm...@gm...>]

On Sun, Oct 25, 2009 at 2:57 PM, Goundy <go...@gm...> wrote:

> Emmanuel Rodriguez wrote:
>
>>
>> Are you sure then that eclipse is picking up the right gtkjini.so file?
>> Did you install your new bindings?
>>
>>
> Oh my! when I rebuild my branch, actually my method is being erased as the
> GdkDrawable file gets replace by the new generated one which doesn't contain
> my method.
> I guess I have to edit the source .def file to keep my method right ?
>
I think so, I haven't used the java-gnome bindings in a long time.
I wish that someone else that's using the bindings could help you :(

-- 
Emmanuel Rodriguez

Re: [java-gnome-hackers] GtkWindow XID

[Goundy <go...@gm...>]

Emmanuel Rodriguez wrote:
>
> Are you sure then that eclipse is picking up the right gtkjini.so file?
> Did you install your new bindings?
>

Oh my! when I rebuild my branch, actually my method is being erased as 
the GdkDrawable file gets replace by the new generated one which doesn't 
contain my method.
I guess I have to edit the source .def file to keep my method right ?

Re: [java-gnome-hackers] GtkWindow XID

[Emmanuel R. <emm...@gm...>]

On Sun, Oct 25, 2009 at 2:42 PM, Goundy <go...@gm...> wrote:

> Emmanuel Rodriguez wrote:
>
>> No exactly, this just means that you have the libraries installed, but
>> java-gnome might not be using them (linked).
>>
>> Check with ldd if the java-gnome .so is linked with  gdk-x11
>>   ldd tmp/libgtkjni-*.so | grep gdk-x11-2.0
>>
>> If ldd doesn't show the file then it isn't linked. Try to link it your
>> self by hand:
>>  rm tmp/libgtkjni-*.so
>>  LDFLAGS=`pkg-config --libs gdk-x11-2.0` build/faster
>>
>> If ldd shows the file in the dependency list then there's something
>> strange going on.
>>
>>  goundy@localhost ~/java-gnome/working/tmp $ ldd libgtkjni-4.0.12-dev.so | grep gdk-x11
>   libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb78ec000)
> that's odd :°)
> Btw, I haven't modified any .def file yet, I just added the new accessor in
> GdkDrawable.java and then linked (in eclipse) the java-gnome project to my
> testing project.
>
Are you sure then that eclipse is picking up the right gtkjini.so file?
Did you install your new bindings?

-- 
Emmanuel Rodriguez

Re: [java-gnome-hackers] GtkWindow XID

[Goundy <go...@gm...>]

Emmanuel Rodriguez wrote:
> No exactly, this just means that you have the libraries installed, but 
> java-gnome might not be using them (linked).
>
> Check with ldd if the java-gnome .so is linked with  gdk-x11
>    ldd tmp/libgtkjni-*.so | grep gdk-x11-2.0
>
> If ldd doesn't show the file then it isn't linked. Try to link it your 
> self by hand:
>   rm tmp/libgtkjni-*.so
>   LDFLAGS=`pkg-config --libs gdk-x11-2.0` build/faster
>
> If ldd shows the file in the dependency list then there's something 
> strange going on.
>
goundy@localhost ~/java-gnome/working/tmp $ ldd libgtkjni-4.0.12-dev.so  
| grep gdk-x11
    libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb78ec000)
that's odd :°)
Btw, I haven't modified any .def file yet, I just added the new accessor 
in GdkDrawable.java and then linked (in eclipse) the java-gnome project 
to my testing project.

Re: [java-gnome-hackers] GtkWindow XID

[Emmanuel R. <emm...@gm...>]

On Sun, Oct 25, 2009 at 12:34 PM, Goundy <go...@gm...> wrote:

> Morning,
>
> Emmanuel Rodriguez wrote:
> >
> >
> > java-gnome is probably not linking against gdk-x11
> > Try to see if you can link it with gdk-x11-2.0  from pkg-config
> >
> > You can find the exact linker flags by running:
> >
> > pkg-config --libs gdk-x11-2.0
> >
> >
> Actually it is, I've:
> goundy@localhost ~ $ pkg-config --libs gdk-x11-2.0
> -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo
> -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
>
> That's kinda weird.
>
No exactly, this just means that you have the libraries installed, but
java-gnome might not be using them (linked).

Check with ldd if the java-gnome .so is linked with  gdk-x11
   ldd tmp/libgtkjni-*.so | grep gdk-x11-2.0

If ldd doesn't show the file then it isn't linked. Try to link it your self
by hand:
  rm tmp/libgtkjni-*.so
  LDFLAGS=`pkg-config --libs gdk-x11-2.0` build/faster

If ldd shows the file in the dependency list then there's something strange
going on.

-- 
Emmanuel Rodriguez

Re: [java-gnome-hackers] GtkWindow XID

[Goundy <go...@gm...>]

Morning,

Emmanuel Rodriguez wrote:
>
>
> java-gnome is probably not linking against gdk-x11
> Try to see if you can link it with gdk-x11-2.0  from pkg-config
>
> You can find the exact linker flags by running:
>
> pkg-config --libs gdk-x11-2.0
>
>
Actually it is, I've:
goundy@localhost ~ $ pkg-config --libs gdk-x11-2.0
-lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo 
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0

That's kinda weird.

Re: [java-gnome-hackers] GtkWindow XID

[Emmanuel R. <emm...@gm...>]

On Sat, Oct 24, 2009 at 4:22 PM, Goundy <go...@gm...> wrote:

> Emmanuel Rodriguez thank you very much, you helped lot
>
> Emmanuel Rodriguez wrote:
> >
> >
> > the XID has to be taken from GdkDrawable, from which GdkWindow
> > inherits. You used a GtkWindow, instead of GdkWindow. I've checked the
> > doc of GdkDrawable [1] and it is missing the accessor for xid wich in
> > C is provide by the function gdk_x11_drawable_get_xid [2]. Without
> > that accesor you will not be able to take the XID of a window.
> >
> >
> >
> > --
> > Emmanuel Rodriguez
> The only problem now is that I'm getting:
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> org.gnome.gdk.GdkDrawable.gdk_x11_drawable_get_xid(J)I
>    at org.gnome.gdk.GdkDrawable.gdk_x11_drawable_get_xid(Native Method)
>    at org.gnome.gdk.GdkDrawable.getXID(GdkDrawable.java:508)
>
java-gnome is probably not linking against gdk-x11
Try to see if you can link it with gdk-x11-2.0  from pkg-config

You can find the exact linker flags by running:

pkg-config --libs gdk-x11-2.0

-- 
Emmanuel Rodriguez

Re: [java-gnome-hackers] GtkWindow XID

[Goundy <go...@gm...>]

Goundy wrote:
> Emmanuel Rodriguez thank you very much, you helped lot
>
> Emmanuel Rodriguez wrote:
>>
>>
>> the XID has to be taken from GdkDrawable, from which GdkWindow 
>> inherits. You used a GtkWindow, instead of GdkWindow. I've checked 
>> the doc of GdkDrawable [1] and it is missing the accessor for xid 
>> wich in C is provide by the function gdk_x11_drawable_get_xid [2]. 
>> Without that accesor you will not be able to take the XID of a window.
>>
>>
>>
>> -- 
>> Emmanuel Rodriguez
> The only problem now is that I'm getting:
> Exception in thread "main" java.lang.UnsatisfiedLinkError: 
> org.gnome.gdk.GdkDrawable.gdk_x11_drawable_get_xid(J)I
>    at org.gnome.gdk.GdkDrawable.gdk_x11_drawable_get_xid(Native Method)
>    at org.gnome.gdk.GdkDrawable.getXID(GdkDrawable.java:508)
>
> And I added a call to that native function as:
>
> GdkWindow.java:
>
>    static final long getXID(Drawable self) {
>        long result;
>
>        if (self == null) {
>            throw new IllegalArgumentException("self can't be null");
>        }
>
>        synchronized (lock) {
>            result = gdk_x11_drawable_get_xid(pointerOf(self));
>
>            return result;
>        }
>    }
>
> Any ideas ?
> Thanks
>
Oh Sorry, I meant GdkDrawable.java *

Re: [java-gnome-hackers] GtkWindow XID

[Goundy <go...@gm...>]

Emmanuel Rodriguez thank you very much, you helped lot

Emmanuel Rodriguez wrote:
>
>
> the XID has to be taken from GdkDrawable, from which GdkWindow 
> inherits. You used a GtkWindow, instead of GdkWindow. I've checked the 
> doc of GdkDrawable [1] and it is missing the accessor for xid wich in 
> C is provide by the function gdk_x11_drawable_get_xid [2]. Without 
> that accesor you will not be able to take the XID of a window.
>
>
>
> -- 
> Emmanuel Rodriguez
The only problem now is that I'm getting:
Exception in thread "main" java.lang.UnsatisfiedLinkError: 
org.gnome.gdk.GdkDrawable.gdk_x11_drawable_get_xid(J)I
    at org.gnome.gdk.GdkDrawable.gdk_x11_drawable_get_xid(Native Method)
    at org.gnome.gdk.GdkDrawable.getXID(GdkDrawable.java:508)

And I added a call to that native function as:

GdkWindow.java:

    static final long getXID(Drawable self) {
        long result;

        if (self == null) {
            throw new IllegalArgumentException("self can't be null");
        }

        synchronized (lock) {
            result = gdk_x11_drawable_get_xid(pointerOf(self));

            return result;
        }
    }

Any ideas ?
Thanks