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

[Java-gnome-developer] How can I access data/object in event callbacks?

[Michael S. <ml...@ko...>]

Hello all!

Using Glade I can associate data with signals. My question is: How can
I access this data in my callbacks? I could this when building a
calculator for example, where the callback of all buttons representing
digits could be the same.

Michael.

[Java-gnome-developer] JavaGTKMandel

[Markus F. <mar...@t-...>]

Hi!

There is a new example in the cvs-tree, at
/src/examples/gtk/mandel/

It should demonstrate how to use the low-level Gdk-classes
and some extraordinary event-handling. 
Since this is my first java-program, I would be
very glad if I get some feedback...

Markus Fritsche

RE: [Java-gnome-developer] java-gnome in debian

[Jeffrey M. <Jef...@Br...>]

> I'm wondering when the next release of java-gnome is due.

I am shooting for the last week in November or the first week 
in December.  

> 
> I have a program that uses java-gnome (works with the 0.7 release)
> that I want to include in the debian distribution.

Good. Can you give some information about the program.  I am
always encouraged to hear how people are using the bindings.

> 
> For this reason I would like to make a java-gnome debian package
> and include it in the distribution too.
> 
> Should I wait for a new release, or package release 0.7?

There has been significant work since the 0.7 release.  I would
recommend waiting for the next release if the time works for
you.  Let me know.

> 
> John Leuner
> 

-Jeff

[Java-gnome-developer] java-gnome in debian

[<je...@pi...>]

Hello

I'm wondering when the next release of java-gnome is due.

I have a program that uses java-gnome (works with the 0.7 release)
that I want to include in the debian distribution.

For this reason I would like to make a java-gnome debian package
and include it in the distribution too.

Should I wait for a new release, or package release 0.7?

John Leuner


---------------------------------------------
This message was sent using M-Web Airmail.
http://airmail.mweb.co.za/

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Jeffrey M. <Jef...@Br...>]

The code is now a fix in cvs.  I had to go back and 
re-familiarize myself with the way GdkEvent works.
GdkEvent is actually a union of all of the other
GDK Event objects.  The new usage will be to check its'
type and then call the appropriate getter to get the
correct event type.  For example:

public boolean zoomStart(GdkEvent event)
{
	if (event.getType().test(GdkEventType.BUTTON_PRESS)) {
		GdkEventButton e = event.getButton();
	} else {
		System.out.println("Something happend");
	}
	return(false);
}

I believe this should work with your example.

-Jeff


> 
> 
> Am Mittwoch, 7. November 2001 21:24 schrieb Jeffrey Morgan:
> 
> > Therefore when you tried to cast from
> > a GdkEvent to a GdkButtonEvent the Java runtime
> > didn't corporate.  Please try it with last nights
> > changes and let me know if this is still a problem.
> 
> I've tried it with the latest changes and the execution of 
> the callback 
> method stops (without any error) right at the point of casting.
> 
> MfG Markus
> 

Re: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Markus F. <mar...@t-...>]

Am Mittwoch, 7. November 2001 21:24 schrieb Jeffrey Morgan:

> Therefore when you tried to cast from
> a GdkEvent to a GdkButtonEvent the Java runtime
> didn't corporate.  Please try it with last nights
> changes and let me know if this is still a problem.

I've tried it with the latest changes and the execution of the callback 
method stops (without any error) right at the point of casting.

MfG Markus

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Jeffrey M. <Jef...@Br...>]

Hopefully this problem was fixed when I implemented
the inheritance.  Prior to the most recent change
GdkEvent and GdkButtonEvent both inherited from 
BaseBoxed but GdkButtonEvent didn't inherit from
GdkEvent.  Therefore when you tried to cast from
a GdkEvent to a GdkButtonEvent the Java runtime
didn't corporate.  Please try it with last nights
changes and let me know if this is still a problem.

-Jeff

> As for the zoom method, I have another question:
> 
> -----------------------------
> ...
> // the EventMask is configured properly
> drwarea.signalConnect("button_press_event", "zoomStart", this);
> ...
> public boolean zoomStart(GdkEvent event)
> {
> 	if (event.getType().test(GdkEventType.BUTTON_PRESS)) {
> 		System.out.println("button_pressed_event caught");
> 	} else {
> 		System.out.println("Something happend");
> 	}
> 	return(false);
> }
> ...
> -----------------------------
> 
> prints "button_pressed_event caught". So far, so good. But if 
> I try to 
> cast 
> 
> -----------------------------
> GdkEventButton e = (GdkButtonEvent) event;
> -----------------------------
> 
> nothing happens (the method seems to stop at the cast).
> When I try 
> 
> -----------------------------
> public boolean zoomStart(GdkEventButton event)
> -----------------------------
> 
> I get the warning (and, as you would expect, the method isn't called 
> :-))
> 
> -----------------------------
> *** WARNING ***: Java-GNOME - cannot find callback method zoomEnd in 
> the specified object with signature (Lgnu/gdk/GdkEvent;)Z
> -----------------------------
> 
> My fault? Lack of knowledge about gtk/gdk? Or feature? :-))
> 
> MfG Markus
> 

Re: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Markus F. <mar...@t-...>]

> You can now implement inheritance with define-boxed types.
> This should help you with GdkPixmap, GdkBitmap, etc.

Thank you!

> > Now I'm heading for a zoom function ;-)

> Great.  We have no example code in the bindings that demonstrate
> the low-level drawing classes.  If you would like to contribute
> your example I would be happy to add it.

Okay, I'll send it to you at the time the code is in a readable form, 
commented and fully functional (short: when it's no more embarrasing 
for me);-)

As for the zoom method, I have another question:

-----------------------------
...
// the EventMask is configured properly
drwarea.signalConnect("button_press_event", "zoomStart", this);
...
public boolean zoomStart(GdkEvent event)
{
	if (event.getType().test(GdkEventType.BUTTON_PRESS)) {
		System.out.println("button_pressed_event caught");
	} else {
		System.out.println("Something happend");
	}
	return(false);
}
...
-----------------------------

prints "button_pressed_event caught". So far, so good. But if I try to 
cast 

-----------------------------
GdkEventButton e = (GdkButtonEvent) event;
-----------------------------

nothing happens (the method seems to stop at the cast).
When I try 

-----------------------------
public boolean zoomStart(GdkEventButton event)
-----------------------------

I get the warning (and, as you would expect, the method isn't called 
:-))

-----------------------------
*** WARNING ***: Java-GNOME - cannot find callback method zoomEnd in 
the specified object with signature (Lgnu/gdk/GdkEvent;)Z
-----------------------------

My fault? Lack of knowledge about gtk/gdk? Or feature? :-))

MfG Markus

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Jeffrey M. <Jef...@Br...>]

You can now implement inheritance with define-boxed types.
This should help you with GdkPixmap, GdkBitmap, etc.

> 
> > as I stated in a previous email I
> > will soon add the ability to implement inheritance.
> 
> was what I wanted to add ;-)
> 
> By the way, my fractal generator is displaying Mandelbrot an Julia 
> (and, btw, about five times faster than the same program in 
> kylix :-)). 
> Now I'm heading for a zoom function ;-)
> 

Great.  We have no example code in the bindings that demonstrate
the low-level drawing classes.  If you would like to contribute
your example I would be happy to add it.

-Jeff

Re: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Markus F. <mar...@t-...>]

> as I stated in a previous email I
> will soon add the ability to implement inheritance.

I didn't saw that
---------------------------------------
(define-func gdk_draw_point
  none
  ((GdkPixmap window (object))
   (GdkGC gc)
   (int x)
   (int y)))
---------------------------------------
was what I wanted to add ;-)

By the way, my fractal generator is displaying Mandelbrot an Julia 
(and, btw, about five times faster than the same program in kylix :-)). 
Now I'm heading for a zoom function ;-)

MfG Markus

-- 
> Ich brauche nun argumente gegen einen Exchange Server als Mailserver.
Es gibt exakt zwei: Microsoft und Exchange Server.
						Robin S. Socha in dcoulm
ICQ: 133368240 Markus Fritsche http://www.planet-archer.de/

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Jeffrey M. <Jef...@Br...>]

> btw, I've added
> (define-func gdk_draw_point
>   none
>   ((GdkWindow window (object))
>    (GdkGC gc)
>    (int x)
>    (int y)))
> 
> to gdk.defs
> 

I'll add it to cvs shortly. 

Thanks
-Jeff

[Java-gnome-developer] gnome-postal classpath

[josh l. <jo...@st...>]

So, I grabbed the latest code from CVS and it looks really cool.  I
wanted to compile and look at the gnome-postal stuff so I just added
these two files for your classpath in the same way that the test/
scripts do...



josh

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Jeffrey M. <Jef...@Br...>]

> This is an artifact of the object wrapping, not of Gdk types 
> per se. The
> problem is that the code that is generated assumes it is 
> always generated
> for Gtk bindings. The code assumes that. What should be done 
> is to have a
> property for all objects to defined "what type" of object 
> they are. That
> property would then be properly inherited, eg. for example something
> like..

That is essentially what I am doing with "define-object" and 
"define-boxed".  The concept of define-object and define-boxed 
were not created in this project but were created and used in
several other language bindings (as were define-enum and 
define-flags)to differentiate between GtkObject objects and 
standard structures that do not have runtime type resolution 
capabilities.  define-boxed is also used for GTK objects
that don't have runtime discovery capabilities like GtkStyle.
In Java-GNOME the define-object type has been my primary focus, 
not define-boxed.  I have recently added the ability to have 
methods on define-boxed and as I stated in a previous email I 
will soon add the ability to implement inheritance.


> Then, when code is generated which requires to access the 
> underlying type
> mechanism, GtkFoo and GdkFoo at their code generation time 
> have access to
> information of which type they are.

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Santeri P. <sjp...@cc...>]

On Tue, 6 Nov 2001, Jeffrey Morgan wrote:
> Once you invoke a method that returns this type it
> will try to discover its' type at runtime using
> gtk_type_name(GTK_OBJECT_TYPE(peer)).  This will
> fail on a GDK object.  There also is a call
> to GTK_IS_OBJECT().  There is no runtime type
> identification of GDK objects and hence the
> "define-boxed".  This has been addressed to a
> large extent in Gnome 2 but I will not have a
> release that supports Gnome 2 until late January.

This is an artifact of the object wrapping, not of Gdk types per se. The
problem is that the code that is generated assumes it is always generated
for Gtk bindings. The code assumes that. What should be done is to have a
property for all objects to defined "what type" of object they are. That
property would then be properly inherited, eg. for example something
like..

	(define-object GtkObject ()
		(comment ...)
		(object-binding-type gtk))

	(define-object GdkObject ()
		(object-binding-type gdk))

	(define-object GtkFoo (GtkObject)
		...)

	(define-object GdkFoo (GtkObject)
		...)

Then, when code is generated which requires to access the underlying type
mechanism, GtkFoo and GdkFoo at their code generation time have access to
information of which type they are.

Due to Java object safety properties it is sufficient that GdkObject and
GtkObject are separate: it is not legal to pass a GdkObject to a method
which excepts GtkObject -- thus if any class descendant (or itself)
GtkObject is excepted, it is already known that the given object has the
property of being a GTK object. This property is due to the Java type
safety.

--
sa...@ik...                    I have become death, destroyer of the worlds.

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Jeffrey M. <Jef...@Br...>]

> 
> >Since GDK objects don't have this runtime
> >feature they cannot be defined as "define-object".
> 
> What is the difficulty? 
> (define-object GdkPixmap (GdkWindow))
> 
> seems to run fine. Or are there side effects?
> 

Once you invoke a method that returns this type it
will try to discover its' type at runtime using
gtk_type_name(GTK_OBJECT_TYPE(peer)).  This will
fail on a GDK object.  There also is a call
to GTK_IS_OBJECT().  There is no runtime type
identification of GDK objects and hence the 
"define-boxed".  This has been addressed to a 
large extent in Gnome 2 but I will not have a
release that supports Gnome 2 until late January.

-Jeff

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Markus F. <mar...@t-...>]

>Since GDK objects don't have this runtime
>feature they cannot be defined as "define-object".

What is the difficulty? 
(define-object GdkPixmap (GdkWindow))

seems to run fine. Or are there side effects?

>know how to create a valid constructor.  It is possible to create a new
>constructor for the object and have it added to the generated code.
>Perhaps GdkColor(int red, int green, int blue).  If you are not
>familiar with this process I could add it for you.

I've made it by this:
----------
gdkwindow = drawingarea.getWindow();
style     = drwarea.getStyle().copy();
color     = style.getFG(0);
gc        = new GdkGC(gdkwindow);
cmap      = new GdkColormap();
----------
now I'm able to allocate colors with the help of 
cmap and color and to use it for painting with gc.

btw, I've added
(define-func gdk_draw_point
  none
  ((GdkWindow window (object))
   (GdkGC gc)
   (int x)
   (int y)))

to gdk.defs

Thank you for your patience, Markus Fritsche

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Jeffrey M. <Jef...@Br...>]

> 
> What is the idea behind defining all Gdk classes boxed? 
> As I stated before, in gdk GdkPixmap and GdkBitmap are subclasses
> of GdkWindow, and can imho only used correctly if you have the
> methods of GdkWindow to operate on them.

Classes derived from GtkObject have certain runtime capabilities
that are utilized by the bindings.  Classes defined as "define-object"
use these capabilities.  Since GDK objects don't have this runtime
feature they cannot be defined as "define-object".  As I said
in my earlier email I haven't focused my efforts on the GDK objects.
I should be able to add inheritance to the "define-boxed" objects.
Give me a day or so.

> 
> As GdkColor is "boxed", I can't add new colors. Correct me if 
> I'm wrong,
> but I think that this way I could only change the default colors 
> that ".getStyle()" can give me?

I am not sure I understand your question.  You are correct that
the constructor for GdkColor is currently protected.  This is due
to the fact that there is no method in GDK to create a GdkColor
object (no gdk_color_new()) and therefore the code generator doesn't
know how to create a valid constructor.  It is possible to create a new 
constructor for the object and have it added to the generated code.
Perhaps GdkColor(int red, int green, int blue).  If you are not 
familiar with this process I could add it for you.

-Jeff

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Markus F. <mar...@t-...>]

Jeffrey Morgan (Jef...@Br...) wrote: 

>>> I have made significant changes to the
>>> way non-GtkObject classes are created and initialized
>>> and would recommend using the current CVS over the
>>> 0.7 build.

What is the idea behind defining all Gdk classes boxed? 
As I stated before, in gdk GdkPixmap and GdkBitmap are subclasses
of GdkWindow, and can imho only used correctly if you have the
methods of GdkWindow to operate on them.

>Generating javadocs is fairly easy.  In the src directory
>you need to type "make doc".  The generated javadocs are getting

Thank you, I didn't saw that...

>You are entering virgin territory.  I have spent very little time
>on the low-level drawing classes and have instead focus on the
>widgets.  I would be happy to help you work you way through this
>code (and fix a few bugs along the way).

As GdkColor is "boxed", I can't add new colors. Correct me if I'm wrong,
but I think that this way I could only change the default colors 
that ".getStyle()" can give me?

MfG Markus

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Jeffrey M. <Jef...@Br...>]

> > I have made significant changes to the
> > way non-GtkObject classes are created and initialized
> > and would recommend using the current CVS over the
> > 0.7 build.
> 
> Okay, I've downloaded the CVS-Version. Would you be so kind 
> to give me 
> a hint how to generate the api-docs using javadoc or the 
> sgml-files? As 
> I stated before, I'm new to the java world and not informed how to 
> generate this nice reference docs :-)
> 

Generating javadocs is fairly easy.  In the src directory
you need to type "make doc".  The generated javadocs are getting
better since I added the capability to insert comments into the
"define-object" and "define-func" structures.  This is new in
cvs.  Not all of these structures have comments at this time
but I hope to complete them prior to the next release.  I also
hope to add the ability to insert comments into the "define-boxed",
"define-enum", and "define-flags" prior to the next release.

You are entering virgin territory.  I have spent very little time
on the low-level drawing classes and have instead focus on the
widgets.  I would be happy to help you work you way through this
code (and fix a few bugs along the way).

-Jeff

Re: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Markus F. <mar...@t-...>]

> I have made significant changes to the
> way non-GtkObject classes are created and initialized
> and would recommend using the current CVS over the
> 0.7 build.

Okay, I've downloaded the CVS-Version. Would you be so kind to give me 
a hint how to generate the api-docs using javadoc or the sgml-files? As 
I stated before, I'm new to the java world and not informed how to 
generate this nice reference docs :-)

Thank you for your patience, Markus Fritsche

-- 

RE: [Java-gnome-developer] Question concerning pixel graphics (fw d)

[Jeffrey M. <Jef...@Br...>]

> When I try 
> \.\...
> GtkWidget w = win.getTopLevel();
> GdkColormap cmap = w.getDefaultColormap();
> \.\...
> the application crashes. No idea why...
> 

Are you using the code currently in CVS?  I just
tried the above method calls and didn't have any
problem.  I have made significant changes to the
way non-GtkObject classes are created and initialized
and would recommend using the current CVS over the
0.7 build.

-Jeff

Re: [Java-gnome-developer] Question concerning pixel graphics (fwd)

[Markus F. <mar...@t-...>]

Santeri Paavolainen (sjp...@cc...) wrote: 

>Hmm, if I remember correctly you have to alloc the color from the window's
>colormap, since gc needs a pixel value, which in turn is only allocated
>(or determined for truecolor displays) at that phase. What happens now is
>that the pixel value has a default of 0, which usually is black on indexed
>color displays and black on truecolor displays.

When I try 
\.\...
GtkWidget w = win.getTopLevel();
GdkColormap cmap = w.getDefaultColormap();
\.\...
the application crashes. No idea why...

MfG Markus

Re: [Java-gnome-developer] Question concerning pixel graphics (fwd)

[Markus F. <mar...@t-...>]

Santeri Paavolainen (sjp...@cc...) wrote: 

>Hmm, if I remember correctly you have to alloc the color from the window's
>colormap, since gc needs a pixel value, which in turn is only allocated
>(or determined for truecolor displays) at that phase. What happens now is
>that the pixel value has a default of 0, which usually is black on indexed
>color displays and black on truecolor displays.

When I try 
\.\...
GtkWidget w = win.getTopLevel();
GdkColormap cmap = w.getDefaultColormap();
\.\...
the application crashes. No idea why...

MfG Markus

Re: [Java-gnome-developer] Question concerning pixel graphics (fwd)

[Santeri P. <sjp...@cc...>]

On Mon, 5 Nov 2001, Markus Fritsche wrote:
> So far, so good. I've made it by changing the gdk.defs-file. The next
> thing is, that I don't know how to draw things in a different color
> than black. I thought it should be something like this:
> \.\...
> GdkGC gc = new GdkGC(mainwindow.getWindow());
> GdkColor red = new GdkColor();
> red.parse("red");
> gc.setForeground(red);
> gwin = drawingarea.getWindow();
> gwin.drawRectangle(gc, false, 10, 10, 10, 10);
> \.\...
> should, afaic, draw a red rectangle into the drawingarea. But a black
> rectangle is drawn.
>
> Btw. shouldn't GdkPixmap and GdkBitmap be subclasses of GdkWindow,
> as in gdk?

Hmm, if I remember correctly you have to alloc the color from the window's
colormap, since gc needs a pixel value, which in turn is only allocated
(or determined for truecolor displays) at that phase. What happens now is
that the pixel value has a default of 0, which usually is black on indexed
color displays and black on truecolor displays.

If that doesn't help, I'll take a look at my own code when I get to home
later, and check the correct calling sequence.

--
sa...@ik...                    I have become death, destroyer of the worlds.

Re: [Java-gnome-developer] Question concerning pixel graphics

[Markus F. <mar...@t-...>]

> For learning about java-gnome and java, I'm programming a mandelbrot
> generator. So, I'd like to know how I could access single pixels in a
> pixmap or a widget.
So far, so good. I've made it by changing the gdk.defs-file. The next
thing is, that I don't know how to draw things in a different color
than black. I thought it should be something like this:
\.\...
GdkGC gc = new GdkGC(mainwindow.getWindow());
GdkColor red = new GdkColor();
red.parse("red");
gc.setForeground(red);
gwin = drawingarea.getWindow();
gwin.drawRectangle(gc, false, 10, 10, 10, 10);
\.\...
should, afaic, draw a red rectangle into the drawingarea. But a black
rectangle is drawn.

Btw. shouldn't GdkPixmap and GdkBitmap be subclasses of GdkWindow,
as in gdk?

Where am I wrong?