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

RE: [java-gnome-hackers] Makefile change?

[Jeffrey M. <ku...@zo...>]

Have you made progress on the makefile changes?

On Sat, 2002-10-26 at 14:49, Tom Ball wrote:
> It seems I only have read access to the CVS repository.  The
> src/Makefile.in changes are ready; I also fixed the javadoc generation
> target.  
> 
> Regarding javadoc, would anyone mind if I got rid of the empty javadoc
> directory from the CVS tree by moving it into a .Attic directory?  It
> would make cleaning the javadoc target much easier if that directory
> were created by the build, as it could then just be completely deleted.
> 
> Tom
> 
> On Mon, 2002-10-21 at 05:13, Jeffrey Morgan wrote:
> > > I started investigating the libglade port by building what's already
> > > there, and found a surprise:  on Linux (probably Solaris too, but it's
> > > been awhile) the default linker mode is to allow unresolved external
> > > references during a build.  In this case, 
> > > org_gnu_glade_LibGlade.c calls
> > > makeBaseObjectClass which I can't find anywhere.  Is that 
> > > unimplemented,
> > > or am I missing a library?
> > 
> > That is an old method that is no longer around.  It's purpose
> > was to make a java object and initialize the pointer to the
> > native peer.  Below is the source for this method.
> > 
> > jobject makeBaseObjectClass (JNIEnv *env, void *peer)
> > {
> >   if (peer == NULL) {
> >     return NULL;
> >   }
> >   else {
> >     jclass cls;
> >     jobject result;
> >     jlong result_jl;
> >     char class[20];
> >     char fullclass[100];
> >     int cmp;
> > 
> >     strcpy(class, gtk_type_name(GTK_OBJECT_TYPE(peer)));
> >     cmp = strncmp("Gtk", class, 3);
> >     if (cmp == 0)
> >       sprintf(fullclass, "gnu/gtk/%s", class);
> >     else
> >       sprintf(fullclass, "gnu/gnome/%s", class);
> >     
> >     cls = (*env)->FindClass(env, fullclass);
> >     
> >     result = (*env)->AllocObject(env, cls);
> >     *(void **) &result_jl = peer;
> >     (*env)->SetLongField (env, result, nativepeerFid, result_jl);
> >     return result;
> >   }
> > }
> > 
> > As you can see, much of this code is not relevant to the
> > current state of the project.
> > 
> > > But back to the build problem: IMHO the build should have 
> > > failed because
> > > makeBaseObjectClass was missing, instead of failing at run 
> > > time.  Adding
> > > "-Xlinker --no-undefined" to each link step catch the error during the
> > > build.  I replaced the makeBaseObjectClass call temporarily 
> > > with a "not
> > > implemented" exception throw -- the method still isn't 
> > > implemented, but
> > > at least the error says it's because a method was called 
> > > which shouldn't
> > > have been (yet), and not because of a problem in the client 
> > > environment.
> > > 
> > > Since this is both my first proposed change and one that changes the
> > > current build philosophy, I thought I should run it by 
> > > everyone first. 
> > > Anyone feel strongly that we shouldn't check for unresolved references
> > > during the build?
> > 
> > I think it is time we clean up the build process.  I completely
> > agree with your suggestion.
> > 
> > -Jeff
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ApacheCon, November 18-21 in
> Las Vegas (supported by COMDEX), the only Apache event to be
> fully supported by the ASF. http://www.apachecon.com
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

Re: [java-gnome-hackers] LibGlade proposal

[Jeffrey M. <ku...@zo...>]

On Sun, 2002-10-27 at 20:31, Tom Ball wrote:
> I've been doing some poking into java.gnu.glade.LibGlade, libglade-0.17,
> and even other language bindings such as the ones for Python and Ruby
> (glade-- for C++ seems focused on code generation rather than
> dynamically loading the glade XML file at runtime).  For the most part,
> these other bindings seem to be just glue to Glade's and GTK's C API. 
> With all the work you've done to present a better event abstraction to
> Java developers, I'd like the glade port to use it as well.
> 
> Here are the constraints as I understand them (please correct me where
> I'm wrong, as these are used to evaluate possible solutions:
> 
> 1.  The various events need to be mapped to the appropriate event class,
> and then connected to a specified listener of that type.
> 
> No problem, LibGlade can do this by defining java.lang.reflect.Proxy
> objects, similar to how the Java Beans persistence support is
> implemented in 1.4.
> 
> 2.  Although these listeners connect a typed event to a typed component,
> they all need to be in the same class due to C naming conventions used
> in the glade definition file.
> 
> Although this might make OO purists shudder, I think this approach is
> more efficient than having a separate listener class for each widget
> like the AWT does.  Conceptually, each "form" (as represented by a glade
> XML file) has an associated event handling class.  By using Proxy
> instances to connect event handlers to different widgets (instead of
> defining separate anonymous inner classes as Swing and the AWT do), the
> number of glue classes are cut to one.  Having all the event handlers in
> one place also makes them easier to find.
> 
> 3.  libglade separates widget instantiation from event handler
> connection, and keeping those steps separate is wanted for Java-Gnome as
> well.
> 
> It's faster to create the widget hierarchy and connect it at the same
> time, but separating the two may be necessary for certain applications. 
> I can't think of any, however, so if no one else can, maybe we should
> keep it simple to begin with.
> 
> 4.  It would be helpful if skeleton methods for the event handlers
> needed by a glade definition file were generated.
> 
> Glade-- uses a command-line generator to create the files Glade creates
> for C.  It would be easy to write an XML parser that generates a
> LibGlade subclass with empty or "not implemented yet" method bodies for
> each of the functions referenced in the glade file.
> 
> How does this sound?  Better ideas?  I'm open to just about anything...
> 

This is exactly what I had in mind.  My vote is to move forward
with the proposal.

-Jeff

[java-gnome-hackers] LibGlade proposal

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

On Fri, 2002-10-18 at 03:57, Jeffrey Morgan wrote:
> I believe our libglade bindings need some help.  Since
> you have an interest in this I would appreciate it if you
> could take a look and make some recommendations.  One of
> the areas that I would like to see changed in the libglade 
> binding is the event handling.  As you can see from our 
> bindings we have just changed over to a more "java like" 
> event handling API.  libglade still wants to use the old 
> signal_connect method.  As a result I have had to keep our 
> old event handling structure public.

I've been doing some poking into java.gnu.glade.LibGlade, libglade-0.17,
and even other language bindings such as the ones for Python and Ruby
(glade-- for C++ seems focused on code generation rather than
dynamically loading the glade XML file at runtime).  For the most part,
these other bindings seem to be just glue to Glade's and GTK's C API. 
With all the work you've done to present a better event abstraction to
Java developers, I'd like the glade port to use it as well.

Here are the constraints as I understand them (please correct me where
I'm wrong, as these are used to evaluate possible solutions:

1.  The various events need to be mapped to the appropriate event class,
and then connected to a specified listener of that type.

No problem, LibGlade can do this by defining java.lang.reflect.Proxy
objects, similar to how the Java Beans persistence support is
implemented in 1.4.

2.  Although these listeners connect a typed event to a typed component,
they all need to be in the same class due to C naming conventions used
in the glade definition file.

Although this might make OO purists shudder, I think this approach is
more efficient than having a separate listener class for each widget
like the AWT does.  Conceptually, each "form" (as represented by a glade
XML file) has an associated event handling class.  By using Proxy
instances to connect event handlers to different widgets (instead of
defining separate anonymous inner classes as Swing and the AWT do), the
number of glue classes are cut to one.  Having all the event handlers in
one place also makes them easier to find.

3.  libglade separates widget instantiation from event handler
connection, and keeping those steps separate is wanted for Java-Gnome as
well.

It's faster to create the widget hierarchy and connect it at the same
time, but separating the two may be necessary for certain applications. 
I can't think of any, however, so if no one else can, maybe we should
keep it simple to begin with.

4.  It would be helpful if skeleton methods for the event handlers
needed by a glade definition file were generated.

Glade-- uses a command-line generator to create the files Glade creates
for C.  It would be easy to write an XML parser that generates a
LibGlade subclass with empty or "not implemented yet" method bodies for
each of the functions referenced in the glade file.

How does this sound?  Better ideas?  I'm open to just about anything...

Tom

RE: [java-gnome-hackers] Makefile change?

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

On Fri, 2002-10-25 at 21:03, Jeffrey Morgan wrote:
> On Sat, 2002-10-26 at 14:49, Tom Ball wrote:
> > It seems I only have read access to the CVS repository.  The
> > src/Makefile.in changes are ready; I also fixed the javadoc generation
> > target.  
> 
> I just checked and you do have full cvs access.  Make sure you are
> using ssh by setting CVS_RSH=ssh.

Ah, that's the problem -- NetBeans CVS repository doesn't require SSH. 
Thanks!

Tom

RE: [java-gnome-hackers] Makefile change?

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

On Fri, 2002-10-25 at 23:03, Jeffrey Morgan wrote:
> On Sat, 2002-10-26 at 14:49, Tom Ball wrote:
> > It seems I only have read access to the CVS repository.  The
> > src/Makefile.in changes are ready; I also fixed the javadoc generation
> > target. =20
>=20
> I just checked and you do have full cvs access.  Make sure you are
> using ssh by setting CVS_RSH=3Dssh.

Also, make sure you are not editing source checked out anonymously
before you became a member of the project.  Even if you give CVS the
right login info, it seems to defer to what it finds in CVS/Root.  I
made this mistake when I first got started.

--=20
Philip A. Chapman

RE: [java-gnome-hackers] Makefile change?

[Jeffrey M. <ku...@zo...>]

On Sat, 2002-10-26 at 14:49, Tom Ball wrote:
> It seems I only have read access to the CVS repository.  The
> src/Makefile.in changes are ready; I also fixed the javadoc generation
> target.  

I just checked and you do have full cvs access.  Make sure you are
using ssh by setting CVS_RSH=ssh.

> 
> Regarding javadoc, would anyone mind if I got rid of the empty javadoc
> directory from the CVS tree by moving it into a .Attic directory?  It
> would make cleaning the javadoc target much easier if that directory
> were created by the build, as it could then just be completely deleted.

This is fine with me.

-Jeff

RE: [java-gnome-hackers] Makefile change?

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

It seems I only have read access to the CVS repository.  The
src/Makefile.in changes are ready; I also fixed the javadoc generation
target.  

Regarding javadoc, would anyone mind if I got rid of the empty javadoc
directory from the CVS tree by moving it into a .Attic directory?  It
would make cleaning the javadoc target much easier if that directory
were created by the build, as it could then just be completely deleted.

Tom

On Mon, 2002-10-21 at 05:13, Jeffrey Morgan wrote:
> > I started investigating the libglade port by building what's already
> > there, and found a surprise:  on Linux (probably Solaris too, but it's
> > been awhile) the default linker mode is to allow unresolved external
> > references during a build.  In this case, 
> > org_gnu_glade_LibGlade.c calls
> > makeBaseObjectClass which I can't find anywhere.  Is that 
> > unimplemented,
> > or am I missing a library?
> 
> That is an old method that is no longer around.  It's purpose
> was to make a java object and initialize the pointer to the
> native peer.  Below is the source for this method.
> 
> jobject makeBaseObjectClass (JNIEnv *env, void *peer)
> {
>   if (peer == NULL) {
>     return NULL;
>   }
>   else {
>     jclass cls;
>     jobject result;
>     jlong result_jl;
>     char class[20];
>     char fullclass[100];
>     int cmp;
> 
>     strcpy(class, gtk_type_name(GTK_OBJECT_TYPE(peer)));
>     cmp = strncmp("Gtk", class, 3);
>     if (cmp == 0)
>       sprintf(fullclass, "gnu/gtk/%s", class);
>     else
>       sprintf(fullclass, "gnu/gnome/%s", class);
>     
>     cls = (*env)->FindClass(env, fullclass);
>     
>     result = (*env)->AllocObject(env, cls);
>     *(void **) &result_jl = peer;
>     (*env)->SetLongField (env, result, nativepeerFid, result_jl);
>     return result;
>   }
> }
> 
> As you can see, much of this code is not relevant to the
> current state of the project.
> 
> > But back to the build problem: IMHO the build should have 
> > failed because
> > makeBaseObjectClass was missing, instead of failing at run 
> > time.  Adding
> > "-Xlinker --no-undefined" to each link step catch the error during the
> > build.  I replaced the makeBaseObjectClass call temporarily 
> > with a "not
> > implemented" exception throw -- the method still isn't 
> > implemented, but
> > at least the error says it's because a method was called 
> > which shouldn't
> > have been (yet), and not because of a problem in the client 
> > environment.
> > 
> > Since this is both my first proposed change and one that changes the
> > current build philosophy, I thought I should run it by 
> > everyone first. 
> > Anyone feel strongly that we shouldn't check for unresolved references
> > during the build?
> 
> I think it is time we clean up the build process.  I completely
> agree with your suggestion.
> 
> -Jeff

RE: [java-gnome-hackers] Remove the org.gnu.gnome.Execute class?

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

Thanks for the input Jeff and Tom.  I'll take it out tonight.

On Mon, 2002-10-21 at 06:06, Jeffrey Morgan wrote:
> I completely agree.  Gone it is!
>=20
> -Jeff
>=20
> > I heartily agree (not that my vote counts for much yet :-).  While the
> > documentation for Execute's async and shell methods suggests they have
> > unique capabilities, a quick grep of the Gnome source code shows that
> > they both are used for the same purpose as Runtime.exec(s), often
> > interchangably (g_get_home gets called a lot using both, for=20
> > example). =20
> >=20
> > As someone who has had to maintain APIs that promised all=20
> > things to all
> > users, I've learned the hard way to just provide the minimum and then
> > see who complains and why.  A smaller API is also easier to learn and
> > use appropriately.
> >=20
> > Tom
> >=20
> > On Sun, 2002-10-20 at 07:28, Philip A. Chapman wrote:
> > > Everyone,
> > >=20
> > > Now that three people have done some work on the Execute=20
> > class, I think
> > > we should delete it.  :-)  I base this opinion on a=20
> > conversation we had
> > > on this list (See the thread started with subject=20
> > Gnome2.defs Aug 10,
> > > 2002).  Execute's async and shell methods duplicate functionality
> > > provided by the java.lang.Runtime.exec methods.  I wish I would have
> > > remembered this conversation last night before I worked on it, but
> > > that's the way it works.
> > >=20
> > > Note, I have not yet deleted the class in case someone is aware of
> > > functionality the Execute's methods afford us that the=20
> > Runtime's does
> > > not.
> > >=20
> > > Thanks,
> > > --=20
> > > Philip A. Chapman
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > Access Your PC Securely with GoToMyPC. Try Free Now
> > https://www.gotomypc.com/s/OSND/DD
> > _______________________________________________
> > java-gnome-hackers mailing list
> > jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> >=20
--=20
Philip A. Chapman

RE: [java-gnome-hackers] Makefile change?

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

> I started investigating the libglade port by building what's already
> there, and found a surprise:  on Linux (probably Solaris too, but it's
> been awhile) the default linker mode is to allow unresolved external
> references during a build.  In this case, 
> org_gnu_glade_LibGlade.c calls
> makeBaseObjectClass which I can't find anywhere.  Is that 
> unimplemented,
> or am I missing a library?

That is an old method that is no longer around.  It's purpose
was to make a java object and initialize the pointer to the
native peer.  Below is the source for this method.

jobject makeBaseObjectClass (JNIEnv *env, void *peer)
{
  if (peer == NULL) {
    return NULL;
  }
  else {
    jclass cls;
    jobject result;
    jlong result_jl;
    char class[20];
    char fullclass[100];
    int cmp;

    strcpy(class, gtk_type_name(GTK_OBJECT_TYPE(peer)));
    cmp = strncmp("Gtk", class, 3);
    if (cmp == 0)
      sprintf(fullclass, "gnu/gtk/%s", class);
    else
      sprintf(fullclass, "gnu/gnome/%s", class);
    
    cls = (*env)->FindClass(env, fullclass);
    
    result = (*env)->AllocObject(env, cls);
    *(void **) &result_jl = peer;
    (*env)->SetLongField (env, result, nativepeerFid, result_jl);
    return result;
  }
}

As you can see, much of this code is not relevant to the
current state of the project.

> But back to the build problem: IMHO the build should have 
> failed because
> makeBaseObjectClass was missing, instead of failing at run 
> time.  Adding
> "-Xlinker --no-undefined" to each link step catch the error during the
> build.  I replaced the makeBaseObjectClass call temporarily 
> with a "not
> implemented" exception throw -- the method still isn't 
> implemented, but
> at least the error says it's because a method was called 
> which shouldn't
> have been (yet), and not because of a problem in the client 
> environment.
> 
> Since this is both my first proposed change and one that changes the
> current build philosophy, I thought I should run it by 
> everyone first. 
> Anyone feel strongly that we shouldn't check for unresolved references
> during the build?

I think it is time we clean up the build process.  I completely
agree with your suggestion.

-Jeff

RE: [java-gnome-hackers] Remove the org.gnu.gnome.Execute class?

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

I completely agree.  Gone it is!

-Jeff

> I heartily agree (not that my vote counts for much yet :-).  While the
> documentation for Execute's async and shell methods suggests they have
> unique capabilities, a quick grep of the Gnome source code shows that
> they both are used for the same purpose as Runtime.exec(s), often
> interchangably (g_get_home gets called a lot using both, for 
> example).  
> 
> As someone who has had to maintain APIs that promised all 
> things to all
> users, I've learned the hard way to just provide the minimum and then
> see who complains and why.  A smaller API is also easier to learn and
> use appropriately.
> 
> Tom
> 
> On Sun, 2002-10-20 at 07:28, Philip A. Chapman wrote:
> > Everyone,
> > 
> > Now that three people have done some work on the Execute 
> class, I think
> > we should delete it.  :-)  I base this opinion on a 
> conversation we had
> > on this list (See the thread started with subject 
> Gnome2.defs Aug 10,
> > 2002).  Execute's async and shell methods duplicate functionality
> > provided by the java.lang.Runtime.exec methods.  I wish I would have
> > remembered this conversation last night before I worked on it, but
> > that's the way it works.
> > 
> > Note, I have not yet deleted the class in case someone is aware of
> > functionality the Execute's methods afford us that the 
> Runtime's does
> > not.
> > 
> > Thanks,
> > -- 
> > Philip A. Chapman
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> Access Your PC Securely with GoToMyPC. Try Free Now
> https://www.gotomypc.com/s/OSND/DD
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

[java-gnome-hackers] Makefile change?

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

I started investigating the libglade port by building what's already
there, and found a surprise:  on Linux (probably Solaris too, but it's
been awhile) the default linker mode is to allow unresolved external
references during a build.  In this case, org_gnu_glade_LibGlade.c calls
makeBaseObjectClass which I can't find anywhere.  Is that unimplemented,
or am I missing a library?

But back to the build problem: IMHO the build should have failed because
makeBaseObjectClass was missing, instead of failing at run time.  Adding
"-Xlinker --no-undefined" to each link step catch the error during the
build.  I replaced the makeBaseObjectClass call temporarily with a "not
implemented" exception throw -- the method still isn't implemented, but
at least the error says it's because a method was called which shouldn't
have been (yet), and not because of a problem in the client environment.

Since this is both my first proposed change and one that changes the
current build philosophy, I thought I should run it by everyone first. 
Anyone feel strongly that we shouldn't check for unresolved references
during the build?

Tom

Re: [java-gnome-hackers] HBox constructor causing segfaults.

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

Yeah, constructors can be evil, since a subclass can't control when its
superclass gets called.  What many toolkits do to work around this is to
define a protected "void init()" which gets called by the superclass's
constructor.  This allows a subclass like AppBar to do something like:

    public AppBar() {
        super();
        // initialization moved down...
    }

    protected init() {
        // initialization here
        super.init();
    }

The init method is a bit dangerous in that subclassers need to realize
that they are dealing with a partially-initialized object, but at least
their superclass can finish initialization with one that is.

An alternative I prefer is to have a protected constructor and a public
static factory method.  Constructors can then initialization objects
like they are supposed to, and the factory method can ensure that the
event handler hookup is called afterwards before a client is given the
object.  

The main drawback to using a static factory method is that it can't
support the Java Beans model, and so these components won't plug into a
form editor easily.

Tom

On Sat, 2002-10-19 at 21:18, Philip A. Chapman wrote:
> Everyone,
> 
> In the constructor org.gnu.gtk.HBox.HBox(), I commented out the line:
> 
> initializeEventHandlers();
> 
> The reason is that it causes segfaults when called during the
> construction of org.gnu.gnome.AppBar, which extends HBox.  AppBar works
> fine if I comment out the line in HBox as specified above and call
> initializeEventHandlers() from AppBar's constructor AFTER calling
> AppBar's gnome_appbar_new native method (thereby obtaining a handle).
> 
> The same applies for org.gnu.gnome.DateEdit as it also extends
> org.gnu.gtk.HBox.
> 
> Jeffrey,
> You are far more familiar with org_gnu_glib_GObject's create_callback
> method than I.  Would you mind looking into this?  Should subclasses of
> HBox simply always call initializeEventHandlers() or is there a way to
> make it work from HBox's constructor?
> 
> The good news is that the TestGNOME application pretty much works now. 
> There's a few annoying things, like buttons that do nothing on the
> dialogs that are opened from the main app.  However. there are no more
> segfaults and all the enabled buttons on the main app seem to be doing
> what they are supposed to.
> 
> Thanks,
> -- 
> Philip A. Chapman

Re: [java-gnome-hackers] Remove the org.gnu.gnome.Execute class?

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

I heartily agree (not that my vote counts for much yet :-).  While the
documentation for Execute's async and shell methods suggests they have
unique capabilities, a quick grep of the Gnome source code shows that
they both are used for the same purpose as Runtime.exec(s), often
interchangably (g_get_home gets called a lot using both, for example).  

As someone who has had to maintain APIs that promised all things to all
users, I've learned the hard way to just provide the minimum and then
see who complains and why.  A smaller API is also easier to learn and
use appropriately.

Tom

On Sun, 2002-10-20 at 07:28, Philip A. Chapman wrote:
> Everyone,
> 
> Now that three people have done some work on the Execute class, I think
> we should delete it.  :-)  I base this opinion on a conversation we had
> on this list (See the thread started with subject Gnome2.defs Aug 10,
> 2002).  Execute's async and shell methods duplicate functionality
> provided by the java.lang.Runtime.exec methods.  I wish I would have
> remembered this conversation last night before I worked on it, but
> that's the way it works.
> 
> Note, I have not yet deleted the class in case someone is aware of
> functionality the Execute's methods afford us that the Runtime's does
> not.
> 
> Thanks,
> -- 
> Philip A. Chapman

[java-gnome-hackers] Remove the org.gnu.gnome.Execute class?

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

Everyone,

Now that three people have done some work on the Execute class, I think
we should delete it.  :-)  I base this opinion on a conversation we had
on this list (See the thread started with subject Gnome2.defs Aug 10,
2002).  Execute's async and shell methods duplicate functionality
provided by the java.lang.Runtime.exec methods.  I wish I would have
remembered this conversation last night before I worked on it, but
that's the way it works.

Note, I have not yet deleted the class in case someone is aware of
functionality the Execute's methods afford us that the Runtime's does
not.

Thanks,
--=20
Philip A. Chapman

[java-gnome-hackers] HBox constructor causing segfaults.

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

Everyone,

In the constructor org.gnu.gtk.HBox.HBox(), I commented out the line:

initializeEventHandlers();

The reason is that it causes segfaults when called during the
construction of org.gnu.gnome.AppBar, which extends HBox.  AppBar works
fine if I comment out the line in HBox as specified above and call
initializeEventHandlers() from AppBar's constructor AFTER calling
AppBar's gnome_appbar_new native method (thereby obtaining a handle).

The same applies for org.gnu.gnome.DateEdit as it also extends
org.gnu.gtk.HBox.

Jeffrey,
You are far more familiar with org_gnu_glib_GObject's create_callback
method than I.  Would you mind looking into this?  Should subclasses of
HBox simply always call initializeEventHandlers() or is there a way to
make it work from HBox's constructor?

The good news is that the TestGNOME application pretty much works now. 
There's a few annoying things, like buttons that do nothing on the
dialogs that are opened from the main app.  However. there are no more
segfaults and all the enabled buttons on the main app seem to be doing
what they are supposed to.

Thanks,
-- 
Philip A. Chapman

Re: [java-gnome-hackers] RE: Want Java-Gnome help?

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

On Fri, 2002-10-18 at 09:42, Tom Ball wrote:
> That sounds great.

Glad to have you on board.  Welcome.

> Sure, I can help clean that up so the old handling code can be ditched.=20
> One reason open source work is so refreshing is that for years I could
> never fix API-related problems in the JRE; one can add to the API over
> time, but never remove due to backward compatibility constraints.  As a
> result, some things could never be properly addressed.  So let's get the
> API as good as possible before there's an installed base to worry about.

Amen!
=20
> BTW, has the team read Josh Bloch's book, Effective Java?  As James
> wrote in the forward, I wish we'd known these rules years ago when the
> first APIs were designed.

That book is now on my wish list at Amazon.  Thanks for the reference.

Again, welcome.  I appreciate your interest in helping.

--=20
Philip A. Chapman

Re: [java-gnome-hackers] Looking forward to the next release

[Jeffrey M. <ku...@zo...>]

On Fri, 2002-10-18 at 13:57, Philip A. Chapman wrote:
> Jeff,
> 
> I'm still here and plan to begin working on gnome this weekend as well. 
> I have been swamped with work lately, but hope to get through with that
> shortly.  

I know the feeling!

> I'm glad you got some of the event stuff nailed down.  I should be able
> to do testing now.  Thanks.

I believe it is pretty close.  I am still having a problem with a
delete event not propagating a subsequent destroy event.  If you
run into any other problems please let me know.

> Have you had an opportunity to look at the work I did with the
> CanvasEllipse?  If so, I'll begin work on the other CanvasItem
> sublcasses.

I have not had a chance to take a look.  Hopefully over the weekend
I can spend some time looking at this work.

Re: [java-gnome-hackers] Looking forward to the next release

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

Jeff,

I'm still here and plan to begin working on gnome this weekend as well.=20
I have been swamped with work lately, but hope to get through with that
shortly.  I have some work I've done on a few examples that has not been
checked in yet.  I've been trying to learn eclipse and did some little
stuff in the examples.

I'm glad you got some of the event stuff nailed down.  I should be able
to do testing now.  Thanks.

Have you had an opportunity to look at the work I did with the
CanvasEllipse?  If so, I'll begin work on the other CanvasItem
sublcasses.

On Fri, 2002-10-18 at 06:15, Jeffrey Morgan wrote:
> The event handling is starting to work as I would
> expect.  I think it is time that we start to list
> the remaining tasks to complete before we have our
> next release.  Here are some of the items I know
> about.
>=20
> 1) The destroy event is still causing fits.  I hope
> to check in code by tomorrow morning that addresses
> this problem.
>=20
> 2) I still have some cleanup to do in the GTK
> package and finish up a few of the TODOs that Mark
> suggested.  I hope to have this completed by early
> next week.
>=20
> 3) The GNOME bindings still need a lot of work.  This
> is where I hope to focus my efforts once I finish items
> 1 & 2.
>=20
> 4) The libglade bindings need some improvement.
>=20
> 5) We need to get all of the examples working.  I also
> believe many of the examples need to be improved to more
> fully demonstrate the widget they are showcasing.
>=20
> 6) We need new examples to demonstrate some of the new
> widgets with GTK2.
>=20
> 7) The documentation needs to be updated.
>=20
> I would like to have a release sometime in November.  I=20
> know there is a lot to do between now and then but I know
> we can do it.  Please let me know if I have left anything
> off the list.
>=20
> -Jeff
>=20
--=20
Philip A. Chapman

[java-gnome-hackers] RE: Want Java-Gnome help?

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

Hi Jeff,

On Fri, 2002-10-18 at 03:57, Jeffrey Morgan wrote:
> I would greatly appreciate your help.  There is a lot
> of activity going on right now on the ATK, GDK, and GTK
> library bindings.  The GNOME portion of the library
> still needs some work.  I hope to finish the lower level
> libraries over the weekend and then focus my attention
> on GNOME.

That sounds great.

> I believe our libglade bindings need some help.  Since
> you have an interest in this I would appreciate it if you
> could take a look and make some recommendations.  One of
> the areas that I would like to see changed in the libglade 
> binding is the event handling.  As you can see from our 
> bindings we have just changed over to a more "java like" 
> event handling API.  libglade still wants to use the old 
> signal_connect method.  As a result I have had to keep our 
> old event handling structure public.f

Sure, I can help clean that up so the old handling code can be ditched. 
One reason open source work is so refreshing is that for years I could
never fix API-related problems in the JRE; one can add to the API over
time, but never remove due to backward compatibility constraints.  As a
result, some things could never be properly addressed.  So let's get the
API as good as possible before there's an installed base to worry about.

BTW, has the team read Josh Bloch's book, Effective Java?  As James
wrote in the forward, I wish we'd known these rules years ago when the
first APIs were designed.

> As far as converting the cormagnon example, I believe it might
> be a little premature to begin this effort.  This example relies
> heavily on the GNOME APIs.  I hope to be at a point where I can
> focus on them next week.

There's obviously no rush to get the examples working.  I purposely
chose something that needed porting to help my own learning.

Tom
> 
> -Jeff
> 
> > I downloaded the java-gnome sources this evening
> > and am impressed by the work done so far. 
> > Building the cromagnon app showed it hadn't been
> > converted after some major API work your team has
> > done, however.  I thought I'd therefore port the
> > example to learn your team's API.
> > 
> > Most of the changes were obvious, and I really
> > like the new API as the changes make the API seem
> > more "Java-like".  This is a pleasant surprise
> > since I was expecting more of a machine
> > translation like many of the other Java library
> > bindings are (the OpenGL bindings come to mind). 
> > I also noticed that some of the conversion work
> > doesn't appear to be done; in particular, the
> > stock menu items referenced by cromagnon.  The CVS
> > dates don't show any activity for a few weeks, either.
> > 
> > So, does your team need any help finishing this
> > library?  I work for Sun Microsystems on mostly
> > open software projects, including NetBeans and a
> > couple of its modules (classfile and metrics are
> > mine).  Prior to that, I was one of the lead
> > developers of Swing and the AWT (although don't
> > blame me for its initial API!).
> > 
> > I am a big fan of Glade, and was starting to write
> > a Java version of libglade when I found your
> > project.  So as a good open source citizen, I am
> > ditching my effort and hope you'll take me on your
> > team instead!
> > 
> > Tom
> > 

[java-gnome-hackers] Looking forward to the next release

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

The event handling is starting to work as I would
expect.  I think it is time that we start to list
the remaining tasks to complete before we have our
next release.  Here are some of the items I know
about.

1) The destroy event is still causing fits.  I hope
to check in code by tomorrow morning that addresses
this problem.

2) I still have some cleanup to do in the GTK
package and finish up a few of the TODOs that Mark
suggested.  I hope to have this completed by early
next week.

3) The GNOME bindings still need a lot of work.  This
is where I hope to focus my efforts once I finish items
1 & 2.

4) The libglade bindings need some improvement.

5) We need to get all of the examples working.  I also
believe many of the examples need to be improved to more
fully demonstrate the widget they are showcasing.

6) We need new examples to demonstrate some of the new
widgets with GTK2.

7) The documentation needs to be updated.

I would like to have a release sometime in November.  I 
know there is a lot to do between now and then but I know
we can do it.  Please let me know if I have left anything
off the list.

-Jeff

[java-gnome-hackers] RE: Want Java-Gnome help?

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

Tom,

I would greatly appreciate your help.  There is a lot
of activity going on right now on the ATK, GDK, and GTK
library bindings.  The GNOME portion of the library
still needs some work.  I hope to finish the lower level
libraries over the weekend and then focus my attention
on GNOME.

I believe our libglade bindings need some help.  Since
you have an interest in this I would appreciate it if you
could take a look and make some recommendations.  One of
the areas that I would like to see changed in the libglade 
binding is the event handling.  As you can see from our 
bindings we have just changed over to a more "java like" 
event handling API.  libglade still wants to use the old 
signal_connect method.  As a result I have had to keep our 
old event handling structure public.

As far as converting the cormagnon example, I believe it might
be a little premature to begin this effort.  This example relies
heavily on the GNOME APIs.  I hope to be at a point where I can
focus on them next week.

-Jeff

> I downloaded the java-gnome sources this evening
> and am impressed by the work done so far. 
> Building the cromagnon app showed it hadn't been
> converted after some major API work your team has
> done, however.  I thought I'd therefore port the
> example to learn your team's API.
> 
> Most of the changes were obvious, and I really
> like the new API as the changes make the API seem
> more "Java-like".  This is a pleasant surprise
> since I was expecting more of a machine
> translation like many of the other Java library
> bindings are (the OpenGL bindings come to mind). 
> I also noticed that some of the conversion work
> doesn't appear to be done; in particular, the
> stock menu items referenced by cromagnon.  The CVS
> dates don't show any activity for a few weeks, either.
> 
> So, does your team need any help finishing this
> library?  I work for Sun Microsystems on mostly
> open software projects, including NetBeans and a
> couple of its modules (classfile and metrics are
> mine).  Prior to that, I was one of the lead
> developers of Swing and the AWT (although don't
> blame me for its initial API!).
> 
> I am a big fan of Glade, and was starting to write
> a Java version of libglade when I found your
> project.  So as a good open source citizen, I am
> ditching my effort and hope you'll take me on your
> team instead!
> 
> Tom
> 

Re: [java-gnome-hackers] CVS will not compile

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

Thanks Mark,

I responded to your email yesterday, but I accidentely used my work
address rather than my personal.  Therefore, it has been held up by the
list server.

Sorry to see you go.  You've done a lot for java-gnome and I know we all
appreciate it.  I wish you luck and hope you come back soon.

On Fri, 2002-10-04 at 02:56, Mark Howard wrote:
> On Fri, 2002-10-04 at 01:05, Philip A. Chapman wrote:
> > The latest from CVS will not compile because of the absence of
> > org.gnu.gtk.CellRendererTextEvent and
> > org.gnu.gtk.CellErndererTextListener.  Did someone forget a cvs add=20
> yes, sorry.
> --=20
>=20
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
--=20
Philip A. Chapman

Re: [java-gnome-hackers] CVS will not compile

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

On Fri, 2002-10-04 at 01:05, Philip A. Chapman wrote:
> The latest from CVS will not compile because of the absence of
> org.gnu.gtk.CellRendererTextEvent and
> org.gnu.gtk.CellErndererTextListener.  Did someone forget a cvs add 
yes, sorry.
-- 

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

[java-gnome-hackers] CVS will not compile

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

The latest from CVS will not compile because of the absence of
org.gnu.gtk.CellRendererTextEvent and
org.gnu.gtk.CellErndererTextListener.  Did someone forget a cvs add or
are these to come soon?
--=20
Philip A. Chapman

Re: [java-gnome-hackers] [VACATION] 2 months

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

Mark,

I know I will miss you.  You've done a lot of work on this project and
have contributed a lot.  It's been great working with you.  Keep in
touch.

On Thu, 2002-10-03 at 12:37, Mark Howard wrote:
> Hi,
> I'm going back to uni at the weekend, so will be able to do little work
> until the start of December. If any bugs come up in my code, please let
> me know - I might be be able to find little bits of time (they say the
> second year is the easiest).=20
> I will try to keep maintaining my Debian packages. I get a 10MB net
> connection next week, so will post the apt-get lines for java-gnome
> snapshot packages (They are complete and working, just need uploading).
> I will probably not upload to Debian main  until ant is moved from
> contrib to main.
> Please don't give up on java-gnome - A lot of work has been done so far
> and a 0.8 release is sure to generate more interest (and more bug
> patches)
>=20
> Here's my list of Gtk todo items which I now won't be able to complete:
> - TreeSortable functions
> - TreeSelelection
> - TreeSelection select function=20
> - TreeView Column drag function
> - TreeView map extended rows function
> - some CellRenderer... events
> - TextBuffer signals
> - TextView signals
> - TextTag
> - TextTagTableSignals
> - Clipboard
>=20
> AFAIK, there are also the following gtk items to do:
> - Image releated widgets
> - socket/plug.
>=20
> Good luck. I look forward to reading about the 0.8.0 release in the
> coming weeks.
> --=20
>=20
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+
--=20
Philip A. Chapman
Product Development Manager

ACO Information Services
866-897-STAR (7827)