Hooking things up in GUI application

[sturlamolden]

Ryan Ginstrom wrote:
> > Behalf Of sturlamolden
> > If you use PyGTK (it also runs on Windows), you can design
> > the GUI with
> > GLADE and then use libglade to import the gui as an xml-resource.
>
> Yes, I've tried something similar with wxGlade. Nice, but it doesn't seem to
> remove the most tedious work -- hooking up handlers (although it does help
> here, at the cost of some behind-the-scenes magic),

It does, there is just *one* line of code for hooking up all the
handlers:

   win.signal_autoconnect(something)

That is one line of code for the entire window, not one line of code
for every widget in the window. Even if your window contains 100
widgets (buttons, sliders, menus, etc), this hooks up the handlers for
every one of them. You just call .signal_autoconnect once. This single
line of code does the job of all the message map macros you would write
in MFC, Fox and wxWidgets. signal_autoconnect does what it says, it
autoconnects the signal handlers. How can that be tedious?

Here is an advice: just be lazy. In particular:

* Don't create write a dictionary mannually and feed it to
signal_autoconnect. Many tutorials do that. It is silly: it is tedious,
it is superfluous bloat, and the job has in fact aldready been done.
Write a class instead. Guido has made sure every class has a
dictionary. Just make sure you have class methods with names
corresponding to the signals. Pass a class reference to
signal_autoconnect.

* Don't grab references for every widget out of the xml. I've seen done
that in many tutorials too. It is silly. Just ask the xml for a
reference when you need one. The xml resources will store the widget
references for you, you don't need to save them anywhere else. Storing
a hundred widget references as class variables is tedious and
superfluous work, and does not do anything except bloating and slowing
your code.


> and getting data into and out of GUI widgets.

It does not save you the job of writing the GUI handlers! It saves you
the job of coding the  GUI (delegate that job to a graphical designer!)
and hooking up the handlers. But you still need to *write* the
handlers.


> That's the kind of boilerplate code that makes GUI
> development a pain in my opinion -- the actual GUI design/layout isn't so
> bad, especially with the spacer layout concept.

At least you get the GUI design out of the rest of your code. The
application logic still need to be there.