Python Programming for Biology: Bioinformatics and Beyond

GUI construction

When  constructing  a  GUI  there  are  a  few  main  areas  that  the  programmer  must  think

about above and beyond the appearance of the graphical items. At the simplest level the

widgets  that  constitute  a  GUI  will  collect  information  from  the  user,  trigger  various

actions  (i.e.  function  calls)  and  display  information.  Thus  the  graphical  objects  need  a

means  of  interacting  with  the  other  parts  of  the  program,  which  is  commonly  kept

somewhat separate from the GUI code. When a user interacts with a widget, e.g. to enter

some text into a box, the program needs to access that data and perhaps change the state of

the  graphics  accordingly.  With  these  interactions  in  mind,  we  use  the  term  callback  to

describe  the  process  of  graphical  widget  calling  a  function  in  our  main  program  and  the

term  update  to  describe  the  setting  of  the  widgets  to  display  new  information.  The  term

signal  is  general  and  will  refer  to  both  callback  and  update  operations.  To  give  a  more

specific example, if a graphical interface is constructed with a tick box (check button) we

can specify a function to be called when the state changes, i.e. when the box is ticked. This

callback from the widget then invokes some change in our program. Conversely, we may

wish to send a signal in the opposite direction so that the tick box is kept updated to reflect

the  state  of  the  main  program  after  some  event.  Inherent  in  this  sort  of  thinking  is  the

notion that the GUI forms a separate layer to the rest of the program.

A  GUI  is  programmed  by  selecting  which  kinds  of  widgets  are  to  be  used,  how  they

signal  to  interact  with  the  rest  of  the  program  and,  of  course,  how  the  objects  are

displayed. When it comes to display, a widget is either placed directly in the context of the

---

screen or inside the borders of another widget. A top-level widget is the term that we will

use for a widget that is not graphically contained by another. The usual form of top-level

widgets in today’s operating systems is a window. The geometry of a top-level widget, in

terms  of  position  and  size,  is  something  that  is  often  adjusted  by  the  user.  However,  the

placement of sub-widgets that go inside the top level is not usually subject to user control.

The  positioning  of  such  widgets  is  a  large  part  of  the  GUI’s  design,  and  the  items  are

generally  placed  to  make  operations  convenient  and  intuitive.  Placement  of  internal

widgets is usually done in a fairly flexible way so that the interface can cope when the top-

level window is resized. Accordingly, it is more common to specify that a widget sticks to

the edge of a window, or expands to fit the current size, rather than specifying its location

absolutely.  Graphical  libraries  will  have  a  layout  or  geometry  management  system  as  a

means  of  directing  where  widgets  are  placed.  For  example,  we  often  just  specify  that

widgets  are  stacked  vertically,  lie  horizontally  or  are  arranged  in  a  grid  and  the  layout

manager handles the fine placement automatically (e.g. making things line up).