java-gnome-developer — For people using the bindings to write their own applications

Re: [Java-gnome-developer] Pixbuf

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

On Thu, 2010-08-26 at 14:54 -0300, Douglaz wrote:
> import javax.swing.JOptionPane;
> import org.gnome.gdk.Pixbuf;

You're trying to mix java-gnome and Swing. That's not going to work.

[I could go on at great length about why mixing toolkits is a bad idea,
but what's relevant here, even if it is briefly "working" for you, is
that no one can help you diagnose things like memory problems when two
entirely different mechanisms for talking to the native graphics
libraries are at play].

AfC
Sydney

[Java-gnome-developer] Pixbuf

[Douglaz <do...@gm...>]

Hello everyone!

    I'm writing a small application which is collecting the image from a few
ip cameras and showing them in a grid.
    In order to do so, I have a few threads collecting the bytes, creating
new Pixbuf object with those bytes, and updating a DataColumnPixbuf.

    I noticed an increase of the memmory usage as time goes by.
    Should I by using some method in order to free those unused Pixbuf
objects?
    Or is there a way to update these existing objects?

Best regards,
Douglas

ps.: In the following tiny test you can see the memmory increase (checking
the system resources):

package camera;

import javax.swing.JOptionPane;
import org.gnome.gdk.Pixbuf;
import org.gnome.gtk.Gtk;

public class Main {

    public Main() {
        super();
        Loader loader = new Loader();
        loader.start();
        JOptionPane.showMessageDialog(null, "Press ok to exit the program");
    }

    public static void main(String[] arsg) {
        Gtk.init(new String[] {});
        new Main();
        System.exit(0);
    }

    protected class Loader extends Thread {

        public void run() {
            while (true) {
                try {
                    Pixbuf p1 = new Pixbuf("camera.jpg");
                    Pixbuf p2 = new Pixbuf("camera.jpg");
                    Pixbuf p3 = new Pixbuf("camera.jpg");
                    sleep(200);
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }

    }

}

Re: [Java-gnome-developer] Grabbing default in a subclass of Dialog

[Richard S. <ri...@r-...>]

On 12/08/10 17:08, Kenneth Prugh wrote:

> It would seem that the Entry is interfering in this test case, as if
> you remove the Entry hitting enter activates the default button.

You are quite right. I removed the Entry field and played around with it
a bit more but still didn't have much success with the
dialog.setDefaultButton() method:

Havign set Apply as the default button, the dialog shows initially with
the Apply button focussed and pressing return invokes the apply
processing. However, having pressed Close, the next time the dialog is
opened, the Close button has become the default. I tried moving the
setDefaultButton() call around - into the handler that shows the dialog
for example, so that setDefaultButton() is called every time the dialog
is shown, but still the same.

I ened up with the flow I wanted (for a goto line dialog in a text
editor), by not using setDefaultButton() or setCanDefault() at all. I
just added an Entry.Activate() handler on the Entry that emits clicked
on the default button when I press return:

// Add close and apply buttons
final Button defaultButton = new Button(Stock.APPLY);
dialog.addButton(Stock.CLOSE, ResponseType.CLOSE);
dialog.addButton(defaultButton, ResponseType.APPLY);

// Connect the handler that shows the dialog
showDialogButton.connect(new Button.Clicked() {
	public void onClicked(Button source) {
		entry.setText("");
		entry.grabFocus();
		dialog.showAll();
	}
});

// Connect a handler to the entry for the default button
entry.connect(new Entry.Activate() {
	@Override
	public void onActivate(Entry source) {
		defaultButton.emitClicked();
	}
});

It's not ideal because, as a user, you get no feedback about which is
the default button. I notice that gedit neatly sidesteps the issue by
using a different type of control for goto line. ;)

-- 
Regards,

Richard Senior
IRC #java-gnome: san-ho-zay

Re: [Java-gnome-developer] Position of a Cell in a TreeView

[Douglaz <do...@gm...>]

Hello everyone!

   Just to let you know I found a way to make it happend, I implemented the
getCellArea() in the TreeView.
   I'll prepare a small test case later today and submit the changes once I
have the doc ready.

Best regards,
Douglas

2010/8/12 Douglaz <do...@gm...>

> Hello all!
>
>     Is it possible to get the position of a cell in a TreeView (x, y,
> width, heigh)?
>
> Best regards,
> Douglas
>

Re: [Java-gnome-developer] Grabbing default in a subclass of Dialog

[Kenneth P. <ken...@gm...>]

On Wed, 11 Aug 2010 14:02:12 +0100
Richard Senior <ri...@r-...> wrote:

> [...]
> 
> Sorry for the long and untidy code snippet but here's a test case that
> doesn't work for me:
> [...]

It would seem that the Entry is interfering in this test case, as if
you remove the Entry hitting enter activates the default button.

[Java-gnome-developer] Position of a Cell in a TreeView

[Douglaz <do...@gm...>]

Hello all!

    Is it possible to get the position of a cell in a TreeView (x, y, width,
heigh)?

Best regards,
Douglas

Re: [Java-gnome-developer] Grabbing default in a subclass of Dialog

[Richard S. <ri...@r-...>]

On 11/08/10 01:31, Andrew Cowie wrote:

> I've added coverage for setDefaultReponse() to Dialog, and merged it
> to 'mainline'. It'll be in java-gnome 4.0.17

Thanks Andrew,

I've grabbed the mainline source and compiled it, but I still can't get
it to work. I'm definitely using the 4.0.17-dev version.

Sorry for the long and untidy code snippet but here's a test case that
doesn't work for me:

package test;

import org.freedesktop.bindings.Version;
import org.gnome.gdk.Event;
import org.gnome.gtk.*;

public class TestDefaultButton {

	public TestDefaultButton() {

		// Create a main window
		Window window = new Window();
		window.setTitle("Default Button (Java-Gnome v" + Version.getVersion()
+ ")");
		window.setDefaultSize(600, 400);

		// Add a button to the main window that launches a dialog
		Button showDialogButton = new Button("Show Dialog");
		HBox hbox = new HBox(true, 0);
		hbox.packStart(showDialogButton, false, false, 0);
		VBox vbox = new VBox(true, 0);
		vbox.packStart(hbox, false, false, 0);
		window.add(vbox);

		// Create a dialog
		final Dialog dialog = new Dialog("Dialog", window, false);
		final Entry entry = new Entry();

		// Add a label and text entry to the dialog
		HBox hbox1 = new HBox(false, 5);
		hbox1.packStart(new Label("Enter text:"), false, false, 10);
		hbox1.packStart(entry, true, true, 5);
		VBox vbox1 = new VBox(true, 0);
		vbox1.packStart(hbox1, true, true, 10);
		dialog.add(vbox1);

		// Add close and apply buttons, making apply the default
		final Button defaultButton = new Button(Stock.APPLY);
		defaultButton.setCanDefault(true);
		dialog.addButton(Stock.CLOSE, ResponseType.CLOSE);
		dialog.addButton(defaultButton, ResponseType.APPLY);
		dialog.setDefaultResponse(ResponseType.APPLY);

		// Connect the handler that shows the dialog
		showDialogButton.connect(new Button.Clicked() {
			public void onClicked(Button source) {
				entry.setText("");
				entry.grabFocus();
				defaultButton.grabDefault();
				dialog.showAll();
			}
		});

		// Connect a window delete handler to the main window
		window.connect(new Window.DeleteEvent() {
			public boolean onDeleteEvent(Widget source, Event event) {
				Gtk.mainQuit();
				return false;
			}
		});

		// Connect the dialog response to print the content of the entry on
		// apply,
		// or to close the dialog on close
		dialog.connect(new Dialog.Response() {
			public void onResponse(Dialog source, ResponseType response) {
				if (response == ResponseType.APPLY) {
					System.out.println(entry.getText());
				}
				else {
					source.hide();
				}
			}
		});

		// Show the main window
		window.showAll();
	}

	public static void main(String... args) {
		Gtk.init(args);
		new TestDefaultButton();
		Gtk.main();
	}

}

-- 
Regards,

Richard

Re: [Java-gnome-developer] Grabbing default in a subclass of Dialog

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

On Tue, 2010-08-10 at 10:15 +0100, Richard Senior wrote:
> applyButton.setCanDefault(true);
> applyButton.grabDefault();
> 
> But when I show the dialog and press return, the default button isn't
> activated

> Am I missing something?

No and yes.

I just tried it with some very similar code that I have, and discovered
that likewise calling Widget's grabDefault() doesn't do it. Damn.

I poked around in the GTK docs, and it turns out there is a method
gtk_dialog_set_default_response(). Which works. You have to call
setCanDefault() on your custom Button first, though.

I've added coverage for setDefaultReponse() to Dialog, and merged it to
'mainline'. It'll be in java-gnome 4.0.17

AfC
Sydney

[Java-gnome-developer] Grabbing default in a subclass of Dialog

[Richard S. <ri...@r-...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm trying to create dialogs with default buttons but I can't get them
to work. I've subclassed org.gnome.gtk.Dialog and used addButton() in
the constructor like this:

Button applyButton = new Button(Stock.APPLY);
addButton(Stock.CLOSE, ResponseType.CLOSE);
addButton(applyButton, ResponseType.APPLY);

applyButton.setCanDefault(true);
applyButton.grabDefault();

But when I show the dialog and press return, the default button isn't
activated?

I tried exposing the button from the dialog class with a getter method
and calling dialog.getDefaultButton().grabDefault() after I'd shown the
dialog but that doesn't seem to work either.

Am I missing something?

- -- 
Regards,

Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxhGJ8ACgkQdPdD0eWqTe7VywCgtKe+f3nvF5V9aXajaJg2QVHE
i9oAoMaioq+D3kwhem95m0iAofVcXtKo
=Pp9U
-----END PGP SIGNATURE-----

Re: [Java-gnome-developer] Enabling and disabling cut/copy/delete actions based on text buffer selection

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

On Tue, 2010-08-03 at 11:32 +0100, Richard Senior wrote:

> public boolean onButtonReleaseEvent(Widget w, EventButton e) {

[snip]

> It does work, apart from one case. If I make a selection and then click
> _inside_ the selection with the mouse, the selection clears but in the
> handler above the buffer.getHasSelection() returns true. So my
> cut/copy/delete buttons remain enabled until I click again or press a key.
> ...
> Is there another event I could use?

I've always used Widget.ButtonPressEvent for this sort of thing; you
want to do your thing before GTK's default handers get to it.

[Widget.ButtonReleaseEvent is when you let go of the mouse, not when you
click it. I imagine you knew that, but you can sometimes fake yourself
our with what the right behaviour to hook into is. Same goes for key
presses; I work with Widget.KeyPressEvent most of the time, only rarely
does one need Widget.KeyReleaseEvent]

Anyway, give it a try and see how you go.

AfC
Sydney

[Java-gnome-developer] Enabling and disabling cut/copy/delete actions based on text buffer selection

[Richard S. <ri...@r-...>]

I've been experimenting with the Java-Gnome libraries over the past few
days and made good progress. It has been an enjoyable and remarkably
productive few days, and I am impressed with the results.

I set myself an exercise of creating a simple text editor. It is working
well but I've run into a problem enabling and disabling actions based on
whether there is a selection in the text buffer. I want to disable the
cut/copy/delete menus and corresponding toolbar buttons when there is
nothing selected in the edit pane and enable them when there is a selection.

My solution to checking for a selection isn't very elegant. I have a
pair of event handlers, one for button released and one for key
released, that do exactly the same thing:

@Override
public boolean onButtonReleaseEvent(Widget w, EventButton e) {

	if (JEditMainWindow.getInstance() != null) {

		// Get a reference to the text buffer
		TextBuffer b =
			JEditMainWindow.getInstance()
			.getEditorPane()
			.getSourceView()
			.getBuffer();

		// Use the action group to enable/disable on selection	
		JEditMainWindow.getInstance()
			.getActions()
			.getValidOnSelection()
			.setSensitive(b.getHasSelection());
	}

	return false;

}

It does work, apart from one case. If I make a selection and then click
_inside_ the selection with the mouse, the selection clears but in the
handler above the buffer.getHasSelection() returns true. So my
cut/copy/delete buttons remain enabled until I click again or press a key.

(For clarification, the way I have designed this is that JEditMainWindow
is a singleton and getActions() returns a Map that exposes the actions
and action groups for the application).

Is my approach to this wrong? Is there another event I could use?

-- 
Regards,

Richard

Re: [Java-gnome-developer] Possible bug

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

On Thu, 2010-07-01 at 22:04 +0200, Mauro Galli wrote:

> 	I'm trying to load java-gnome (4.0.15 Fedora official compile library
> and 4.0.16 rc1) 

We've had some recent patchces to make java-gnome work better on Fedora.
Perhaps you could try 'mainline' >= revno 739

[that was contributed since 4.0.16 was released, but it IS in the Fedora
package of java-gnome 4.0.16, so Alexander tells me, so perhaps you can
use that?]

AfC
Sydney

Re: [Java-gnome-developer] Added method setDrawText and get DrawText tio Scale.java

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

On Sun, 2010-07-04 at 23:00 +0200, Mauro Galli wrote:
> I added the getter and setter to draw or to hide the text of a scale
> object (HScale, VScale).

Patches (and discussion of patches) are best sent to the
java-gnome-hackers mailing list.

Thanks,

AfC
Sydney

[Java-gnome-developer] Added method setDrawText and get DrawText tio Scale.java

[Mauro G. <mau...@gm...>]

I added the getter and setter to draw or to hide the text of a scale
object (HScale, VScale).
Bye

[Java-gnome-developer] Path to Plumbing.java

[Mauro G. <mau...@gm...>]

The patch corrects the path of the native code used when java-gnome
library is loaded through URLClass loader.
Bye Mauro

Re: [Java-gnome-developer] Possible bug

[Serkan K. <se...@ge...>]

> I think to have a solution too, but I don't know how to submit it to
> you.
We have a guide[1] for submitting patches. It should be pretty easy if
you're already familiar with any VCS. I can help if there are any
problems though.

Regards,
Serkan KABA

1: http://java-gnome.sourceforge.net/4.0/HACKING.html

[Java-gnome-developer] Possible bug

[Mauro G. <mau...@gm...>]

Hello to the world,
	I'm trying to load java-gnome (4.0.15 Fedora official compile library
and 4.0.16 rc1) dinamically via URLClass loader, when I try to call the
Gtk.init() method it results in this error:
'We anticipated loading the native portion of java-gnome from:
file:/home/maurogalli/bin/SilenzioPlugins/gui/lib/libgtkjni-4.0.15-rc1.so
but didn't find the library there.'

I download the source and I find the possible problem in the
org/freedesktop/bindings/Plunbing.java class.

I think to have a solution too, but I don't know how to submit it to
you.

Mauro

PS Excuse for my English

Re: [Java-gnome-developer] Set window icon without org.gnome.gtk.Window?

[Ethan Tira-T. <ej...@cm...>]

>> I just want to set the application icon for the window in the task switcher so it's not just the generic java app icon.  I don't want to have to rewrite all the UI stuff though just for this minor issue
> 
> Maybe the Gtk.setDefaultIcon(Pixbuf) function is what you are looking
> for.

Ah, almost... I got excited there, but this only seems to work for windows which extend org.gnome.gtk.Window; if it uses JFrame it only gets the generic icon.

Just for reference how I've seen this addressed elsewhere, on OS X I can pass java -Xdock:icon=my_icon.png without having to modify any code... I quite like that solution for a basic branding issue like this.  Alternatively, OS X also uses system properties to control some UI options via the look and feel module (e.g. -Dapple.laf.useScreenMenuBar=true), so I'd expect they could have done the icon setting the same way... However, setting via -X to java probably lets them load the icon right from the get-go, to display even before the classes are done loading into memory... *shrug*

Anyway, doing some more searching, turns out Java 6 has this issue covered with a newly introduced "setIconImage" for the java.awt.Window, so I'm all set!
http://java.sun.com/javase/6/docs/api/javax/swing/JFrame.html#setIconImage(java.awt.Image)

Thanks!
-Ethan

Re: [Java-gnome-developer] Running File I/O Thread Crashes Java-Gnome

[Jester <jsn...@gm...>]

Hi Andrew and Kenneth,

I greatly appreciate your help! Setting GDK_NATIVE_WINDOWS=1 solves the issue
and everything is now running perfectly stable.

To give you some background: I'm based in San Francisco and am porting a
large-scale financial application from Swing to java-gnome. I could immediately
see the potential for a fist-class Java application on a gnome desktop when
playing with some of your examples and therefore was quite disappointed when I
encountered many instabilities that would crash the application within minutes
of launching it. As you can imagine the are multiple data streams coming in
simultaneously, all processed in parallel in their own worker threads, and that
is exactly what triggered the issue.

As Andrew mentioned the problem is not fixed and can be easily reproduced with
the sample code that I had posted earlier in this thread. It would be great if a
future version of java-gnome fixed this for good.

Adding a method to set native mode programmatically will come in handy and I'm
looking forward to 4.0.16.

By the way, the performance of java-gnome is rather good, even with this
workaround, and I'm extremely happy with my decision to focus on Linux/Gnome
while continuing to leverage the power of Java.

Thanks again, guys!

Jester

Re: [Java-gnome-developer] Set window icon without org.gnome.gtk.Window?

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

Hello,

> I'm guessing the answer will be no, in which case consider this a feature request, but basically I have a Java application, and I just want to set the application icon for the window in the task switcher so it's not just the generic java app icon.  I don't want to have to rewrite all the UI stuff though just for this minor issue.  Especially since that would kill the portability with other platforms.
> 
> Perhaps this can be done via the GTK look and feel properties?  Is that done in this group or is that another project (can you give a pointer?)
Maybe the Gtk.setDefaultIcon(Pixbuf) function is what you are looking
for.

Regards,

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

[Java-gnome-developer] Set window icon without org.gnome.gtk.Window?

[Ethan Tira-T. <ej...@cm...>]

I'm guessing the answer will be no, in which case consider this a feature request, but basically I have a Java application, and I just want to set the application icon for the window in the task switcher so it's not just the generic java app icon.  I don't want to have to rewrite all the UI stuff though just for this minor issue.  Especially since that would kill the portability with other platforms.

Perhaps this can be done via the GTK look and feel properties?  Is that done in this group or is that another project (can you give a pointer?)

Thanks,
  -Ethan

[Java-gnome-developer] java-gnome 4.0.16 released

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

There's a new version of java-gnome! It would have been a few days ago,
but we've all been watching the World Cup of course :)

Release notes
http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.16

Tarball
http://ftp.gnome.org/pub/gnome/sources/java-gnome/4.0/java-gnome-4.0.16.tar.bz2

Ubuntu package
https://launchpad.net/~java-gnome/+archive/ppa

Gentoo package
http://packages.gentoo.org/package/dev-java/java-gnome/


Anyone using java-gnome to develop lovely applications is, as ever,
invited to come hang out with us in #java-gnome on irc.gimp.net and chat
with us about what you're up to. We'd love to see you.
Cheers!

AfC
Sydney

Re: [Java-gnome-developer] Running File I/O Thread Crashes Java-Gnome

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

On Sun, 2010-06-06 at 20:27 +1000, Andrew Cowie wrote:

> $ GDK_NATIVE_WINDOWS=true java ...
> Works fine!

> Well. That would make this either:
> 
> i) a GTK bug
> 
> or
> 
> ii) a bug in the way that java-gnome is doing something to bind GTK,
> 
> or
> 
> iii) something you're not doing "correctly" as the developer using GTK
> (in light of the client-side window changes).

It is still not clear which of (i), (ii), or (iii) this problem is, but
we've added coverage of [org.gnome.gdk] Window's ensureNative() which
gives you access to the function which tells GDK to fall back to the old
pre 2.18 behaviour. So you can workaround the problem programatically
with

        widget.show();
        underlying = widget.getWindow();
        underlying.ensureNative();

Again I emphasize that this problem is not solved; fixed would be not
need to call this (for whichever reason) but at least this is another
step in the right direction.

This will be in java-gnome 4.0.16.

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-developer] Running File I/O Thread Crashes Java-Gnome

[Kenneth P. <ken...@gm...>]

On Sun, 06 Jun 2010 20:27:33 +1000
Andrew Cowie <an...@op...> wrote:

> On Sat, 2010-06-05 at 08:11 +0000, someone who still doesn't have a
> $ GDK_NATIVE_WINDOWS=true java -classpath
> ~/workspace/java-gnome/tmp/gtk-4.0.jar:tmp/classes/ DrawingWindow
> 
> Works fine!
> 
> Try it?

I can confirm that `export GDK_NATIVE_WINDOWS=1` causes no failures to
occur. With the jvisualvm profiler running I let the thread print up to
50,000 and no crash occurred.

Re: [Java-gnome-developer] Running File I/O Thread Crashes Java-Gnome

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

On Sat, 2010-06-05 at 08:11 +0000, someone who still doesn't have a real
name wrote:

> running the data retrieving part in a separate process (not just a separate
> thread).

That really shouldn't be necessary. You're either 

a) doing something horribly wrong.

or 

b) you've uncovered a nasty bug somewhere.

Given that worker threads and action handlers have been working fine for
us for years, I'm not entirely convinced it's (b), but it's always
possible that something has changed somewhere in the stack and that
you've hit something strange as a result.

On the other hand, it's not immediately obvious that you're doing (a),
so I'm not sure.

> which still causes the crash.

Yup.

What would be ideal is some kind of test case that ran automatically,
but that's not always easy. You've got it narrowed down fairly nicely as
it is.

You should probably open a bug now.

> This makes java-gnome unfit for many real-world application.

{shrug}

I know of a number of highly threaded apps that work just fine,
including several that I have written myself. So I'm not really sure I'd
agree with that sentiment, but then again I'm biased; java-gnome works
for everything I throw at it. So you're certainly not going to get my
goat with that one :)


> Your suggestion about sleeping the thread is good and I've tried this. My sleep
> time was 100ms per cycle 

That was just a debugging measure to slow things down a bit so we could
try and isolate what was happening. But personally, if I was dealing
with shorter sleeps I'd just Thread.yield().

The fact that it works fine for a while, then the DrawingArea stops
doing getting ExposeEvents is interesting. And that only happens when
you've started your worker thread. And not that the problem does *not*
happen if you terminate you app before the DrawingArea jams up.

It's *not* the whole app freezing, which is the behaviour you see if
you've somehow managed to block the main loop.

Which means it is something else.

> gdk_window_get_position: assertion `GDK_IS_WINDOW (window)' failed

"is window failed."
"isn't a window."
"isn't a GDK window."
"no window."
"no window?"
"client-side windows?"

Hmmm.

I wonder if this has something to do with the client-side windows
changes introduced in GTK 2.18? Well, the way to find out is to set
GDK_NATIVE_WINDOWS=true as an environment variable. That makes GTK fall
back to the deprecated-way-it-was to-be-removed-as
soon-as-all-the-bugs-are-fixed and-people-fix-their-apps behaviour.

$ GDK_NATIVE_WINDOWS=true java -classpath ~/workspace/java-gnome/tmp/gtk-4.0.jar:tmp/classes/ DrawingWindow

Works fine!

Try it?

++

Well. That would make this either:

i) a GTK bug

or

ii) a bug in the way that java-gnome is doing something to bind GTK,

or

iii) something you're not doing "correctly" as the developer using GTK
(in light of the client-side window changes).


My guess is that it is hopefully (iii) :) There are lots of people using
GtkDrawingAreas out there, so I can't imagine that if this were a GTK
problem it would have gone undetected this long. Under (ii) it _might_
be related to GC, or it might be somehow a change in how top level
Windows are reference counted. But I doubt that. We'll see.

Please open a bug. File it against java-gnome, and then we can consult
with the GTK hackers about the way forward [we may need to duplicate the
effect in C code to prove it's not a java-gnome or Java bug].

But before you do that, have a search of the GTK mailing list archives
for the last year or so. You'll see mention somwehere that some windows
have to explicitly request they be given a native X window to support
them if they need such a thing. My understanding was that GtkDrawingArea
already took care of this but in any case most GtkWidgets didn't need
such a thing because things would "just work". It's possible that the
interaction between us, GTK, and Cairo is confusing things. Anyway,
there may be a call we need to [add to java-gnome for you to] make.

AfC
Sydney

P.S. 

Note that you do NOT want this fallback as a global environment setting.
It's a major optimization for GTK and "the way ahead". The idea is to
fix the problematic usages, not rely on something that less performant
and deprecated.


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