Comment and a question

[David Allen <s2mdalle titan vcu edu>]

First the comment - 

I was writing a piece of GTK+ code the other day, and I made a really
dumb mistake.  The comment though is that the dumb mistake I made had
very strange results.  Here's the situation...

Let's say I have a GtkMenuItem that I'm going to call foo.  (As in
GtkWidget *foo = gtk_menu_item_new()).  Further, let's say I have a
function called foo which has the signature void foo(GtkWidget
*emitter, gpointer data) and it is defined in another file, and
accessible to the function that's defining foo to be a menu item
through header files.

That's the dumb mistake - name clash.  The weird part is that when I
run the application as normal, I choose the Foo menu item, and nothing
happens.  No GTK-WARNING's complaining that the function pointer is no
good, nothing.  If I run the program through strace, the function is
called perfectly.

I'm assuming that in the case where it doesn't work, when I say 

gtk_signal_connect(GTK_OBJECT(foo), "activate",
                   GTK_SIGNAL_FUNC(foo), NULL);

that the second foo refers to the GtkMenuItem, not the function, and
that's why the function code isn't running when foo is selected.  But
when run through strace, foo the function is called.  

I would figure that with the normal rules of C, the
GTK_SIGNAL_FUNC(foo) would actually refer to the GtkMenuItem, and thus
be not a function, since the definitoin of the GtkMenuItem is more
local, and shadows the definition of the function.  What I can't
figure out for the life of me is how code generated by gcc could use
one or the other, depending on how the program was run.  I would have
thought that gcc at compilation time would pick which identifier it
thought I was talking about, and compiled it there.  Maybe there's
some trick having to do with GTK_SIGNAL_FUNC macro evaluation that I
don't know.  

Anyway, that was mighty odd...if anybody has an explanation for how
that might happen, I'd love to hear it, because this doesn't sound
possible, but it's definately happening.  (I've since fixed the
affected code just by changing the name of the GtkMenuItem to
something other than foo so it doesn't clash with the function and of
course everything is peachy)

----------------------------------------------

Now the question.  (Sorry for the length of this post, but I figure
it's better than spamming the group with 2 different things)

I have a GtkCheckMenuItem inside of my application's toplevel menu.
It controls whether or not a certain widget in the application is
displayed.  Internally, I have a gboolean which holds the current
state of the widget.  When that gboolean is true, the widget is shown,
and when it's not, it's not shown.  When I create the
GtkCheckMenuItem, I do it with a special function that I pass the
gboolean to, so that on application start up, the check button is
pressed down if the gboolean was true, and is up if it was false for
on/off.

The problem is that there is another function which indirectly
affects the value of the gboolean value (not some random side-affect,
it's supposed to work that way) -- but how do I keep the
GtkCheckMenuItem "in sync" with the current value of the gboolean
value when more than just the signal function attached to the menu
item has the power to change the value of that boolean?

The only way I can think of is to have a special function called every
time that boolean is altered that will go back to the GtkCheckMenuItem
and toggle it back or forth if necessary -- but the code for that is
extremely crufty, since I'd have to hold a static reference to the
particular GtkCheckMenuItem, and functions which change the boolean
and have absolutely nothing to do with menuing would have to call
them.

Any suggestions on that one?  I don't suppose there's a way to emit a
signal any time a particular variable's value changes.  The problem
here is not how, because I can work it out fine, the problem is how to
do it in a non-crufy way.  Of course, I always have the option of
destroying the entire menu system and creating it from the ground up
whenever anything changes, but that's much worse than cruft.

-- 
David Allen
http://opop.nols.com/
----------------------------------------
A novice was trying to fix a broken Lisp machine by turning the power
off and on.  Knight, seeing what the student was doing spoke sternly:
"You can not fix a machine by just power-cycling it with no
understanding of what is going wrong."  Knight turned the machine off
and on.  The machine worked.