Re: [pygame] Tutorial... GUI

["RR4CLB" <chester_lab@xxxxxxxxxxxx>]

Marcus,

    I could not find a zip file for OcempGUI so I assume it does not exist. 
    So the example can not be run unless I use something else.

        Bruce

On, Wed Sep 26, 2007, RR4CLB wrote:

> Hi!
> 
>     The reading I did today is getting a little more clear on these
> issues, but having something to experiment with would be great.

[Layout description]

Regarding that the screen consists of three areas aranged in a
horizontal manner. On the top the input facilities, followed the warning
message. The rest is occupied by the game screen.

Regarding this design the best would be a pygame user interface as I
mentioned before. Otherwise you would have two or even three separate
windows, one pygame window and two using another user interface toolkit.

Using a different user interface toolkit together with pygame will also
make it nearly impossible to have fullscreen support.

[Screen reader and sound output]

The issues Ulf mentioned in another mail are not tha critical. You can
create classes, which wrap your drawing code (for text, images) and
allow them to provide additional information in another form (sound,
text, etc.). The biggest problem however will be to expose those
information to the AT system in order to let screen readers and other AT
devices read them.

I created an accessibility wrapper for python using the Unix ATK/AT-SPI
toolkit (no support for Windows and MacOS X so far), which can be used
to let arbitrary python classes and objects expose their information to
the underlying accessibility provider.
    http://ocemp.sourceforge.net/papi.html

[Game with both visual and text support]

Basically that sounds not that hard - the only issue will be to provide
the text in a way it can be recognized by screen readers. I am not sure
about the state of the console output recognition (Windows command
shell, etc.), but if it works you could print the information once a
certain event is received.

To support both, mouse and keyboard input and to save the time to create
an own solution my recommendation would be using PGU or OcempGUI for the
user interfaces. Both also allow you to create new classes easily (such
as an enhanced image label or button class, which can expose its
information using text output or using an image).

One critical question would be: arcade or round-based game type?
Arcade would need some sort of real time approach when it comes to sound
output, otherwise the player will be killed before he recognizes what
happened.

[Layout in pygame]

This really depends on with what you end up with. Which user interface
toolkit you choose (if you choose any) and especially what would be
needed for the graphical parts.

Regards
Marcus