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

[java-gnome-hackers] fixed

[Mark H. <mh...@ca...>]

Hi,
  I've just tried the latest code from cvs and things seem a lot better
than the last time I looked. Thanks for all the excellent work everyone,
especially Tom. 
  Over Christmas I started a project for displaying and editing Debian
bug reports. Currently the only way to do this is via email or a poor
web interface (http://bugs.debian.org), so this program should be very
useful (I have certainly found it useful). If Tom is able to create this
InvokeLater method in the next few weeks, I will develop this program
further and make a release of it, hopefully having the results that many
more people get interested in java-gnome and start contributing patches.
I finish uni in two weeks, so should hopefully be able to start
contributing again at that time.
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] Native error handling

[Tom B. <Tom...@Su...>]

The various GNOME error and warning messages that get displayed to the
console were bothering me, so I implemented log handlers for the
libraries we use.  These handlers throw a RuntimeException with the
error message inside.  

Is something like this of interest to you folks?  Regardless of what
gets designed, we need some sort of error reporting strategy.  I like
using RuntimeExceptions because they are easier for an application
writer to manage than log handlers (just add a catch block).  Another
option is some sort of Error event and listener, but then errors would
get reported after the offending method invocation, rather than during
it.

Tom

Re: [java-gnome-hackers] Welcome back, Philip!

[Tom B. <Tom...@Su...>]

On Thu, 2003-02-27 at 10:07, Tom Ball wrote:
> If you are looking for a hard problem, Mark and I are seeing lots of
> assertion failures.  The ones on my system are caused when
> org_gnu_glib_GObject.c tries to copy a widget parameter (Containers fire
> signals with child parameters) in jg_signal_cb in the "default" case
> block.  If you can shed any light here, that would be great.

Fixed:

diff -r1.7 org_gnu_glib_GObject.c
198c198
<       *(void **) &peer = g_value_get_pointer(&param_values[i]);
---
>       *(void **) &peer = g_value_get_object(&param_values[i]);

I guess GLib-2.0 has stronger type checking...

Tom

Re: [java-gnome-hackers] WeakReferences going away

[Philip A. C. <pch...@pc...>]

On Thu, 2003-02-27 at 12:10, Tom Ball wrote:
> In this case, I think the problem is related to my style of app
> development:  I never keep listener references in my app, but instead
> just attach them to a widget and forget about them:
>=20
> 	Button cancelButton =3D fontsel.getCancelButton();
> 	cancelButton.addListener(new ButtonListener() {
> 		public void buttonEvent(ButtonEvent event) {
> 		    if (event.isOfType(ButtonEvent.Type.CLICK)) {
> 			fontsel.destroy();
> 		    }
> 		}
> 	    });
>=20

Yes, this does seem to be an issue of coding style.  Many, many code
examples of Swing use inner classes as event handlers.  Not to start any
flame wars, but I *personally* dislike inner classes and very rarely (if
ever) use them.  However, my personal preference does not matter.  Java
allows developers to do this and many swing developers (and some IDEs w/
GUI designers) use this heavily.  Therefore, we should code to support
*both* methods.  (Disclaimer:  I realize that the use of inner classes
are not the only possible cause of this problem, but would probably be
the most likely.)

> But there I think good documentation is the best one can do here.

Then good documentation it shall be.  Even if this weren't a problem,
good documenatation is a must.  :-)

> If memory isn't too big an issue (or if we want to create a "debug"
> version of our libraries), we can keep a WeakReference'd static list in
> each listener class of the current listeners and what widget they are
> listening to.  Some key sequence (such as Ctl-Shift-F10) can trigger the
> dumping of this list out to the command line for debugging purposes.=20
> This beats poking around in a heap profiler, and is much more likely to
> be used by app developers.  If you want, I can add this feature soon.

I think that this would be a *very* nice feature in a "debug" version.

--=20
Philip A. Chapman

Application Development:
Java, Visual Basic (MCP), VB for Applications, PostgreSQL, MySQL, MSSQL
Linux, Windows 9x, Windows NT, Windows 2000, Windows XP

Re: [java-gnome-hackers] WeakReferences going away

[Tom B. <Tom...@Su...>]

On Thu, 2003-02-27 at 09:20, Philip A. Chapman wrote:
> The original thought was to protect from memory leaks.

Yes, dangling listeners can be a major source of object leaks.

> The problem is that sometimes developers do not call the remove method
> to remove their listener before releasing all other references in their
> code to the listener object.  This leaves the reference in the listener
> list as the only reference to the listener and the listener is never
> garbage collected.
> 
> Granted, this is a developer issue in that they *should* always call the
> remove method first.  The hope was to give some protection against such
> sloppy programming from causing big problems.

Paranoid, perhaps, not altruistic. :-)  One way to solve this is to
provide good example code -- developers tend to slavishly copy examples,
and as we learned the hard way with Swing, bad examples foster
widespread bad toolkit use.

In this case, I think the problem is related to my style of app
development:  I never keep listener references in my app, but instead
just attach them to a widget and forget about them:

	Button cancelButton = fontsel.getCancelButton();
	cancelButton.addListener(new ButtonListener() {
		public void buttonEvent(ButtonEvent event) {
		    if (event.isOfType(ButtonEvent.Type.CLICK)) {
			fontsel.destroy();
		    }
		}
	    });

In this example, the only reference to the ButtonListener is in
cancelButton's listener list, which is why it gets GC'd if that list is
implemented with WeakReferences.  This style of listener usage is very
common among AWT and Swing developers; that doesn't make it necessarily
correct usage, but I can testify that it is bewildering for such a
developer to have one's listeners "disappear" after installing them this
way.

Now, if an application class either implements the listener interface
directly or stores the reference, then you have the potential leakage
you describe since the app instance won't be GC'd.  But there I think
good documentation is the best one can do here.

> If it's causing too much trouble, can it be reworked?  If not, I'd say
> remove it.  Maybe the idea was too altruistic.

If memory isn't too big an issue (or if we want to create a "debug"
version of our libraries), we can keep a WeakReference'd static list in
each listener class of the current listeners and what widget they are
listening to.  Some key sequence (such as Ctl-Shift-F10) can trigger the
dumping of this list out to the command line for debugging purposes. 
This beats poking around in a heap profiler, and is much more likely to
be used by app developers.  If you want, I can add this feature soon.

Tom

[java-gnome-hackers] Welcome back, Philip!

[Tom B. <Tom...@Su...>]

On Thu, 2003-02-27 at 09:20, Philip A. Chapman wrote:
> BTW, Off topic:  I've been away for quite a while because of insane work
> schedules.  I'm hoping to get involved again in the next few weeks. 
> What is still outstanding to be done?

Work insanity seems rampant these days.  My own project was almost
cancelled at SunLabs, and now I need to focus on it more in spite of my
management's former support of my Java-GNOME help.  

In general, the biggest area that needs work are the examples and
demos.  That may seem like junior-level work, but they uncover lots of
problems in the toolkit that a senior-level engineer needs to
investigate.  Since these are also our best documentation, they deserve
extra scrutiny to make sure they are using the toolkit in the manner we
want them to.

If you are looking for a hard problem, Mark and I are seeing lots of
assertion failures.  The ones on my system are caused when
org_gnu_glib_GObject.c tries to copy a widget parameter (Containers fire
signals with child parameters) in jg_signal_cb in the "default" case
block.  If you can shed any light here, that would be great.

Tom

Re: [java-gnome-hackers] WeakReferences going away

[Philip A. C. <pch...@pc...>]

On Thu, 2003-02-27 at 10:38, Tom Ball wrote:
> It appears that org.gnu.gtk is misusing the WeakReference class to store
> its event listeners.  On my system, widgets that are initially
> responsive to events quickly stop being responsive, even with simple
> Java-GNOME example apps.  The problem is that the app's event listeners
> are being GC'd even though the widgets they are listening to are still
> live.
>=20
> Unless anyone objects soon, I want to check in this "WeakReference-free"
> delta.

Tom,

The original thought was to protect from memory leaks.

The problem is that sometimes developers do not call the remove method
to remove their listener before releasing all other references in their
code to the listener object.  This leaves the reference in the listener
list as the only reference to the listener and the listener is never
garbage collected.

Granted, this is a developer issue in that they *should* always call the
remove method first.  The hope was to give some protection against such
sloppy programming from causing big problems.

If it's causing too much trouble, can it be reworked?  If not, I'd say
remove it.  Maybe the idea was too altruistic.

BTW, Off topic:  I've been away for quite a while because of insane work
schedules.  I'm hoping to get involved again in the next few weeks.=20
What is still outstanding to be done?

--=20
Philip A. Chapman

Application Development:
Java, Visual Basic (MCP), VB for Applications, PostgreSQL, MySQL, MSSQL
Linux, Windows 9x, Windows NT, Windows 2000, Windows XP

[java-gnome-hackers] WeakReferences going away

[Tom B. <Tom...@Su...>]

It appears that org.gnu.gtk is misusing the WeakReference class to store
its event listeners.  On my system, widgets that are initially
responsive to events quickly stop being responsive, even with simple
Java-GNOME example apps.  The problem is that the app's event listeners
are being GC'd even though the widgets they are listening to are still
live.

A WeakReference is supposed to be used for cases where it's okay for a
reference to go away, usually because it can be recreated.  The classic
example is with a cache; if a lookup is expensive, you cache the result
in a hashtable using a WeakReference (or just use WeakHashMap) -- if the
cache gets emptied by the garbage collector, it just means more
lookups.  The cache may have an entry disappear, but the caller never
knows this because the cache is a hidden implementation detail.

Event listeners need to remain permanently attached to their respective
widgets, however; they are not transitory in any way.  When I remove all
of the WeakReference use in GTK, the problem goes away as it should.  It
also simplies the event handling code quite a bit, and most likely
speeds it up as well.  I suspect there's a lot more potential for shared
code now, too.

Unless anyone objects soon, I want to check in this "WeakReference-free"
delta.

Tom

Re: [java-gnome-hackers] assertion failure

[Tom B. <Tom...@Su...>]

One temporary hack is to turn off Container event handling by commenting
out the "addEvents(evtMap);" line.  The problem appears to be in
callbacks that pass back a widget -- container signals just happen to do
this a lot.  The assertion occurs because the widget handle is null when
we try to fetch it.  I still haven't figured out why it's null, however.

Tom

On Wed, 2003-02-26 at 04:34, Mark Howard wrote:
> On Tue, 2003-02-25 at 22:02, Tom Ball wrote:
> > Is anyone else seeing the following repeated assertion failure?
> 
> I get it all the time. Very often related to the text and tree widgets.
> I also get terrible performance when trying to enter text into text
> widgets, which I have so far assumed is related.
> 
> > and it's getting called regularly.  Any ideas why?
> Unfortunately not.
> 
> possibly related:
> I tried debugging a crash which looked similar some time ago. It
> appeared as if the location of the peer was often randomly set to 0x14
> sometime during a glib call - the glib source code for this function
> could not have done this though.
> I always get crashes like this after any event occurs when running in
> either Blackdown 1.4.1beta or gcj natively compiled. (but kaffe works
> fine for me). 
> Other people have also reported this crashing on the 
> 
> jav...@li...
>  mailing list.
-- 
Tom Ball <Tom...@Su...>

Re: [java-gnome-hackers] assertion failure

[Mark H. <mh...@ca...>]

On Tue, 2003-02-25 at 22:02, Tom Ball wrote:
> Is anyone else seeing the following repeated assertion failure?

I get it all the time. Very often related to the text and tree widgets.
I also get terrible performance when trying to enter text into text
widgets, which I have so far assumed is related.

> and it's getting called regularly.  Any ideas why?
Unfortunately not.

possibly related:
I tried debugging a crash which looked similar some time ago. It
appeared as if the location of the peer was often randomly set to 0x14
sometime during a glib call - the glib source code for this function
could not have done this though.
I always get crashes like this after any event occurs when running in
either Blackdown 1.4.1beta or gcj natively compiled. (but kaffe works
fine for me). 
Other people have also reported this crashing on the 

jav...@li...
 mailing list.
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] assertion failure

[Tom B. <Tom...@Su...>]

Is anyone else seeing the following repeated assertion failure?

(java-gnome:11690): GLib-GObject-CRITICAL **: file gvaluetypes.c: line
803 (g_value_get_pointer): assertion `G_VALUE_HOLDS_POINTER (value)'
failed

In org_gnu_glib_GObject.c:jg_signal_cb I added the following at line
233:

if (!G_VALUE_HOLDS_POINTER(&param_values[i]))
    printf("couldn't find Java peer\n");

and it's getting called regularly.  Any ideas why?

Tom

Re: [java-gnome-hackers] threads

[Mark H. <mh...@ca...>]

On Mon, 2003-02-24 at 18:44, Tom Ball wrote:
>  Unless you want to develop it, Mark, I'll come up with a
> proposal for some sort of invokeLater.
Go for it. 


Timer:
>  A code review
> by anyone who has the time would be appreciated, however.
I'll have time in about 3 weeks :)
Will you also create a simple example application for this please. 

> Are there really different types of timers?
I guess there aren't many and if they are then they would be better
served by writing a completely custom timer, or using the invokeLater
method. I was just thinking about what we had been told about the Java
Thread class when I wrote the suggestion.
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] threads

[Tom B. <Tom...@Su...>]

On Fri, 2003-02-21 at 04:52, Mark Howard wrote:
>   I think you've already found that gtk, like swing, requires that
> almost all graphics operations must be performed in a single thread. 

Thanks for the information; this confirms my guess.  Over the years I've
found that there are very few toolkits that truly support
multi-threading, and those that do require that the app writer jump
through lots of hoops.  If I could change only one thing in Java's core
libraries, I would make the AWT's threading model single-threaded. 
"Keep it simple" as an app model saves everyone a lot of pain later.

> Your timer looks interesting, but I think this would only be useful for
> a limited number of cases. Perhaps it would be more useful to create
> methods similar to SwingUtilities.invokeAndWait(Runnable) and
> SwingUtilities.invokeLater(Runnable), which execute the run method of
> the given class in the graphics thread. These methods are used for
> everything which updates the display from additional threads. 

We have a general problem in that there is no way to create new event
sources in Java-GNOME, which I think is a big hole.  Just implementing
the related GLib functions isn't the answer, however, as that conflicts
with the new event API that Jeffrey designed.  An invokeLater
(invokeAndWait can be easily abused by developers) method would be both
useful and allow us more time to design a proper event source API
later.  Unless you want to develop it, Mark, I'll come up with a
proposal for some sort of invokeLater.

> I was going to suggest at this point that Timer could be based on those,
> but now realise that it would probably have severe performance issues.
> So it's probably best if we have both a timer and invokeLater (or
> similar) methods.

I agree.  If there had been an invokeLater-type interface, I would have
used it, but timers in general really do deserve special treatment
(which is probably why GLib's main loop functions include timer
support).  The Timer code turned out to be quite small, and it actually
worked the first time (gasp!).  By following advice in the JNI manual
and Effective Java, I think the code is close to right.  A code review
by anyone who has the time would be appreciated, however.

> For your API Proposal, I would suggest that you make it more like the
> Thread class, in that the user can either override it (e.g. if they want
> to change it's functionality), or they can supply a Runnable object to
> its constructor (when they want to use the default behaviour).

I think the right answer is a combination of these:  make the class
final (there really isn't any functionality that makes sense to change),
but take a Runnable in its constructor.  I have strong opinions
regarding the correct use of inheritance versus composition, and believe
that inheritance should be reserved for "is a" relationships between
object types, while "have a" relationships should use composition.  

Are there really different types of timers?  Maybe one-shots and
recurrent ones, but one-shots are handled by your invokeAndWait
suggestion.  My guess is that the only difference between recurring
timers are their interval and the code they execute, and these can be
handled by specifying them in a constructor.  My guess is that
application classes normally "have a" timer rather than being one, so
unless there are strong objections, I'll modify Timer to require a
Runnable and interval in its constructor.

Thanks for your feedback,
Tom

[java-gnome-hackers] threads

[Mark H. <mh...@ca...>]

Hi,
  I've been looking again at the gtk code. I'm not sure if this is new
for gtk 2.2 - I'm sure it wasn't there when I looked last year.

Apparently, Gtk methods can be called from multiple threads, if all  are
enclosed within  gdk_threads_enter()/ gdk_threads_leave() statements
(with a gtk_flush() before the leave()).g_thread_init() and
gdk_threads_init() must also be called from each thread.

Unfortunately I don't have enough time at the moment to look at this in
more detail. I'm not sure whether the enter/leave calls have to be made
if the code is running in the main thread - If they don't, then we could
make modifications easily to allow multiple threads. If they do, then
this may simply mean that the user has to make calls to enter/leave
before modifying the gui. Most callbacks are done in the graphics
thread.
I am also confused by the examples having:
gdk_threads_enter ();
  gtk_main ();
gdk_threads_leave ();
wouldn't this block any other threads acquiring the lock?

Relevant web pages are:
http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html#id2848858
http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] API proposal: org.gnu.gdk.Timer

[Sergio R. <ser...@hi...>]

Short and easy to use :). But you know, it's my real humild opinion.
I'm looking foward to see the native implementation.

Great!

PD. It's great to know that someone overthere is still alive, it seems
that studies and work are driving the team crazy :)

Best wishes.

On Fri, 2003-02-21 at 08:07, Tom Ball wrote:

> 
> Please review the attached, and bring up any problems or improvements
> you can think of.  Once the idea is accepted and the API agreed upon,
> I'll go ahead and implement the native methods.
> 
> Tom
> ----
-- 
Sergio Rubio < http://rubiojr.dragon-lance.net >

IF THEN THEN THEN = ELSE; ELSE ELSE = THEN (Lenguaje PL/I)
		
			(atribuido a Flex y los lexers)

[java-gnome-hackers] threads

[Mark H. <mh...@ca...>]

Hi,
  I think you've already found that gtk, like swing, requires that
almost all graphics operations must be performed in a single thread. 

Your timer looks interesting, but I think this would only be useful for
a limited number of cases. Perhaps it would be more useful to create
methods similar to SwingUtilities.invokeAndWait(Runnable) and
SwingUtilities.invokeLater(Runnable), which execute the run method of
the given class in the graphics thread. These methods are used for
everything which updates the display from additional threads. 

I was going to suggest at this point that Timer could be based on those,
but now realise that it would probably have severe performance issues.
So it's probably best if we have both a timer and invokeLater (or
similar) methods.

For your API Proposal, I would suggest that you make it more like the
Thread class, in that the user can either override it (e.g. if they want
to change it's functionality), or they can supply a Runnable object to
its constructor (when they want to use the default behaviour).

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] API proposal: org.gnu.gdk.Timer

[Tom B. <Tom...@Su...>]

Although there isn't an equivalent class in GNOME, I'd like to propose
adding a timer class to Java-GNOME.  There is a timeout facility in
GObject, but it involves several API that aren't implemented and IMHO
doesn't easily map to Java concepts.  Timers are really useful for
various UI metaphors; in my case, I need one to report status in a
system monitoring app.

Instead, attached is a proposed Timer class which seems to belong in
org.gnu.gdk.  To use, a developer subclasses it, implements its "run()"
method, and specifies a time interval.  This method is executed when the
interval elapses as if it were an event -- same GLib Main event loop,
same thread, etc.  It should therefore be safe to execute any valid
GNOME code within the run method without thread safety or other worries.

Here's a simple clock label class, which an application might use in its
status line:

import org.gnu.gtk.Label;
import org.gnu.gdk.Timer;
import java.text.DateFormat;
import java.util.Date;

public class Clock extends Timer {
   private Label clockPane;

   public Clock(Label pane) {
      super(1000);  // 1 second timer interval
      clockPane = pane;
      start();
   }

   public void run() {
      String dateStr = DateFormat.getDateInstance().format(new Date());
      clockPane.setText(dateStr);
   }
}

Please review the attached, and bring up any problems or improvements
you can think of.  Once the idea is accepted and the API agreed upon,
I'll go ahead and implement the native methods.

Tom

[java-gnome-hackers] How to fire a new event?

[Tom B. <Tom...@Su...>]

Is there any way to tell Java-GNOME to fire a new event type? 
GObject.addEventHandler is used to connect an event handler, but I can't
find any way to emit a signal.

Tom

Re: [java-gnome-hackers] Java-Gnome thread model?

[Tom B. <Tom...@Su...>]

An alternative to a timer thread is to use gtk_timeout_add(), which
isn't one of the calls we support.  Is it okay if I just add that
support, or do I need to regenerate the file somehow?

Tom

On Thu, 2003-02-20 at 11:28, Tom Ball wrote:
> Hi all,
> 
> What's the thread model for Java-GNOME development?  Swing requires that
> all GUI updating happen on the event dispatch thread, while the AWT
> pretends it's fully multithreaded.  I haven't found any documentation
> suggesting threading rules for Java-GNOME, but there also isn't much
> synchronization effort either.
> 
> What's prompting this question is that I'm writing a GUI front-end for
> Sun's VPN client using Java-GNOME, which will have a status window (a
> GtkTextView) updated by a timer.  Since I couldn't find any timers in
> Java-GNOME, I'm writing a simple one that just loops in a separate
> thread.  Can this thread directly set the TextBuffer's text, or should
> it conj an event to do it on the main thread?
> 
> Tom
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
-- 
Tom Ball <Tom...@Su...>

[java-gnome-hackers] Java-Gnome thread model?

[Tom B. <Tom...@Su...>]

Hi all,

What's the thread model for Java-GNOME development?  Swing requires that
all GUI updating happen on the event dispatch thread, while the AWT
pretends it's fully multithreaded.  I haven't found any documentation
suggesting threading rules for Java-GNOME, but there also isn't much
synchronization effort either.

What's prompting this question is that I'm writing a GUI front-end for
Sun's VPN client using Java-GNOME, which will have a status window (a
GtkTextView) updated by a timer.  Since I couldn't find any timers in
Java-GNOME, I'm writing a simple one that just loops in a separate
thread.  Can this thread directly set the TextBuffer's text, or should
it conj an event to do it on the main thread?

Tom

Re: [java-gnome-hackers] handle->GObject mapping needed

[Tom B. <Tom...@Su...>]

On Thu, 2003-01-09 at 01:52, Mark Howard wrote:
> On Sat, 2003-01-04 at 06:37, Tom Ball wrote:
> > 1.  Store an JNI object reference in the native gobject.  GTK has the
> > ability to add named properties using g_object_set, so this is
> > workable.  The AWT uses this method.
> 
> I guess this would take longer when creating all widgets as more jni
> calls are required. 

Not very long, as downcalls (Java->JNI) are very fast while upcalls are
slow.  I doubt we're creating thousands of widgets per second; one extra
JNI call per widget *creation* shouldn't impact performance.  

Also, this only applies to widgets that are created from handles;
widgets which call GTK to create their native counterparts can store the
handle in that same call. 

> Would the reference be created using (*env)->NewGlobalRef so that the GC
> doesn't free it?

Right.

> If so, how will this reference be removed to allow the Java object to be
> freed?

In the widget's destroy method.  

> If not, then what will happen if the user does not keep a reference to
> the Java object

One issue we haven't faced is that it is currently possible for a Java
widget to be gc'd without its handle being destroyed, causing an object
leak in the underlying toolkit.  This probably hasn't been a problem
because our test programs are not long-lived, but may indeed be a
serious issue when real apps using our library are created and used
(like the email client).  Doing better cleanup will address this issue.

> > 2.  Maintain a hashtable to map handles to GObjects, and use a factory
> > method instead of constructors to look up or create GObjects from
> > handles.
> Constructors would still be used when constructing a new widget.
> Factory methods would be used when accessing an existing object (or at
> least existing in the native sense). 
> Why is this a problem? IMHO, it makes more sense than having everything
> done in constructors.

One reason I like using public factory methods *instead* of public
constructors is that when designed well they can simplify library use. 
Josh Bloch describes their benefits in great detail in Effective Java,
which I highly recommend.

Still, I am not pushing for a big API overhaul -- I'd rather see 0.8 get
released.

Tom

[java-gnome-hackers] Re: [Java-gnome-developer] Possibility to built SWING on top uf Java-GTK?

[Tom B. <Tom...@Su...>]

On Thu, 2003-01-09 at 05:22, Bill Haneman wrote:
> > Furthermore... I want to run it as native machine-code, I really don't like the 
> > smell of virtual machines altogether. :)
> > 
> > The only real political question I can see is... do people really want Swing 
> > apps depending on JNI? I can only speak for myself, but I sure as s*** don't 
> > mind one bit. In fact I favour it more than than that childish 
> > (flames to /dev/null) pure-Java concept.
> 
> This may not be feasible without going through the (ugh) JCP. 

No, that's not true.  Apple's Swing L&F makes some native calls, and it
looks like this is increasing with each release.  As long as Swing's
public API isn't changed (which Apple didn't), then it doesn't matter
how it is implemented.

> Anyhow, you might want to try Swing with a recent VM if you are taking
> 1.3 as your performance benchmark.  Maybe 1.5's improvements will also
> help narrow the performance and integration/interop gaps so that using
> Swing in non-native mode is more palatable to GNOME developers, too.  I
> think there are other areas where integration and interoperability work
> between GNOME and Java might be even more useful in the future.

Very true.  Sun has started serious client-side work on Linux; the first
release will mostly just package existing Linux technology for its
customers, but the next releases will focus on better Java integration. 
I don't know more than that now, however.

Tom

[java-gnome-hackers] Java-Gnome 0.8 Application

[Mark H. <mh...@ti...>]

Hi,
  In case anyone is interested, I have uploaded tarballs of the
java-gnome based program which I've been working on.

The main program is bugwatcher. This is a system for monitoring bug
listings and reports on the Debian bug tracking system. It has no
dependency on a Debian system - just uses the website - so should run on
any system with the latest java-gnome. 
It's current state is quite workable, however there are a number of
problems:
- Textview is very slow
- Many problems with most widgets when using text (sometimes doesn't do
the requested action; occasionally segfaults; never accepts empty
strings); these may only be present when using kaffe.
- Multiple thread issues: I'm trying to do some work in one thread and
update a progress bar from the same place. Unfortunately gtk requires
that all gui work be done in one thread. Not sure how to resolve this.
Perhaps some way of creating custom events?
- downloading and parsing bug reports and listings is slow. Output
should be shown on the console, but the application may freeze
temporarily. I'm working on this. It's a combination of java
Serialization problems and updates needed to the bugs server.

Tarballs are available at http://tildemh.com/tmp/debbuggtk/
libdebbug-java-20030109.tar.gz is a required library for handling the
bugs
debbuggtk-20030109.tar.gz contains the main java-gnome classes. The main
class is com.tildemh.debbuggtk.BugWatcher
20030109.png is a screenshot

I'd love to hear any comments 
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] handle->GObject mapping needed

[Mark H. <mh...@ti...>]

On Sat, 2003-01-04 at 06:37, Tom Ball wrote:
> 1.  Store an JNI object reference in the native gobject.  GTK has the
> ability to add named properties using g_object_set, so this is
> workable.  The AWT uses this method.

I guess this would take longer when creating all widgets as more jni
calls are required. 
Would the reference be created using (*env)->NewGlobalRef so that the GC
doesn't free it?
If so, how will this reference be removed to allow the Java object to be
freed?
If not, then what will happen if the user does not keep a reference to
the Java object

> 2.  Maintain a hashtable to map handles to GObjects, and use a factory
> method instead of constructors to look up or create GObjects from
> handles.
Constructors would still be used when constructing a new widget.
Factory methods would be used when accessing an existing object (or at
least existing in the native sense). 
Why is this a problem? IMHO, it makes more sense than having everything
done in constructors.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] handle->GObject mapping needed

[Tom B. <Tom...@Su...>]

In adding support for container events, I found we need to be able to
map a GTK widget handle to its associated Java-GNOME Widget object,
something like:

    /**
     * Return the associated Java-GNOME object for a given handle.
     */
    public static GObject getGObject(int handle) { ... }

Briefly scanning through the code, it looks like this mapping is needed
elsewhere.  For example, there were many cases where a new Widget was
created in an event callback, so that there were then two Widget objects
which shared the same GTK handle.  This duplication was okay back when
all widget state was stored within GTK, but now that we have Java-based
event listener lists and the like, it's important that the 1-to-1
mapping between widgets and Widgets be preserved.

There are two ways to implement a "back-pointer" from a native handle to
its associated GObject:

1.  Store an JNI object reference in the native gobject.  GTK has the
ability to add named properties using g_object_set, so this is
workable.  The AWT uses this method.

2.  Maintain a hashtable to map handles to GObjects, and use a factory
method instead of constructors to look up or create GObjects from
handles.

The advantage of (1) is that GTK manages the memory, so there's no worry
of object leaks.  I'd implement it by making GObject.handle private and
add a protected setter which would call a native method to set the named
property.  The disadvantage is that this mapping isn't as obvious as
(2).

The advantage of (2) is that it easy to understand and therefore
maintain.  The main problem is that all GObject constructors get
hidden/deprecated, and a factory method used instead (like
Widget.makeWidget).  This factory method would check the hashtable
before creating new GObjects with a given handle.  Josh Bloch recommends
this technique in Effective Java, but not everyone is used to it.

My vote is for (1), but I'm comfortable implementing either solution.

Tom