[Glade-users] globals vs locals... again

[cooperdl worldnet att net (David Cooper)]

James Cameron wrote:
> Have you any suggestions on how Glade can provide such a service?  It
> already provides lookup_widget() in support.c along with the code in
> interface.c to make it easy to find a widget by name given a pointer to
> any other widget in the same window.

Maybe I'm missing something here and am going about some things all
wrong. I actually don't have a major problem with using lookup_widget()
to find the name of a widget in the same window. Actually, I haven't had
a problem finding a widget in the current window. I'm more interested in
accessing widgets in other windows. However, this could be part of my
problem.

For example, I am working on a simple interface to SCCS/RCS for newbies.
The main window is very basic: Menubar, toolbar, entry field for
path/filename, and status label(signed in/signed out/etc). The user can
either use a fileopen dialog to select a file, which is then placed in
the entry field, or they can type it in. The "File Open" menu and
toolbar activate signals call a function that displays the dialog. The
callback for the "OK" button on the fileopen dialog is where I retrieve
the selected file and replace whatever is currently in the mainwindow
entry field with this new filename.

So, in the callback for the fileopen dialog OK button, I need to access
the entry field that is in the main window. What is the best method to
do this? I'm currently getting a pointer to the dialog box, using that
pointer to obtain a pointer to the main window based on a unique data
key assigned to the main window, and then using lookup_widget to find
the entry field. I guess I'm looking for a way to condense three
function calls to one.

I don't have a great idea on how the builder could do this for us.
However, I'll see what I can do.

> We know that making everything global would be bad ... so this has to be
> a decision made by the programmer, not by the builder.

Agreed. Even though several other builders do this, I have reservations
from a purist standpoint.

> I agree that code quality may not be as important as getting the job
> done sooner.

For small projects, such as the one I mention above, time is often more
important than quality. However, this can still lead to bad habits which
can carry over to large projects where it can only lead to trouble.

Regards,

David