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

Re: [java-gnome-hackers] GtkWindow XID

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

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

> Hi,
>
> I'm trying to use gstreamer in a simple java-gnome app by using
> gstreamer-java. But to be able to embed a video into a Window I've to
> get back its native xid.
> So, I modified Java-gnome to implement this:
>
> in GtkWindow.java I added:
>    static public final long getWindowXID (Window w){
>        return pointerOf(w);
>    }
>
> 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.

Here's an example on how to embed Gstreamer in a custom Gtk2 application:
http://github.com/potyl/perl-GStreamer-Interfaces/blob/master/examples/gst-video-sample.pl

The code in Perl, but you should be able to understand easily what's going
on.

[1]
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gdk/Drawable.html
[2]
http://library.gnome.org/devel/gdk/unstable/gdk-X-Window-System-Interaction.html#gdk-x11-drawable-get-xid


-- 
Emmanuel Rodriguez

[java-gnome-hackers] GtkWindow XID

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

Hi,

I'm trying to use gstreamer in a simple java-gnome app by using 
gstreamer-java. But to be able to embed a video into a Window I've to 
get back its native xid.
So, I modified Java-gnome to implement this:

in GtkWindow.java I added:
    static public final long getWindowXID (Window w){
        return pointerOf(w);
    }

and in Window.java I added:
    public long getWindowXID (){
        return GtkWindow.getWindowXID(this);
    }

But when I use this id to embed the video X says BadWindow.
Am I getting the xid the right way ?

Thanks in advance

[java-gnome-hackers] Considering Trove

[Andrew C. <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

Re: [java-gnome-hackers] Upgrading public branches

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

On Thu, 2009-10-08 at 16:08 +1100, Andrew Cowie wrote:
> I'm going to upgrade java-gnome's 'mainline' branch to the 2a format

Done.

AfC
Sydney

Re: [java-gnome-hackers] Cleaned linkbutton branch

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

Hello,

> Well. It that never used to happen; perhaps its now happening due to a
> recent change somewhere else down the stack, or as a result of our Xvfb
> code?
We cannot change the behavior of a LinkButton now so emitClicked() open
the right application for the given URI. In the test, it is a website so
it opens the web browser. I did not think about commenting this, my
bad ;-)

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

Re: [java-gnome-hackers] Cleaned linkbutton branch

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

On Thu, 2009-10-08 at 13:37 +0200, Guillaume Mazoyer wrote:
> I just did the 'linkbutton' branch cleanup.

So it's all fine, except that I don't think that the unit test should
result in a web broswer starting up! Yikes. :)

Well. It that never used to happen; perhaps its now happening due to a
recent change somewhere else down the stack, or as a result of our Xvfb
code?

No matter. I've commented out that test fixture for now. Shame,
really. :)

Merged to 'mainline'.

AfC
Sydney

[java-gnome-hackers] Cleaned linkbutton branch

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

Hello,

I just did the 'linkbutton' branch cleanup.
So, there are all the stuffs we have in the previous 'linkbutton' branch
except the setUriHook() method which is removed until we know how to fix
it.

The branch can be found at
'bzr/java-gnome/hackers/guillaume/linkbutton/'.

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

[java-gnome-hackers] Upgrading public branches

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

I'm going to upgrade java-gnome's 'mainline' branch to the 2a format
this weekend, unless anyone actively contributing is in some kind of
dire strait and cannot get a Bazaar that speaks that repository format
(that would be bzr >= 1.16.1 apparently, although I'd really encourage
you to be using bzr 2.0.0 now that it's widely available).

AfC
Sydney

[java-gnome-hackers] Colormap obsolete?

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

I recently noticed https://bugzilla.gnome.org/show_bug.cgi?id=536498
where it's pointed out that various GdkColormap getters are ... unused.

A few months ago, though, Zak Fenton worked hard to get Screen's
getColormapDefault() and getColormapRGB() exposed, and we use that for
doing transparent backgrounds. And it works great as far as I was able
to use it.
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gdk/Screen.html#getColormapDefault()

This whole topic has always been mysterious to me. Can someone maybe
shed some light on how one is supposed to use this, or not?

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/

[java-gnome-hackers] More spelling

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

Anyone know anything about the internals of Echant?

I've done some preliminary work to expose coverage of the Enchant spell
checker facade. It's a pretty straight-forward API to use, and judging
by the tests I wrote, it works great.

One thing I don't understand is what Enchant's "exclude" list is; if you
add() a word then it's added to the custom [local] word list for that
Dictionary. All good. But when you remove() that word, it is indeed
delete from that list file but it is simultaneously *added* to an
"exclude" file, ie it gets moved out from .config/enchant/en.dic [ie
remove()] but then appears in .config/enchant/en.exc

And THAT I have no understanding of.

The binding seems sane, otherwise, so it's merged in. But if someone who
knows what they're about wants to play with this, I'd appreciate it.
Enchant.init() is the starting point.

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

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

Hello,

> Is this code on your 'linkbutton' branch?
No, it is not. Since it does not work I chose to not commit it.

> Anyway, I think we're pretty close now, so next time we catch up
> together online let's see if we can figure it out together.
I think so. I hope we can finish this work soon.

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

Re: [java-gnome-hackers] LinkButton

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

On Sun, 2009-09-13 at 13:56 +0200, Guillaume Mazoyer wrote:
> I found a way to "unset" the previous URI hook in the GtkLinkButton
> class but using it in the JNI side still does not work. And now, I'm a
> bit lost.

Is this code on your 'linkbutton' branch?

Anyway, I think we're pretty close now, so next time we catch up
together online let's see if we can figure it out together.

AfC
Sydney

Re: [java-gnome-hackers] LinkButton

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

Hello,

I found a way to "unset" the previous URI hook in the GtkLinkButton
class but using it in the JNI side still does not work. And now, I'm a
bit lost.

In order to come back to the default GtkLinkButton behavior, we have to
use the "gtk_link_button_set_uri_hook()" but with 3 NULL arguments.

>> gtk_link_button_set_uri_hook(NULL, NULL, NULL);

In this way, even if this method has been used before, a click on the
button will simply open the given URI with the with the showUri(URI)
method.

I tried to use this to correct the our default LinkButton behavior but
it still doesn't work. I guess it is due to the fact that there is no
reference to the GtkLinkButton given to the
"gtk_link_button_set_uri_hook()" method.

Is it possible to fix that? I guess but I don't know how...

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

Re: [java-gnome-hackers] LinkButton

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

Hello,

I continue my investigation. In my last to mails I was wrong. When we
click on a GtkLinkButton both of the "clicked" and
"gtk_link_button_set_uri_hook()" callbacks are used.

The current branch acts like GTK does except for one thing. As you
supposed, when we used the "gtk_link_button_set_uri_hook()" method twice
the second callback *should replace* the first one so I guess it is the
only thing which should be corrected.

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

Re: [java-gnome-hackers] LinkButton

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

Hello,

> Can you paste your C and Java test code somewhere?

Java example:
http://respawner.pastebin.com/m10695646

C example:
http://respawner.pastebin.com/d6107fe80

C files for the "clicked" callback:
http://respawner.pastebin.com/d5e5a0647
http://respawner.pastebin.com/d287b66ab


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

Re: [java-gnome-hackers] LinkButton

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

On Tue, 2009-09-01 at 18:34 +0200, Guillaume Mazoyer wrote:
> When the GtkLinkButton (in C) is pressed, there is *no* "clicked" signal
> emitted (that is a little weird?)

Presumably the C implementation in gtk/gtklinkbutton.c connects to the
"clicked" signal and, having received it, blocks it from further
emission. [though the internal detail of how they may be very different]

> but in Java this signal is still
> emitted.

Perhaps because we're connecting before the [default] handler installed
by GtkLinkButton?

Still, you should have been able to duplicate the effect in C.

Can you paste your C and Java test code somewhere?

AfC
Sydney

Re: [java-gnome-hackers] LinkButton

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

Hello,

> Guillaume, I merged your 'linkbutton' into mine; if you could in turn
> merge (or pull) 'hackers/andrew/linkbutton' into yours hopefully it'll
> be clean.
Done.

> You'll notice I wrote some tests that are failing. Perhaps you can see
> if you can figure out what wrong assumptions we're making about
> LinkButton's behaviour.
About the failing tests, I did some investigations to know more about
the "gtk_link_button_set_uri_hook" method. I eventually wrote an example
in C and its Java equivalent.

When the GtkLinkButton (in C) is pressed, there is *no* "clicked" signal
emitted (that is a little weird?) but in Java this signal is still
emitted. So I guess the "gtk_link_button_set_uri_hook" callback totally
replaces the "clicked" signal callback.

With the current state of the "linkbutton" branch, we can do two
different things with the "gtk_link_button_set_uri_hook" and the
"clicked" signal, so maybe I should correct the current LinkButton
behavior (how?) to make it act like the official GtkLinkButton does.

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

[java-gnome-hackers] java-gnome 4.0.13 released

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

See IRC channel :)

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

Cheers,

AfC
Sydney

[java-gnome-hackers] LinkButton

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

On Sun, 2009-08-23 at 14:51 +0200, Guillaume Mazoyer wrote:

> I think I finished to work on the linkbutton

So I just discovered the hard way that Serkan didn't merge the
'linkbutton' improvements I made in June into his branch. :(

Guillaume, I merged your 'linkbutton' into mine; if you could in turn
merge (or pull) 'hackers/andrew/linkbutton' into yours hopefully it'll
be clean.

You'll notice I wrote some tests that are failing. Perhaps you can see
if you can figure out what wrong assumptions we're making about
LinkButton's behaviour.

AfC
Sydney

Re: [java-gnome-hackers] Looking for contributors for my incomplete Java-Gnome Bazaar branches

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

Since few days/weeks, I'm trying to keep some of the Serkan's branches
alive.

> Vte:
> http://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/vte/
> VTE library provides a terminal widget which powers Gnome Terminal and
> other GTK+ terminal emulators. The purpose of this branch to add
> coverage of VTE API.
VTE branch [bzr/java-gnome/hackers/guillaume/vte/] is in progress. I
added all methods but there is still a lot of documentation to do.

> Sexy:
> http://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/sexy/
> Libsexy provides additional widgets for GTK+. The purpose of this branch
> to add coverage of widgets provided by Libsexy.
Libsexy branch [bzr/java-gnome/hackers/guillaume/libsexy/] is also one
of the branch I continue to work on. I guess It's pretty close to be
finished. I did all the missing code and comments, wrote some examples
and snapshots. I still must write test cases and everything should be
ready after that.

> Linkbutton:
> http://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/linkbutton/
> LinkButton is a widget providing an HTML anchor like link. The purpose
> of this branch is to cover LinkButton.
I think I finished to work on the linkbutton
[bzr/java-gnome/hackers/guillaume/linkbutton/] branch. Serkan's did a
lot of work on it. I just added comments, wrote an example and added
email and url callbacks for AboutDialog. I'm not sure it is ready to be
merged but (to Andrew) feel free to pull it and take a look.

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

Re: [java-gnome-hackers] ABI break; API bump?

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

On Fri, 2009-08-21 at 22:32 +0200, Guillaume Mazoyer wrote:
> I did not think about using the TreeModelFilter but now the example is
> using it. Thank you for the tip.

Nicely done!

I simplified the logic a bit, but this was great.

Merged to 'mainline'.

Minimum version of GTK required by java-gnome now 2.16

AfC
Sydney

Re: [java-gnome-hackers] ABI break; API bump?

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

> I think that example needs to use a TreeModelFilter rather than the
> manual clear & repopulate you're doing now, but that doesn't matter
> enough for me to block your branch.
I did not think about using the TreeModelFilter but now the example is
using it. Thank you for the tip.

> One last thing, though: were you planning on *using* the Snapshots you
> created? I think you need to add <img> to the Entry.java class javadoc
> comment :)
Actually, the snapshot was used into EntryIconPosition. It was a mistake
I made when I did the documentation, the "fix" is now pushed.

> Your branch is otherwise fine and will be merged to 'mainline'.
Nice :)

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

Re: [java-gnome-hackers] ABI break; API bump?

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

On Thu, 2009-08-20 at 13:58 +0200, Guillaume Mazoyer wrote:

> I did some changes (the ones we talk on IRC) on my GTK 2.16 entry branch

Nice!

I did a pass over ExampleShowSomeone; I did do some minor comment
cleanup. See 'hackers/andrew/entry-icon'.

I think that example needs to use a TreeModelFilter rather than the
manual clear & repopulate you're doing now, but that doesn't matter
enough for me to block your branch.

One last thing, though: were you planning on *using* the Snapshots you
created? I think you need to add <img> to the Entry.java class javadoc
comment :)

Your branch is otherwise fine and will be merged to 'mainline'. If you
can just maybe do that one thing for the docs, that'd be great.

Cheers,

AfC
Sydney

Re: [java-gnome-hackers] ABI break; API bump?

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

Hello Andrew,

> If anyone has anything they want in, then now would be a good time.
I did some changes (the ones we talk on IRC) on my GTK 2.16 entry branch
[bzr/java-gnome/hackers/guillaume/entry-gtk-2.16/]. If you can take a
look to see if it's ready to be pulled in mainline it would be nice. And
of course, if it's ready to be pulled then pushed go ahead :)

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

Re: [java-gnome-hackers] ABI break; API bump?

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

Correcting the unicode behaviour is really important, so I'm going to do
the a bug fix release of java-gnome quite soon and without much fanfare.
If anyone has anything they want in, then now would be a good time.

AfC
Sydney