Re: Interdependent widgets

[Paolo Costabel <paolo zebradevelopment com>]

Prewitt, Nathan C ERDC-ITL-MS Contractor wrote:

>     This gets around the problem of the function prototypes, but I 
> still have my main application widget as global data. 
I don't see anything wrong with it. If you want to keep things clean, 
you may want to create an Application object that contains all the 
global data, and have accessors for them.

> And, if I am going to do this, why use the signal and handler at all.  
> For example, when the OK button is clicked on the file selection 
> widget, I setup three signal handlers:  func_1 reads the data file, 
> func_2 updates in widgets in the main application window, and func_3 
> kills the file selection widget.  If I create func_4 that contains the 
> guts of func_2 but has a generic function declaration (no args), why 
> have gtk call func_2 and then call func_4?  I could just call func_4 
> directly from func_1 after the file is read.
I don't see why you are attaching three handlers to the same signal. You 
should have a single handler calling three functions.

>     I was hoping that the event box or some other construct would 
> allow me to raise a signal that would be caught by a handler that was 
> within the proper scope to modify the widgets in my main application 
> widget.  In this way, whenever I do something that I know will change 
> one of othese widgets, all I have to do is raise this signal and the 
> handler will be called to modify the widgets.
You can subclass any object and add your own signals, however if I 
understand your problem correctly you want to have several widgets 
update together to reflect a change in your data. The best way to do 
this is to mimic the GtkAdjustment paradigm: you have one object storing 
the state of your data that emits a signal whenever something changes. 
Individual widgets connect to the signal to update their state accordingly.

> Thanks,
>
> Nathan
>
>
> > -----Original Message-----
> > From: Paolo Costabel [mailto:paolo zebradevelopment com]
> > Sent: Wednesday, January 12, 2005 3:08 PM
> > To: Prewitt, Nathan C ERDC-ITL-MS Contractor
> > Cc: gtk-app-devel-list gnome org
> > Subject: Re: Interdependent widgets
> >
> >
> > The way to handle this is to have a function doing the update and two
> > handlers with the right signature calling it.
> >
> > Prewitt, Nathan C ERDC-ITL-MS Contractor wrote:
> >
> > >    This is my first try developing with GTK+ and I seem to
> > have missed what
> > >I think is a very basic thing after looking through the tutorial, the
> > >examples, and the online manual.  I am using glade to design
> > the gui and I
> > >have a main application window and several other dialogs
> > including a file
> > >selection dialog.  My main application window has a menu
> > bar, a tool bar, a
> > >status bar, an opengl drawing area (using gtkGLExt) and a
> > notebook that
> > >contains many interdependent widgets.
> > >
> > >    When a file is selected (OK is clicked), a handler
> > catches that signal
> > >to open the file and read the contents.  The widgets on the
> > main application
> > >widget need to be updated to reflect what was read from the
> > file.  These
> > >updates including doing things like setting the ranges on sliders and
> > >spinners.  The problem lies partially in the fact that the
> > file selection
> > >widget is separate from the main application widget.  And,
> > since glade tries
> > >to keep all data private, there seems to be no easy way to
> > identify widgets
> > >in the main application widget when the signal handler is
> > called in response
> > >to a signal initiated by the file selection widget.
> > >
> > >    My solution was to make the main application window a
> > global variable.
> > >I have a routine that sets the ranges of several widgets in the main
> > >application widget.  I made this routine a handler for the
> > clicked signal
> > >from the OK button of the file selection widget.  I then
> > tried to make this
> > >also a handler for a signal from a spinner in the main
> > application widget so
> > >that I don't duplicate code (and maybe introduce bugs).  But
> > this would
> > >require a different function prototype for the handler.  I
> > would rather be
> > >able to cause a signal to be generated that will cause the
> > widgets to be
> > >updated without there being any indication of what caused
> > that signal.  Any
> > >clues?
> > >
> > >thank you
> > >
> > >_______________________________________________
> > >gtk-app-devel-list mailing list
> > >gtk-app-devel-list gnome org
> > >http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> > >
> > > 
> > >
> >