java-gnome-hackers

[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] 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] HBox constructor causing segfaults.

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

I have made a similar change to the GTK java classes.  We should
probably make the same changes to the GNOME classes.

I have also implemented a getType method for all objects derived
from GObject in the GTK package.  This method returns the GLib
runtime type identification.  This id is used for several of the
newer widgets and will take a greater significance in future versions
of GTK and GNOME.  This should also be propagated to the GNOME
classes.

On Sun, 2002-10-20 at 13:30, Tom Ball wrote:
> 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
> 
> 
> 
> 
> -------------------------------------------------------
> 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
>