Re: [pygame] Interface Surfaces

["Dave LeCompte (really)" <dave@xxxxxxxxxxxx>]

Kris Schnee wrote:
> What do you think of having each widget draw directly to the screen
> instead of to the parent widget's surface? Sounds awkward, since they'd
> need to know their absolute drawing location.

Actually, this is the way I usually draw widgets - although there are
times when being able to draw to a parent widget makes a lot of sense.

You don't have to have the location in the child widgets (absolute or
relative) - what I have done in the past is have the parent ("container")
widgets keep track of the locations of its children relative to itself.
This makes things like dialog boxes really easy to deal with, because
moving the box only needs to update the position of the box, not any
deeper in the hierarchy.

The way that I have got that to work (in PyGame, in particular, but it
applies elsewhere, as well) is that all widgets implement a draw method
something like this:

def draw(self, canvas, pos)

In the case of containers, the container first draws itself, then it
delegates down to its children and draws them with a passed-through
canvas, and a calculated position (the position of the container, plus
some offset of the child widget within the container).

This has worked well for the kinds of UI that I've wanted to draw, but I
can imagine cases where it becomes tricky. For example, maybe you've got a
dialog box that can fade out over time. (That seems like atrocious user
interface design, but leaving that aside...) For that, I imagine the
easiest way to get that to work is to draw the entire dialog box at full
alpha into an offscreen surface, then blit that surface to the screen with
an alpha that ramps to full transparency over time.

However, using container widgets to group and position child widgets makes
a number of UI idioms simple. I mentioned dialog boxes already, but list
boxes or any other kind of container with a scroll bar become (almost)
trivial.


Hope this is of use.
-Dave LeCompte