Copyright © 2005 Marcus von Appen
Redistribution and use in source (XML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code (XML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.
Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Important: THIS DOCUMENTATION IS PROVIDED BY THE OCEMPGUI PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OCEMPGUI PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Table of Contents
This manual gives an overview about the OcempGUI library and explains how to install, configure and use it. It is meant to be an introduction into the OcempGUI library. This manual is not an API reference. Instead the most classes, methods and functions of the OcempGUI library will be briefly described and examples about how to use them will be provided.
The descriptions, mentioned classes, methods and functions as well as the examples may get out of date and thus using any portion or information of this manual could crash your application or behave in another unexpected way. Although the author tries to keep the manual in synchronization with changes in the library, this can happen from time to time.
If you experience such a misbehaviour or are unsure about a description, refer to the extensive inline documentations of the library. You can accomplish this easily using the pydoc application, for example.
The first versions of OcempGUI were created in 2004, when the author of the package started the Ocean Empire project. Ocean Empire is a reimplementation of an old MS-DOS™ game named Ocean Trader.
The author decided to use the pygame library, which is a python wrapper of the SDL library and noted later, that no matching GUI like extensions exist for it. The first task was to implement such a GUI extension to have a suitable graphical environment for the game. The result of this attempt is OcempGUI.
OcempGUI itself is a GUI toolkit based on the Sprite concept of pygame and completely implemented in Python. It can be easily integrated in projects and reduces the development time by providing an own event mangement system and a reliable collection of user interface elements, of which all components are easy to use, extensible and support styling for the look and feel.
This section describes the process to configure and install OcempGUI.
The following applications and libraries are needed before OcempGUI can be installed:
Python, version 2.3 or higher
pygame, version 1.6 or higher
Please refer to the documentation of the respective package about how to install it.
OcempGUI is not provided as binary package by the author. However, it might be that someone else set up such a package for your wanted operating system or distribution. Those packages are usually not supported by the author, what means that installation problems or similar issues, which do not target the library directly, should be escalated to the respective supplier of that package.
The unpacked package contains two possibilities of building and installing it. Both ways are mostly identical but the one or other user might tend to prefer a specific way. The first is the python way of installing software, the second follows the tradition of the unix environment and uses a Makefile (which actually simply starts the python way). While being in the top source directory, it is possible to type either
make install
for the traditional unix way or
python setup.py install
for the python way.
The package might have some special options, which are described in the README file shipped with it.
Using the latest development sources is possible via CVS. More information about how to use the SourceForge repository can be found on SourceForge.
It should be noted, that using the development sources can cause higher risks to the environment than the usual releases can do. Thus it is highly recommended to read the ocemp-devel mailing list in which actual development ist discussed.
The various components of OcempGUI can be used alone without the
need to use another module of the package. If only a small event
management system is needed, only the
ocempgui.events module can be imported. If
an event management exists and widgets are needed, only the
ocempgui.widgets module needs to be
imported and so on.
The following OcempGUI modules are currently available:
ocempgui.access
Provides various accessibility tools and interfaces for
pygame, so that people with disabilities can easily use
and access pygame applications. Generic object
interfaces for pygame elements are available, which enable them
to provide information for access-related technologies like
braille keyboards or speech synthesizers. The
ocempgui.widgets widget classes
integrate the interfaces of this module.
The accessibility module is in an early state at the moment and currently does not offer any outstanding feature.
ocempgui.draw
Provides various drawing primitives, on which the
ocempgui.widgets module
relies. Usually the methods of this module provide
simplified wrappers for the pygame drawing functions.
ocempgui.events
A small and fast event management system. It comes with an
EventManager class, which takes
care of distributing events to connected objects through
signal queues. The event management system can deal with
any type of data, which you want to use as event.
ocempgui.object
Abstract object definitions, that allow you to rapidly
create own classes, which are event capable through signal
slots. Function or method callbacks
can be connected to or disconnected from the signals, the
object listens to. The BaseObject
class is ready to be used with the
ocempgui.events module.
ocempgui.widgetsVarious GUI elements for the creation and integration of interactive user interfaces. This module contains most commonly used user interface elements as well as abstract core definitions and interfaces to rapidly create own user interface elements. It also provides an own rendering class, which allows you to instantly create your pygame application without the need of taking care about an event and update loop.
To make python objects accessible and usable by the
ocempgui.access module and layers, the
objects have to inherit from the Accessible
class. It provides a single method interface,
get_accessible_context(), which has to
return a AccessibleContext object for the
specific python object.
Dependant on the capabilities of the python object and the
information it provides, it has to set up several attributes of
the AccessibleContext, it will return.
The accessible module is in an early stage and currently does not perform anything useful.
The ocempgui.draw module contains several
wrapper functions around various pygame drawing functions, which
are used by the ocempgui.widgets module. It
is divided in several submodules, of which each one contains
various related functions such as creating rectangle surfaces,
drawing strings or loading images. Although not any function
defined within the ocempgui.draw module
simplifies the usage of the pygame drawing functions, they can
reduce the amount of code to write and several of them enable you
to simplify specific operations.
To use the drawing routines in your own code, you can simply import the module using:
import ocempgui.draw
The ocempgui.draw.Draw submodule contains
several functions for geometric objects. Although most of them
are only wrappers around the respective pygame functions, some
of them can be used to create more complex geometric
objects. The following list gives an overview about the
functions defined within this submodule.
draw_line (surface, color, a, b, width=1)
Draws a line with the given width
from a to b
on the passed surface. This
function simply wraps the
pygame.draw.line() function.
You can find the following example as a python script
under examples/draw_line.py.
# Draw.draw_line () usage example.
import pygame, pygame.locals
from ocempgui.draw import Draw
# Initialize the drawing window.
pygame.init ()
screen = pygame.display.set_mode ((200, 200))
screen.fill ((250, 250, 250))
pygame.display.set_caption ('Draw.draw_line ()')
# Draw horizontal lines in different colors and sizes.
for i in range (10):
val = i * 10
Draw.draw_line (screen, (0 + val, 50 + val, 40 + 2 * val),
(5, val), (195, val), i)
# Draw vertical lines in different colors and sizes.
for i in range (10):
val = i * 8
Draw.draw_line (screen, (0 + 2 * val, 30 + val, 35 + 2 * val),
(5 + i * 10, 100), (5 + i * 10, 195), i)
# Draw a cross.
Draw.draw_line (screen, (0, 0, 0), (120, 100), (195, 195), 3)
Draw.draw_line (screen, (0, 0, 0), (195, 100), (120, 195), 3)
# Show anything.
pygame.display.flip ()
# Wait for input.
while not pygame.event.get ([pygame.locals.QUIT]):
pass
Example 1. Draw.draw_line ()
draw_rect (width, height,color=None)
Creates a rectangle surface with a size of
width and
height, which can be manipulated
and blitted on other surfaces. This function simply wraps
the pygame.Surface function and
calls Surface.fill() on demand.
You can find the following example as a python script
under examples/draw_rect.py.
# Draw.draw_rect () usage example.
import random
import pygame, pygame.locals
from ocempgui.draw import Draw
# Initialize the drawing window.
pygame.init ()
screen = pygame.display.set_mode ((200, 200))
screen.fill ((250, 250, 250))
pygame.display.set_caption ('Draw.draw_rect ()')
# Draw rectangles with various colors.
rect = Draw.draw_rect (55, 40, (255, 0, 0))
screen.blit (rect, (5, 5))
rect = Draw.draw_rect (55, 40, (0, 255, 0))
screen.blit (rect, (65, 5))
rect = Draw.draw_rect (55, 40, (0, 0, 255))
screen.blit (rect, (125, 5))
# Draw encapsulated rectangles.
for i in range (30):
val = i + 3
rnd = (random.randint (0, 5), random.randint (0, 5), random.randint (0, 5))
color = (rnd[0] * i + 100, rnd[1] * i + 100, rnd[2] * i + 100)
rect = Draw.draw_rect (100 - 2 * val, 100 - 2 * val, color)
screen.blit (rect, (5 + val, 50 + val))
# Show anything.
pygame.display.flip ()
# Wait for input.
while not pygame.event.get ([pygame.locals.QUIT]):
pass
Example 2. Draw.draw_rect ()
draw_triangle (surface, color, a, b, c, width=0)
Draws a triangle using the vertices
a, b and
c on the passed
surface. This function simply wraps
the pygame.draw.polygon() function.
You can find the following example as a python script
under examples/draw_triangle.py.
# Draw.draw_triangle () usage example.
import pygame, pygame.locals
from ocempgui.draw import Draw
# Initialize the drawing window.
pygame.init ()
screen = pygame.display.set_mode ((200, 200))
screen.fill ((250, 250, 250))
pygame.display.set_caption ('Draw.draw_triangle ()')
# Draw three triangles.
Draw.draw_triangle (screen, (255, 0, 0), (20, 5), (5, 30), (35, 30), 0)
Draw.draw_triangle (screen, (0, 255, 0), (25, 5), (40, 30), (55, 5), 0)
Draw.draw_triangle (screen, (0, 0, 255), (60, 5), (45, 30), (75, 30), 0)
# Draw a 'tunnel effect' of triangles.
for i in range (30):
val = i + 3
color = (val * 4, val * 7, val * 5)
Draw.draw_triangle (screen, color, (5 + 2 * val, 50 + val),
(195 - 2 * val, 50 + val), (100, 195 - 2 * val), 1)
# Show anything.
pygame.display.flip ()
# Wait for input.
while not pygame.event.get ([pygame.locals.QUIT]):
pass
Example 3. Draw.draw_triangle ()
The ocempgui.draw.Image submodule
contains image related functions, such as loading or saving
image data.
load_image (filename, alpha=False, colorkey=None)
Loads an image from the specified
filename and automatically converts
it to the current display pixel format. If
alpha is set to True, the method
will try enable alpha transparency by using the
pygame.Surface.convert_alpha()
method. If the colorkey argument is
set to a color value, the method tries to add color based
transparency using the
pygame.Surface.set_colorkey()
method. This function is just a wrapper around
pygame.image.load() and
additionally calls
Surface.convert().
You can find the following example as a python script
under examples/load_image.py.
# Image.load_image () usage example.
import pygame, pygame.locals
from ocempgui.draw import Image
# Initialize the drawing window.
pygame.init ()
screen = pygame.display.set_mode ((120, 100))
screen.fill ((250, 250, 250))
pygame.display.set_caption ('Image.load_image ()')
# Load an image and blit it on the screen.
image = Image.load_image ("./image.png")
screen.blit (image, (10, 10))
# Show anything.
pygame.display.flip ()
# Wait for input.
while not pygame.event.get ([pygame.locals.QUIT]):
pass
Example 4. Image.load_image ()
The ocempgui.draw.String submodule
contains functions, which allow the creation and manipulation of
fonts and string surfaces. It includes a simple font caching
system, which provides a fast availability of fonts, which were
created earlier. Besides this feature, the string surface
related functions are mostly wrappers around the respective
pygame functions.
create_font (fontfile, size)
Creates and returns a pygame.Font
object from the given fontfile
using the passed size. The font
will be cached internally, so that a second invocation
using the same fontfile and
size will return the cached font.
This function simply wraps the
pygame.font.Font initializer.
If you manipulate the returned
pygame.Font directly, the
manipulation will be applied to the cached font, too. To
circumvent this behaviour, create a copy of the return
value using the
pygame.Font.copy() method and
manipulate the copy.
You can find the following example as a python script
under examples/create_font.py.
# String.create_font () usage example.
import pygame
from ocempgui.draw import String
def check (font, name):
bold = "not bold"
if font.get_bold ():
bold = "bold"
print "%s at %s is %s" % (name, font, bold)
# Initialize the pygame engine.
pygame.init ()
# Create a font from the ttf located in the current directory.
font = String.create_font ("tuffy.ttf", 14)
check (font, "font")
# Now create a second font and manipulate it.
# NOTE: Due to the caching we are using the same font object as above!
font_mod = String.create_font ("tuffy.ttf", 14)
font_mod.set_bold (True)
# Output the bold state of both fonts.
check (font, "font")
check (font_mod, "font_mod")
Example 5. String.create_font ()
create_system_font (fontname, size)
Creates and returns a pygame.Font
object from the given system font with the specified
fontname and the given
size. Like the
create_font() function, the font
will be cached internally, so that a second invocation
with the same parameters will return the cached font.
This function simply wraps the
pygame.font.SysFont initializer.
If you manipulate the returned
pygame.Font directly, the
manipulation will be applied to the cached font, too. To
circumvent this behaviour, create a copy of the return
value using the
pygame.Font.copy() method and
manipulate the copy.
The pygame.SysFont
documentation also notes this:
This will always return a valid Font object, and will fallback on the builtin pygame font if the given font is not found. | ||
| --Pygame documentation | ||
You can find the following example as a python script
under examples/create_system_font.py.
# String.create_system_font () usage example.
import pygame
from ocempgui.draw import String
# Initialize the pygame engine.
pygame.init ()
# Create some fonts.
fonts = {}
names = ( "Arial", "Helvetica", "Sans", "Serif", "Times" )
for name in names:
fonts[name] = String.create_system_font (name, 14)
# Output the fonts as well as their object address.
for name in fonts:
print "Loaded: %s at %s" % (name, fonts[name])
Example 6. String.create_system_font ()
draw_string (text, font, size, antialias, color)
Creates a transparent surface displaying the
text in the given
color. If
antialias evaluates to True, the
text will be rendered using antialiasing (if possible).
The function first tries to resolve
font as font file. If that fails,
it looks for a system font name, which matches the
font name and returns a Font
object based on those information (or the fallback font
of pygame, see also
create_system_font (fontname, size)
.
You can find the following example as a python script
under examples/draw_string.py.
# String.draw_string () usage example.
import pygame, pygame.locals
from ocempgui.draw import String
# Initialize the drawing window.
pygame.init ()
screen = pygame.display.set_mode ((400, 100))
screen.fill ((250, 250, 250))
pygame.display.set_caption ('String.draw_string ()')
# Create a text using the ttf located in the current directory.
text = String.draw_string ("This is tuffy.ttf", "tuffy.ttf", 16, 1, (0, 0, 0))
screen.blit (text, (5, 5))
# Create a text using the 'Times' system font
text = String.draw_string ("This is Times", "Times", 16, 1, (255, 0, 0))
screen.blit (text, (5, 35))
# Create a text using the fallback python font by specifying a wrong
# font name (hopefully ;-).
text = String.draw_string ("This is the fallback", "invalid_font_name_here",
16, 1, (0, 0, 255))
screen.blit (text, (5, 60))
# Now the same again without antialiasing.
text = String.draw_string ("This is tuffy.ttf (no aa)", "tuffy.ttf",
16, 0, (0, 0, 0))
screen.blit (text, (200, 5))
text = String.draw_string ("This is Times (no aa)", "Times",
16, 0, (255, 0, 0))
screen.blit (text, (200, 35))
text = String.draw_string ("This is the fallback (no aa)",
"invalid_font_name_here", 16, 1, (0, 0, 255))
screen.blit (text, (200, 60))
# Show anything.
pygame.display.flip ()
# Wait for input.
while not pygame.event.get ([pygame.locals.QUIT]):
pass
Example 7. String.draw_string ()
draw_string_with_bg (text, font, size, antialias, color,
bgcolor)
This function is identical to the
draw_string (text, font, size, antialias, color)
function, except that it provides
a background color via the bgcolor
parameter.
You can find the following example as a python script
under examples/draw_string_with_bg.py.
# String.draw_string_with_bg () usage example.
import pygame, pygame.locals
from ocempgui.draw import String
# Initialize the drawing window.
pygame.init ()
screen = pygame.display.set_mode ((100, 100))
screen.fill ((250, 250, 250))
pygame.display.set_caption ('String.draw_string_with_bg ()')
# Create texts using the 'Times' system font and different background
# colors.
text = String.draw_string_with_bg ("This is Times", "Times", 16, 1, (0, 0, 0),
(200, 200, 200))
screen.blit (text, (5, 5))
text = String.draw_string_with_bg ("This is Times", "Times", 16, 1, (0, 0, 0),
(0, 200, 0))
screen.blit (text, (5, 60))
# Show anything.
pygame.display.flip ()
# Wait for input.
while not pygame.event.get ([pygame.locals.QUIT]):
pass
Example 8. String.draw_string_with_bg ()
The ocempgui.events module provides a small
and fast event management system. It is currently separated into
three different classes, of which the most important is the
EventManager class. Besides the
EventManager, an
Event class for sending event data and an
EventCallback class for connecting
functions or methods to signals are available.
To create an own event driven application system or to enhance an existing application, only a few guidelines have to be respected and only a minimal set of changes be made on existing code. You will need to
enable objects to receive events,
set up the event management system.
To understand, what you are doing and to know the pitfalls of the event management system, you first have to know, how it works. The next subsection will give you a short explanation of it.
The event management system of OcempGUI uses a simple approach using signal slots. This means, that objects will register themselves only for specific event types, of which they want to be notified. Any other event will not be sent to them.This reduces the overhead of events the objects have to deal with (either by dropping or processing them) and improves the performance and scalability of the event management system (especially with many objects).
An object, which shall be event aware, has to implement a
notify() method, which will receive
events distributed by the EventManager.
The signature of the method looks like the following:
class OwnObject:
...
def notify (self, event):
...
The event argument of the method will be
an Event object, which can be used to
perform certain actions within the method body then:
class OwnObject:
...
def move (self, coords):
# Moves the object to the desired coordinates (x, y).
self.x = coords[0]
self.y = coords[1]
print "Moved to %d,%d" % (self.x, self.y)
def notify (self, event):
# Check the event signal and run a certain action with its data.
if event.signal == "clicked":
print "Something was clicked!"
elif event.signal == "move":
# Assuming that the event.data contains a coordinate tuple.
self.move (event.data)
Example 9. Enabling an object to receive events
Setting up the main event management is nearly as easy as
enhancing the objects. To add objects to the
EventManager, the
add_object() method has to be
invoked. It receives the object to add and a list of signal ids
as arguments. The signal ids will cause the object to be
registered in specific queues, to which events with matching
signal ids then will be sent.
Objects can be removed from the
EventManager using the
remove_object() method. The method
allows you to either remove the object from specific
slots or from all
slots, it is registered for, at once.
We use the OwnObject class of the
previous example and will (un)register it for the signals
"move" and "clicked".
# Create an EventManager and OwnObject instance.
manager = EventManager ()
myobj = OwnObject ()
# Add the object to the EventManager.
manager.add_object (myobj, "move", "clicked")
# Remove the object from the 'clicked' slot.
manager.remove_object (myobj, "clicked")
# Remove the object from _all_ slots it still listens on.
manager.remove_object (myobj)
Example 10.
Adding and removing an object to the
EventManager
Now let us proceed to the most important: sending events. To
send events to the objects of the
EventManager, you can use the
emit() method. It receives two
arguments, which will become the signal and data of a
Event object. The
Event will be created by the
EventManager and then sent to the
matching objects. So all you have to do is to pass the
emit() method the correct information
for the event.
Both arguments the emit() receives,
have no limitations of type, length or whatsoever. It is up to
you to to send correct information through the event management
system and to check for correct information on the object side.
The following example is a complete example based on the
excerpts from above. You can find it as python script under
examples/eventmanager.py
# EventManager usage example.
from ocempgui.events import EventManager
# Create a new event capable object. This can be acquired by adding a
# 'notify ()' method to the object, which receives a single argument.
class OwnObject:
def __init__ (self):
self.x = 0
self.y = 0
def move (self, coords):
# Moves the object to the desired coordinates (x, y).
self.x = coords[0]
self.y = coords[1]
print "Moved to %d,%d" % (self.x, self.y)
def notify (self, event):
# Check the event signal and run a certain action with its data.
if event.signal == "clicked":
print "Something was clicked!"
elif event.signal == "move":
# Assuming that the event.data contains a coordinate tuple.
self.move (event.data)
# Create an EventManager and OwnObject instance.
manager = EventManager ()
myobj = OwnObject ()
# Add the object to the EventManager.
manager.add_object (myobj, "move", "clicked")
# Send events to the registered objects via the emit() method.
manager.emit ("clicked", None)
manager.emit ("move", (10, 10))
# Remove the object from the 'clicked' slot.
manager.remove_object (myobj, "clicked")
# Send the 'clicked' event once more.
manager.emit ("clicked", None)
# Remove the object from _all_ slots it still listens on.
manager.remove_object (myobj)
# Send the 'move' event again.
manager.emit ("move", (40, 40))
Example 12. Complete event management example
The previous section gave you a rough overview about how to use
the OcempGUI event system with your own objects. As you might
have seen, using only the notify()
method and lengthy if-else conditions might not always be the
best idea. Also, overriding the
notify() method whenever the
functionality of an object should change is not the best,
especially, if it should be runtime dependant.
You might consider using the BaseObject
from the ocempgui.object module
instead. It offers ready to use signal slots and methods to bind
callbacks at runtime, improving its and your flexibility without
big effort.
The BaseObject is event driven, which
means, that it acts and reacts upon events it receives and
that it can raise events. Hereby you have to distinguish
between Signals and
Events. Signals are
certain identifiers, a BaseObject can
listen to, while Events are a combination
of a Signal and additional data.
What does that mean in practice? As you already know from
the section called “Building event driven systems”, objects will register
themselves at an event manager with a specific signal, they
listen to. Events in turn carry a specific signal id and
additional data. A BaseObject will
register itself at an event manager with its signals. If
events are passed to the event manager, it will distribute
them to the object, if needed. The object in turn will react
according to its programming instructions.
To allow your object to react according to the application
needs on certain events easily, the
BaseObject supports the connection of
callbacks to signals you can define for
it. A callback is a method or function,
which should be invoked, when the object receives a certain
event.
The first thing you should do is to let your existing object or
the newly created one inherit from the
BaseObject class. Afterwards you can
unleash its full power by adding just a minimal set of code.
from ocempgui.object import BaseObject
class OwnObject (BaseObject):
def __init__ (self):
BaseObject.__init__ (self)
...
Example 13.
Inheriting from the BaseObject class
That is not all of course. You also have to set up the signals the object has to listen to and create callbacks. Let us create a small ping-pong example, where two objects react upon a 'ping' and 'pong' signal.
The BaseObject has a
_signals attribute, which basically is a
dictionary with the signal ids it listens to as keys and list
for the callbacks as values. To allow your object to listen to
the 'ping' or 'pong' signal, you have to add those to this
dictionary.
from ocempgui.object import BaseObject
class OwnObject (BaseObject):
def __init__ (self):
BaseObject.__init__ (self)
self._signals["ping"] = []
self._signals["pong"] = []
...
Example 14. Adding a signal to the object
The list as value is mandatory to allow callbacks to be connected to those signals. If you are going to supply other types as value, keep in mind, that it is unlikely that connecting or disconnecting callbacks will work as supposed.
Now we just need to make the notify()
aware of those signal types and let it invoke the appropriate
callbacks, which will be connected to those signals.
class OwnObject (BaseObject):
...
def notify (self, event):
if event.signal == "ping":
self.run_signal_handlers ("ping")
elif event.signal == "pong":
self.run_signal_handlers ("pong")
Example 15. Setting up the notify() method
As you see, the run_signal_handlers()
takes care of invoking the connected callbacks. Now you have
anything set up to allow the object to listen to specific
events, to connect callbacks to it and let it invoke them,
when it receives the specific signal.
To connect methods or functions as callbacks to a specific
signal, the connect_signal() method of
the BaseObject can be used. It allows
additional data to be passed to the callback by specifiying the
data right after the signal and callback. If the callbacks is
not needed anymore, it can be disconnected using the
disconnect_signal() method.
class OwnObject (BaseObject):
...
my_obj = OwnObject ()
ev_callback1 = my_obj.connect_signal ("ping", ping_callback, data)
ev_callback2 = my_obj.connect_signal ("pong", pong_callback, data1, data2)
...
my_obj.disconnect_signal (ev_callback1)
my_obj.disconnect_signal (ev_callback2)
Example 16. Connecting and disconnecting callbacks.
Now it just needs to be connected to an event manager. In
contrast to the earlier section, you do not need to register
any signal of your BaseObject inheritor
manually. When you connect it to an event manager, it will
automatically do that for you.
class OwnObject (BaseObject):
...
manager = EventManager
my_obj = OwnObject ()
# Any signal of the object will be registered automatically.
my_obj.manager = manager
Example 17. Connecting the object to an event manager.
The last important thing to know about the
BaseObject is its ability to emit
events. If the object is connected to an event manager, you
can let it send events through the manager with the object its
emit() method. The syntax is the same
as if you would emit events on the
EventManager directly.
Now let us look at the example we just went through (the
following oone is slightly modified only). You can find the
example as python script under
examples/baseobject.py
# BaseObject usage example.
from ocempgui.object import BaseObject
from ocempgui.events import EventManager
# Callbacks, which should be invoked for the object.
def ping_callback (obj, additional_data):
print "The object is: %s" % obj.name
print "Passed data is: %s" % additional_data
def pong_callback ():
print "Another callback with no arguments."
# Object implementation, which can listen to specific events.
class OwnObject (BaseObject):
def __init__ (self, name):
BaseObject.__init__ (self)
self.name = name
# The object should be able to listen to 'ping' and 'pong'
# events.
self._signals["ping"] = []
self._signals["pong"] = []
def notify (self, event):
# This simple notify method will not be used in this
# example. Instead, the signals are invoked directly.
if event.signal == "ping":
self.run_signal_handlers ("ping")
elif event.signal == "pong":
self.run_signal_handlers ("pong")
manager = EventManager ()
# Create an object and connect callbacks to its both events.
my_obj = OwnObject ("First object")
ev1 = my_obj.connect_signal ("ping", ping_callback, my_obj, "data")
ev2 = my_obj.connect_signal ("pong", pong_callback)
# Connect it to the event manager
my_obj.manager = manager
# Invoke the connected signals handlers for a specific event.
manager.emit ("ping", None)
manager.emit ("pong", None)
# After disconnecting a callback, it will not be invoked anymore.
my_obj.disconnect_signal (ev1)
my_obj.disconnect_signal (ev2)
manager.emit ("ping", None)
manager.emit ("pong", None)
Example 18. Ping-Pong with a BaseObject
The ocempgui.object module includes
another event capable object class, the
ActionListener, which inherits from the
BaseObject class, but allows you to
create and delete signals and listening queues as you need
them without the necessity to subclass.
The ActionListener creates the signal
id and a callback queue, when you connect a callback to it and
registers itself for this signal automatically at its event
manager. This can be extremeley useful, if a more flexible
event capable object type is needed, which does not need to do
any sanity checks on the event data. Instead it will send the
event data to the callback as well, which then can work with it.
Once more let us create a ping-ping example using the
ActionListener class instead of a
BaseObject now.
You can find the example as python script under
examples/actionlistener.py
# ActionListener usage example.
import sys
from ocempgui.events import EventManager
from ocempgui.object import ActionListener
count = 0
def emit_pong (event, manager):
print "emit_pong received: [%s] - emitting pong..." % event
manager.emit ("pong", "pong_event")
def emit_ping (event, manager):
global count
if count > 10:
sys.exit ()
count += 1
print "emit_ping received: [%s] - emitting ping..." % event
manager.emit ("ping", "ping_event")
# Create an event manager and two ping-pong listeners.
manager = EventManager ()
listener1 = ActionListener ()
listener1.connect_signal ("ping", emit_pong, manager)
listener1.manager = manager
listener2 = ActionListener ()
listener2.connect_signal ("pong", emit_ping, manager)
listener2.manager = manager
# start ping-pong actions
print "Starting Ping-Pong"
manager.emit ("ping", "ping_event")
Example 19. Ping-Pong with the ActionListener
Looking at the first interesting line, line eight,
def emit_pong (event, manager):
print "emit_pong received: [%s] - emitting pong..." % event
manager.emit ("pong", "pong_event")
EventManager
object, on which it emits a pong event with additional data then.
Line twelve and following does the same, but breaks, if it was invoked more than ten times.
The next lines of interest are line twenty-three to twenty-nine,
listener1 = ActionListener ()
listener1.connect_signal ("ping", emit_pong, manager)
listener1.manager = manager
ActionLister objects will
be created and signal slots and callbacks for the 'ping' and
'pong' events will be set up. In line twenty-five and
twenty-nine the objects will be registered at the event
manager created earlier in the code.
Although this class is very mighty, you should not use it as base for own event capable classes. When the feature set and code amount of your own classes grow, it easily can happen, that you oversee events or that you do not understand which signals it should deal with anymore.
It is however a good and valuable class type to work as proxy or to delegate events to different functions or methods in a context sensitive manner.
The first thing an application using OcempGUI should do is to
initialize the renderering system. The
Renderer class from the
ocempgui.widgets package contains all
necessary parts to take care of this. It includes
the event mangement
a sprite based render engine
methods to create the pygame window
The Renderer can be set up with only
three lines of code.
Now that the Renderer is set up, you
can start to place widgets on the pygame window by adding them
using the Renderer.add_widget()
method. Let us do this by building a simple (and well-known)
application with a Button widget on it,
that displays 'Hello World'.
You can find the example as python script under
examples/hello_world.py
# Hello World example.
from ocempgui.widgets import *
# Initialize the drawing window.
re = Renderer ()
re.create_screen (100, 50)
re.title = "Hello World"
re.color = (250, 250, 250)
button = Button ("Hello World")
button.position = (10, 10)
re.add_widget (button)
# Start the main rendering loop.
re.start ()
Example 21. Hello World with OcempGUI
The second line
from ocempgui.widgets import*
ocempgui.widgets module you will need
to build an application. It is also possible to use a fine
grained selection of classes and submodules to import, but
mostly the above code will serve well.
The fifth and sixth lines
re = Renderer ()
re.create_screen (100, 50)
Renderer object, which
takes care of updating the screen and the event management and
create a pygame window with a 100x50 size.
The seventh and eight line
re.title = "Hello World"
re.color = (250, 250, 250)
In line ten
button = Button ("Hello World")Button widget is created. The
constructor can receive an additional argument with the text,
the Button should display.
The next line will place the Button at
a specific position.
button.position = (10, 10)
Line twelve
re.add_widget (button)
The last line will start the main processing loop of the
Renderer.
re.start ()
Renderer, which will wait
for events, draw and update the widgets and so on.
Every widget of OcempGUI inherits from the
ocempgui.object.BaseObject class and
its event handling makes heavy usage of the
BaseObject features.
To cause a Button to print a message
upon a mouse click, you would connect a message printing
function to the click signal of the
Button. In turn, if this callback is
not needed anymore in the later program flow, you would
disconnect the function from the
Button's signal.
This theoretical model is used in many different toolkits and
OcempGUI stays with it. We will enhance our 'Hello world'
example application from the previous chapter with a callback
now, wich prints a message each time the
Button is clicked.
You can find the example as python script under
examples/hello_world_signals.py
# Hello World example.
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def print_message ():
print "The button was clicked!"
# Initialize the drawing window.
re = Renderer ()
re.create_screen (100, 50)
re.title = "Hello World"
re.color = (250, 250, 250)
button = Button ("Hello World")
button.position = (10, 10)
button.connect_signal (SIG_CLICKED, print_message)
re.add_widget (button)
# Start the main rendering loop.
re.start ()
Example 22. Hello World with callbacks
The first change you note is the new import directive in line three.
from ocempgui.widgets.Constants import *
ocempgui.widgets module. The availabe
signal identifiers used by the various widgets of OcempGUI
area prefixed with SIG_.
Line five and six contain the function, which will be used as the callback for the button. It is indifferent, if the callback is a class or object method or a function. Both cases will work in the same way.
The next notably change was done in line 16
button.connect_signal (SIG_CLICKED, print_message)
Button to invoke the
print_message function each time it
is clicked. You also could send additional data to the
callback as you already know from the section called “Making objects event capable - the better way”. Anything written about
the signal handling of the BaseObject
class applies to the widgets, too.
The following sections cover the possibilities and capabilities of
the different widgets, the ocempgui.widgets
module offers. The sections will not cover any method and
attribute of the widgets in detail, but just the most important
ones. It is strongly recommended, that you read through the doc
strings of the widgets, too, to get a complete overview about
them.
The ocempgui.widgets module contains some
globally accessed settings, that influence its complete
behaviour. Those can be found in the
ocempgui.widgets.base part and contain
the Style, which is currently in use, the
timer rate for double-clicks and a debugging flag. You can
adjust those settings easily by simply binding them to new
values.
Before you go ahead and change base.GlobalStyle, you should read the section called “Changing the widget appearance”.
The base.debug setting is for additional debugging output and should not be set to True usually (unless you are using a development version).
The last one, base.DoubleClickRate should
be set using the
base.set_doubleclick_rate() method only
and denotes the maximum time to elaps between two click
operations to identify them as a double-click.
The BaseWidget is the most basic class of
all widgets and contains common attributes and methods, each
widget of the ocempui.widgets module has to
include. Every widget inherits from it, so that any description
and explanation in this section also to the widgets, which are
explained later on.
A widget can be set to a specific position on the main screen using the position attribute.
widget.position = 10, 15
This will not work as supposed using widgets, that are bound
to a Container or
Bin widget, which will be explained
in one of the following sections.
If you read the current position value of a widget, keep in mind, that it will return a tuple containing the both, x and y, coordinates.
Every widget supports a minimum size, that will be respected by the default drawing methods.
widget.size = 80, 20
The currently used width and height, which can differ from its size can be retrieved using the width and height attributes.
if (widget.width == widget.size[0]) and (widget.height == widget.size[1]):
print "Widget does not exceed its minimum size."
To allow an easy and logical keyboard navigation, widgets have an index attribute, which influences the navigation order using the keyboard.
widget.index = 3
The input focus mentioned above denotes a state of the widget,
in which the user can interact with it using the keyboard only.
A Button widget will react upon pressing
the space bar with a click while an Entry
widget will let the user type text. You can set the input focus
of a widget manually with the focus attribute.
widget.focus = True
Table). Depedant
on the widget the set_focus() method of it
will return either True or False, which indicates, that the
input focus could be sucessfully set for that widget or not.
frame = VFrame ()
focusok = frame.set_focus (True)
if not focusok:
print "Focus could not be set."
Widgets can be disabled from user interaction and receiving events, if you set their sensitive attribute to False.
widget.sensitive = False
The renderering system of the
ocempgui.widgets module can use different
layers, on which widgets are drawn. This is especially useful
and often necessary to place widgets above others (e.g. to place
a Window widget above another one).
widget.depth = 3
Labels are elements displaying a short amount of text. They are non-interactive widgets and usually are used to display needed information to the user.
To create a Label, you typically will use
my_label = Label (text)
To set the text after creation, use the text
attribute or set_text() method.
label.text = "New Text"
label.set_text ("New Text")
It is possible to have multiline text by setting the multiline attribute to True:
label.multiline = True
label.set_multiline (True)
Labels support keyboard accelerators, so called mnemonics, which
can activate other widgets. The '#' will cause the directly
following to work as mnemonic character. If you want to cause the
Label to display a normal '#', use '##' in
the text.
label.text = '#Mnemonic'
label.set_text ('A simple hash: ##')
If a mnemonic is set up, you usually have to set the widget, which should be activated by the mnemonic as well.
label.widget = another_widget
Below you will find an example to illustrate most of the abilities
of the Label widget class. You do not need
to care about other widgets like the Frame
class for now as those are explained later on.
You can find the following example as a python script under
examples/label.py.
# Label examples.
import os
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _create_vframe (text):
frame = VFrame (Label (text))
frame.spacing = 5
frame.align = ALIGN_LEFT
return frame
def create_label_view ():
states = ("STATE_NORMAL", "STATE_ENTERED", "STATE_ACTIVE",
"STATE_INSENSITIVE")
table = Table (2, 3)
table.spacing = 5
# Frame with the states.
frm_states = _create_vframe ("States")
for i in xrange (len (states)):
lbl = Label (states[i])
if STATE_TYPES[i] == STATE_INSENSITIVE:
lbl.sensitive = False
else:
lbl.state = STATE_TYPES[i]
frm_states.add_child (lbl)
table.add_child (0, 0, frm_states)
table.set_align (0, 0, ALIGN_TOP)
# Frame with different padding.
frm_padding = _create_vframe ("Padding")
for i in xrange (5):
lbl = Label ("Padding: %dpx" % (i * 2))
lbl.padding = i * 2
frm_padding.add_child (lbl)
table.add_child (0, 1, frm_padding)
table.set_align (0, 1, ALIGN_TOP)
# Frame with mnemonic support.
frm_mnemonics = _create_vframe ("Mnemonics")
strings = ("#Simple Mnemonic", "A ## is displayed using '####'",
"M#ultiple M#nemonics #have no #effect")
for i in xrange (len (strings)):
lbl = Label (strings[i])
frm_mnemonics.add_child (lbl)
table.add_child (0, 2, frm_mnemonics)
table.set_align (0, 2, ALIGN_TOP)
# Frame with multiline labels.
frm_multiline = _create_vframe ("Multiline labels")
strings = ("Single line", "First lines" + os.linesep + "Second line",
"First line" + os.linesep + "Second line" + os.linesep +
"Third Line",
"Two lines with a" + os.linesep + "#mnemonic")
for i in xrange (len (strings)):
lbl = Label (strings[i])
lbl.multiline = True
frm_multiline.add_child (lbl)
table.add_child (1, 0, frm_multiline)
table.set_align (1, 0, ALIGN_TOP)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (500, 350)
re.title = "Label examples"
re.color = (234, 228, 223)
re.add_widget (create_label_view ())
# Start the main rendering loop.
re.start ()
Example 23. Label example
Buttons are interactive user interface elements, which usually react upon mouse events such as clicks or similar events.
You already learned about the Button widget
in an earlier section, so let us look at some interesting details
of it now.
The Button widget is a interactive
widget, which reacts upon mouse input such as clicks. Basically
it is a container (which will be explained detailled later on),
which holds a Label widget to display its
text.
To create a Button, you usually will type
button = Button (text)
The usage of mnemonics for the Button is easy to achieve by
simply supplying a mnemonic text as described in the section called “Labels”. You can set the text directly through
the text attribute or
set_text() method.
button.text = "#Mnemonic"
button.set_text ("#Mnemonic")
Button its
Label as this already has been done on
creation of the Button.
As one of only few widgets the Button
supports different border styles to adjust its look and feel
without the need to override its drawing methods.
button.border = BORDER_NONE
button.set_border (BORDER_NONE)
The Button widget has some default
signals, it listens to. Those are
SIG_MOUSEDOWN - Invoked, when a mouse button is pressed down on the Button.
SIG_MOUSEUP - Invoked, when a mouse button is released on the Button.
SIG_MOUSEMOVE - Invoked, when the mouse moves over the Button area.
SIG_CLICKED - Invoked, when the left mouse button is pressed and released over the Button.
Below you will find an example to illustrate most of the
abilities of the Button widget class. You
do not need to care about other widgets like the
Frame class for now as those are
explained later on.
You can find the following example as a python script under
examples/button.py.
# Button examples.
import os
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _create_vframe (text):
frame = VFrame (Label (text))
frame.spacing = 5
frame.align = ALIGN_LEFT
return frame
def create_button_view ():
states = ("STATE_NORMAL", "STATE_ENTERED", "STATE_ACTIVE",
"STATE_INSENSITIVE")
table = Table (2, 3)
table.spacing = 5
# Frame with the states.
frm_states = _create_vframe ("States")
for i in xrange (len (states)):
btn = Button (states[i])
if STATE_TYPES[i] == STATE_INSENSITIVE:
btn.sensitive = False
else:
btn.state = STATE_TYPES[i]
frm_states.add_child (btn)
table.add_child (0, 0, frm_states)
table.set_align (0, 0, ALIGN_TOP)
# Frame with different padding.
frm_padding = _create_vframe ("Padding")
for i in xrange (5):
btn = Button ("Padding: %dpx" % (i * 2))
btn.padding = i * 2
frm_padding.add_child (btn)
table.add_child (0, 1, frm_padding)
table.set_align (0, 1, ALIGN_TOP)
# Mnemonics.
frm_mnemonic = _create_vframe ("Mnemonics")
btn = Button ("#Simple Mnemonic")
btn2 = Button ("#Activate using <ALT><Underlined Key>")
frm_mnemonic.add_child (btn, btn2)
table.add_child (0, 2, frm_mnemonic)
table.set_align (0, 2, ALIGN_TOP)
# Borders.
frm_borders = _create_vframe ("Borders")
btn_raised = Button ("Raised border")
btn_sunken = Button ("Sunken border")
btn_sunken.border = BORDER_SUNKEN
btn_flat = Button ("Flat border")
btn_flat.border = BORDER_FLAT
btn_none = Button ("No border")
btn_none.border = BORDER_NONE
btn_etchedin = Button ("Etched in")
btn_etchedin.border = BORDER_ETCHED_IN
btn_etchedout = Button ("Etched out")
btn_etchedout.border = BORDER_ETCHED_OUT
frm_borders.add_child (btn_raised, btn_sunken, btn_flat, btn_none,
btn_etchedin, btn_etchedout)
table.add_child (1, 0, frm_borders)
table.set_align (1, 0, ALIGN_TOP)
# Multiline labeled buttons
frm_multiline = _create_vframe ("Multiline labels")
strings = ("Single lined Button", "Two lines on" + os.linesep + "a Button",
"Two lines with a" + os.linesep + "#mnemonic")
for i in xrange (len (strings)):
button = Button (strings[i])
button.child.multiline = True
frm_multiline.add_child (button)
table.add_child (1, 1, frm_multiline)
table.set_align (1, 1, ALIGN_TOP)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (550, 470)
re.title = "Button examples"
re.color = (234, 228, 223)
re.add_widget (create_button_view ())
# Start the main rendering loop.
re.start ()
Example 24. Button example
The ImageButton is basically a subclass
of the Button, but enhances it by the
ability to load and display image data. It supports any image
data format, that can be handled by the underlying pygame
library. Due to its inheritance, everything said about the
Button widget applies to the
ImageButton as well.
The creation of an ImageButton is
slightly different to the Button. Instead
of passing the text to display, you can pass either the name of
a file to load (including the full path to it) or a
pygame.Surface object to display.
button = ImageButton ("path/to/an/image.png")
button = ImageButton (pygame_surface)
button.text = "Additional text"
Below you will find an example to illustrate most of the
abilities of the ImageButton widget
class. You do not need to care about other widgets like the
Frame class for now as those are
explained later on.
You can find the following example as a python script under
examples/imagebutton.py.
# ImageButton examples.
import pygame, os
from ocempgui.draw import Image
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _create_vframe (text):
frame = VFrame (Label (text))
frame.spacing = 5
frame.align = ALIGN_LEFT
return frame
def create_button_view ():
states = ("STATE_NORMAL", "STATE_ENTERED", "STATE_ACTIVE",
"STATE_INSENSITIVE")
image = Image.load_image ("./image.png")
table = Table (2, 2)
table.spacing = 5
# Frame with the states.
frm_states = _create_vframe ("States")
for i in xrange (len (states)):
btn = ImageButton (image)
if STATE_TYPES[i] == STATE_INSENSITIVE:
btn.sensitive = False
else:
btn.state = STATE_TYPES[i]
btn.text = states[i]
frm_states.add_child (btn)
table.add_child (0, 0, frm_states)
table.set_align (0, 0, ALIGN_TOP)
# Frame with different padding.
frm_padding = _create_vframe ("Padding")
for i in xrange (4):
btn = ImageButton (image)
btn.padding = i * 2
frm_padding.add_child (btn)
table.add_child (0, 1, frm_padding)
table.set_align (0, 0, ALIGN_TOP)
# Mnemonics.
frm_mnemonic = _create_vframe ("Mnemonics")
btn = ImageButton (image)
btn.text = "#Simple Mnemonic"
btn2 = ImageButton (image)
btn2.text = "#Activate using <ALT><Underlined Key>"
frm_mnemonic.add_child (btn, btn2)
table.add_child (1, 0, frm_mnemonic)
table.set_align (1, 0, ALIGN_TOP)
# Multiline labeled ImageButton
frm_multiline = _create_vframe ("Multiline label")
button = ImageButton (image)
button.text = "Multiple lines" + os.linesep + "with a #mnemonic"
button.child.multiline = True
frm_multiline.add_child (button)
table.add_child (1, 1, frm_multiline)
table.set_align (1, 1, ALIGN_TOP)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (570, 400)
re.title = "ImageButton examples"
re.color = (234, 228, 223)
re.add_widget (create_button_view ())
# Start the main rendering loop.
re.start ()
Example 25. ImageButton example
Inherited from the Button the
ToggleButton widget does not differ from
it except that it is always in one state, either active or
inactive, which are alternated by a click. By default it is
displayed in a depressed state on a click and pops up after
clicking it again.
To create a ToggleButton, you can do the
same as with the Button class.
button = ToggleButton (text)
You can retrieve the current state as boolean value of the
ToggleButton through its
active attribute and set its state
programmatically via this attribute or the
set_active() method.
if button.active:
print "The ToggleButton is currently active!"
button.set_active (False)
CheckButton and
RadioButton classes in the next sections.
To track changes of this state, the
ToggleButton supplies a SIG_TOGGLED
signal, which will be raised, if the state is changed via a
mouse input or the accelerator action of a
Label.
def state_changed (togglebutton):
state = "active"
if not togglebutton.active:
state = "inactive"
out = "The state of the ToggleButton has been set to %s" % state
button = ToggleButton ("A ToggleButton")
button.connect_signal (SIG_TOGGLED, state_changed, button)
Below you will find an example to illustrate most of the
abilities of the ToggleButton widget
class. You do not need to care about other widgets like the
Frame class for now as those are
explained later on.
You can find the following example as a python script under
examples/togglebutton.py.
# ToggleButton examples.
import os
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _create_vframe (text):
frame = VFrame (Label (text))
frame.spacing = 5
frame.align = ALIGN_LEFT
return frame
def create_button_view ():
states = ("STATE_NORMAL", "STATE_ENTERED", "STATE_ACTIVE",
"STATE_INSENSITIVE")
table = Table (2, 3)
table.spacing = 5
# Frame with the states.
frm_states = _create_vframe ("States")
for i in xrange (len (states)):
btn = ToggleButton (states[i])
if STATE_TYPES[i] == STATE_INSENSITIVE:
btn.sensitive = False
else:
btn.state = STATE_TYPES[i]
frm_states.add_child (btn)
table.add_child (0, 0, frm_states)
table.set_align (0, 0, ALIGN_TOP)
# Frame with different padding.
frm_padding = _create_vframe ("Padding")
for i in xrange (5):
btn = ToggleButton ("Padding: %dpx" % (i * 2))
btn.padding = i * 2
frm_padding.add_child (btn)
table.add_child (0, 1, frm_padding)
table.set_align (0, 0, ALIGN_TOP)
# Mnemonics.
frm_mnemonic = _create_vframe ("Mnemonics")
btn = ToggleButton ("#Simple Mnemonic")
btn2 = ToggleButton ("#Activate using <ALT><Underlined Key>")
frm_mnemonic.add_child (btn, btn2)
table.add_child (0, 2, frm_mnemonic)
table.set_align (0, 2, ALIGN_TOP)
# Multiline labeled buttons
frm_multiline = _create_vframe ("Multiline labels")
strings = ("Single lined ToggleButton",
"Two lines on" + os.linesep + "a ToggleButton",
"Two lines with a" + os.linesep + "#mnemonic")
for i in xrange (len (strings)):
button = ToggleButton (strings[i])
button.child.multiline = True
frm_multiline.add_child (button)
table.add_child (1, 0, frm_multiline)
table.set_align (1, 0, ALIGN_TOP)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (530, 400)
re.title = "ToggleButton examples"
re.color = (234, 228, 223)
re.add_widget (create_button_view ())
# Start the main rendering loop.
re.start ()
Example 26. ToggleButton example
The CheckButton, which inherits from the
ToggleButton, does not bring in any new
features. Instead it just uses a different look to display its
set state. The state of the CheckButton
is indicated by a small (usually 10x10 px) square, which is
either checked or unchecked.
To create a CheckButton widget, you
usually will do the same as with the
ToggleButton.
button = CheckButton (text)
Below you will find an example to illustrate most of the
abilities of the CheckButton widget
class. You do not need to care about other widgets like the
Frame class for now as those are
explained later on.
You can find the following example as a python script under
examples/checkbutton.py.
# CheckButton examples.
import os
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _create_vframe (text):
frame = VFrame (Label (text))
frame.spacing = 5
frame.align = ALIGN_LEFT
return frame
def create_button_view ():
states = ("STATE_NORMAL", "STATE_ENTERED", "STATE_ACTIVE",
"STATE_INSENSITIVE")
table = Table (2, 3)
table.spacing = 5
# Frame with the states.
frm_states = _create_vframe ("States")
for i in xrange (len (states)):
btn = CheckButton (states[i])
if STATE_TYPES[i] == STATE_INSENSITIVE:
btn.sensitive = False
else:
btn.state = STATE_TYPES[i]
frm_states.add_child (btn)
table.add_child (0, 0, frm_states)
table.set_align (0, 0, ALIGN_TOP)
# Frame with different padding.
frm_padding = _create_vframe ("Padding")
frm_padding.spacing = 5
frm_padding.align = ALIGN_LEFT
for i in xrange (5):
btn = CheckButton ("Padding: %dpx" % (i * 2))
btn.padding = i * 2
frm_padding.add_child (btn)
table.add_child (0, 1, frm_padding)
table.set_align (0, 0, ALIGN_TOP)
# Mnemonics.
frm_mnemonic = _create_vframe ("Mnemonics")
btn = CheckButton ("#Simple Mnemonic")
btn2 = CheckButton ("#Activate using <ALT><Underlined Key>")
frm_mnemonic.add_child (btn, btn2)
table.add_child (0, 2, frm_mnemonic)
table.set_align (0, 2, ALIGN_TOP)
# Multiline labeled buttons
frm_multiline = _create_vframe ("Multiline labels")
strings = ("Single lined CheckButton",
"Two lines on" + os.linesep + "a CheckButton",
"Two lines with a" + os.linesep + "#mnemonic")
for i in xrange (len (strings)):
button = CheckButton (strings[i])
button.child.multiline = True
frm_multiline.add_child (button)
table.add_child (1, 0, frm_multiline)
table.set_align (1, 0, ALIGN_TOP)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (550, 350)
re.title = "CheckButton examples"
re.color = (234, 228, 223)
re.add_widget (create_button_view ())
# Start the main rendering loop.
re.start ()
Example 27. CheckButton example
RadioButton widgets are similar to the
CheckButton widgets, except that they can
grouped, so that only one button of a group can be activated at
a time. This is especially helpful, if you need to have the user
to choose between a small amount of options.
The creation of a RadioButton is done using
button = RadioButton (text, group)
group argument can contain
another RadioButton object, with which
the newly created one should be grouped together.
Alternatively to the group argument of
the constructor, a RadioButton can be
assigned to a group after its creation with the
group attribute or
set_group() method.
button.group = other_radio_button
button.set_goup (other_radio_button)
RadioButton widgets from a group
with the add_button() or
remove_button() methods of the group.
Given those possibilities a group of four choices can be created like the following example.
group = RadioButton ("Choice 1")
button1 = RadioButton ("Choice 2", group)
button2 = RadioButton ("Choice 3")
button2.group = group
button3 = RadioButton ("Choice 4")
group.add_button (button3)
In contrast to its parent classes, activating a
RadioButton causes the other buttons in
its group to loose their active state.
Below you will find an example to illustrate most of the
abilities of the RadioButton widget
class. You do not need to care about other widgets like the
Frame class for now as those are
explained later on.
You can find the following example as a python script under
examples/radiobutton.py.
# RadioButton examples.
import os
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _create_vframe (text):
frame = VFrame (Label (text))
frame.spacing = 5
frame.align = ALIGN_LEFT
return frame
def create_button_view ():
states = ("STATE_NORMAL", "STATE_ENTERED", "STATE_ACTIVE",
"STATE_INSENSITIVE")
table = Table (2, 3)
table.spacing = 5
# Frame with the states.
frm_states = _create_vframe ("States")
group = None
for i in xrange (len (states)):
btn = RadioButton (states[i], group)
if i == 0:
group = btn
if STATE_TYPES[i] == STATE_INSENSITIVE:
btn.sensitive = False
else:
btn.state = STATE_TYPES[i]
frm_states.add_child (btn)
table.add_child (0, 0, frm_states)
table.set_align (0, 0, ALIGN_TOP)
# Frame with different padding.
frm_padding = _create_vframe ("Padding")
group = None
for i in xrange (5):
btn = RadioButton ("Padding: %dpx" % (i * 2), group)
if i == 0:
group = btn
btn.padding = i * 2
frm_padding.add_child (btn)
table.add_child (0, 1, frm_padding)
table.set_align (0, 0, ALIGN_TOP)
# Mnemonics.
frm_mnemonic = _create_vframe ("Mnemonics")
btn = RadioButton ("#Simple Mnemonic")
btn2 = RadioButton ("#Activate using <ALT><Underlined Key>", btn)
frm_mnemonic.add_child (btn, btn2)
table.add_child (0, 2, frm_mnemonic)
table.set_align (0, 2, ALIGN_TOP)
# Multiline labeled buttons
frm_multiline = _create_vframe ("Multiline labels")
strings = ("Single lined RadioButton",
"Two lines on" + os.linesep + "a RadioButton",
"Two lines with a" + os.linesep + "#mnemonic")
group = None
for i in xrange (len (strings)):
btn = RadioButton (strings[i], group)
if i == 0:
group = btn
btn.child.multiline = True
frm_multiline.add_child (btn)
table.add_child (1, 0, frm_multiline)
table.set_align (1, 0, ALIGN_TOP)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (550, 330)
re.title = "RadioButton examples"
re.color = (234, 228, 223)
re.add_widget (create_button_view ())
# Start the main rendering loop.
re.start ()
Example 28. RadioButton example
Entry boxes support the input of text or numerical values via the keyboard or similar input devices. They usually support the most common editing operations such as character input, deletion, etc.
The Editable class is an abstract base
class, which takes care of dealing with keyboard events and text
caret positioning. It is used as backend for the
Entry widget class, which will be
explained in the next section.
You usually will not create an Editable
object directly, but rather use it as parent for your own
classes.
It can store and operate on (unicode) text through its
text attribute. The text usually will be
set via this attribute or the
set_text() method.
editable.text = "Text"
editable.set_text ("Text")
It also supports a virtual text caret position, which will be
used by its internals to determine the position for editing
operations. The caret attribute and
set_caret() allow you to adjust the
caret position.
editable.caret = 7
editable.set_caret (7)
Given both the text and
caret attribute, the internals of the
Editable will modify the text of it upon
receiving keyboard events, if it has the input focus. Given an
Editable, which contains the text
"This is a Test." and its caret is set to
4, the processing of a pressed key ("D") causes:
Check, whether text editing is allowed.
If it is, insert a "D" at the fourth position in the text.
The text of it now is "ThisD is a Test"
The previous list mentioned a check, whether the text of an
Editable can be modified. To allow or
disallow editing the hold text, you can adjust the value of the
editable attribute.
editable.editable = True
editable.set_editable (True)
set_text() method.
The Editable listens by default to the
following signals:
SIG_KEYDOWN - Invoked, when a key gets pressed.
SIG_INPUT - Invoked, when the input is validated or aborted using RETURN or ESC.
The Entry widget is a single line text
input box, that inherits from the Editable
class. It fully supports the Editable
features and enhances it by mouse event sensitivity.
To create a Entry widget, you usually
will type
entry = Entry (text)
Entry widgets support a password-like
mode, in which any typed character will be displayed as an
asterisk ('*').
entry.password = True
To allow a better look for some special fonts, the
Entry can place an additional amount of
pixels between its border and the text input area via the
padding attribute or
set_padding() method.
entry.padding = 5
entry.set_padding (10)
Entry by default.
The Entry supports the SIG_MOUSEDOWN
signal to get the input focus upon a left
mouse button press.
Below you will find an example to illustrate most of the
abilities of the Entry widget class. You
do not need to care about other widgets like the
Frame class for now as those are
explained later on.
You can find the following example as a python script under
examples/entry.py.
# Entry examples.
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def create_entry_view ():
states = ("STATE_NORMAL", "STATE_ENTERED", "STATE_ACTIVE",
"STATE_INSENSITIVE")
table = Table (10, 10)
table.spacing = 5
# Frame with the states.
frm_states = VFrame (Label ("States"))
frm_states.spacing = 5
frm_states.align = ALIGN_LEFT
for i in xrange (len (states)):
entry = Entry (states[i])
if STATE_TYPES[i] == STATE_INSENSITIVE:
entry.sensitive = False
else:
entry.state = STATE_TYPES[i]
frm_states.add_child (entry)
table.add_child (0, 0, frm_states)
table.set_align (0, 0, ALIGN_TOP)
# Frame with different padding.
frm_padding = VFrame (Label ("Padding"))
frm_padding.spacing = 5
frm_padding.align = ALIGN_LEFT
for i in xrange (5):
entry = Entry ("Padding: %dpx" % (i * 2))
entry.padding = i * 2
frm_padding.add_child (entry)
table.add_child (0, 1, frm_padding)
table.set_align (0, 0, ALIGN_TOP)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (400, 400)
re.title = "Entry examples"
re.color = (234, 228, 223)
re.add_widget (create_entry_view ())
# Start the main rendering loop.
re.start ()
Example 29. Entry example
Range widgets denote any widget class, that is based on the
abstract Range widget class. Those widgets
usually support setting a value within a defined value range, such
as scaling widgets or scrollbars.
The Range widget class is an abstract
class, which enables inheriting classes to set and use value
ranges. It can make use of float values, thus providing a high
and for most cases exact resolution of values and it supports
setting minimum and maximum values as well as stepwise
increments.
You usually will not create a Range
object directly, but inherit from it in your own widget classes.
The constructor of a Range
range = Range (minimum, maximum, step)
Range.
The minimum attribute defines the lower
limit of the value range it serves, while the
maximum attribute defines the upper limit
of it. Both can be set either via the attribute or the
set_minimum() or
set_maximum() methods.
if range.minimum < 0:
range.set_minimum (0)
if range.maximum > 100:
range.set_maximum (100)
The step attribute of the
Range is useful to increment or decrement
the value of it in a constant manner. By default it is set to
1.0.
range.step = 10.0
range.set_step (-3.2)
The value of the Range can be read and
set via the value attribute and
set_value() method. It can not grow
beyond the upper or lower limit of the
Range. Assigning a value not within those
limitations will let it raise an exception.
range.value = 4.59
range.set_value (4.59)
For an efficient usage of the Range
within loops, etc. the increase() and
decrease() are supplied by it.
range.increase ()
range.decrease ()
The Range raises a SIG_VALCHANGED event,
whenever its value changed. This means a
real value change, reassignments of the same value are ignored.
The following example code shows this behaviour.
def val_changed (range):
print "The value changed to: %d" % range.value
range.connect_signal (SIG_VALCHANGED, val_changed, range)
if range.value != 10.0:
range.value = 10.0 # Signal handler is invoked.
range.value = 10.0 # Nothing happens.
Scale widgets separate in an abstract
Scale base class, which mainly contains
internal code needed by its both subclasses, the
VScale and HScale
widget. A Scale, inherited from the
Range, is a widget that lets you pick a
value from a range using a vertical
(VScale) or horizontal
(HScale) slider. Those both widgets only
differ in their appearance.
To create a HScale or
VScale widget, you typically will use the
same constructor syntax as for the Range
widget.
hscale = HScale (minimum, maximum, step)
vscale = VScale (minimum, maximum, step)
Range, the
minimum and
maximum arguments set the upper an lower
limit of the value range, while the step
argument sets the step range and defaults to 1.0.
The most important attributes and methods are already explained in the section called “Range”, so they will not be explained here again.
The Scale widgets listen to the three
available mouse events,
SIG_MOUSEDOWN - Invoked, when a mouse button is pressed
down on the Scale.
SIG_MOUSEUP - Invoked, when a mouse button is released on
the Scale.
SIG_MOUSEMOVE - Invoked, when the mouse moves over the
Scale.
Similar to the Scale widget, the
ScrollBar lets you pick a value from a
range, but additionally contains two buttons at its ends, which
allow the user to increment or decrement the value stepwise.
The ScrollBar is usually not used as
standalone widget, but instead serves as control in more complex
widgets, which need scrolling abilities.
In contrast to the Scale, the
ScrollBar uses a slider with a variable
size, which depends on the length of the
ScrollBar and the
maximum value of it. The slider however has
a defined minimum size, so that it will not shrink to an
unusable size by default.
The procedure to create a ScrollBar is
similar to the Scale and
Range.
hscrollbar = HScrollBar (minimum, maximum, step)
vscrollbar = VScrollBar (minimum, maximum, step)
The most important attributes and methods are already explained in the section called “Scale” and the section called “Range”, so they will not be explained here again.
The Scrollbar widgets listen to the three
available mouse events,
SIG_MOUSEDOWN - Invoked, when a mouse button is pressed
down on the ScrollBar.
SIG_MOUSEUP - Invoked, when a mouse button is released on
the ScrollBar.
SIG_MOUSEMOVE - Invoked, when the mouse moves over the
ScrollBar.
Container widgets are able to hold other widgets and take care of
drawing them on their own surface. They are mostly used for layout
purposes or complex widgets, which consist of several other
widgets or which need to add additional functionality to different
widget types (like the ScrolledWindow
widget). They allow to bind one or more widgets as child(ren) to
themselves and take over the role as parent widget.
The abstract Bin class is a container,
that is able to hold exactly one child. It allows to bind und
unbind a child widget and supports setting an additional padding
between its surface borders and the child surface.
You usually will not create a Bin
object directly, but inherit from it in your own widget classes.
The child of a Bin can be set with the
child attribute or
set_child() method. It is not necessary
to register the child at an event manager after binding it to
the Bin as this will set the event
manager of the child to its own one.
label = Label ("Label for a bin")
bin.set_child (label)
# No need to set an event manager explicitly for the label.
bin.manager = eventmanager
For layout purposes the Bin can make use
of additional pixels to place between its outer surface edges
and the child surface. This pixel amount can be modified and
used using the padding attribute of the
Bin. Various inheritors within the
widgets module of OcempGUI make heavy use of this attribute to
adjust the look of themselves. The following example
demonstrates this.
from ocempgui.widgets import Button, Renderer
renderer = Renderer ()
renderer.create_screen (200, 120)
button_5px = Button ("Button with 5px padding")
button_5px.position = 5, 5
button_5px.padding = 5
button_10px = Button ("Button with 10px padding")
button_10px.position = 5, 60
button_10px.padding = 10
renderer.add_widget (button_5px, button_10px)
renderer.start ()
Example 30. Bin.padding example
TODO: provide implementation examples
The abstract Container widget class is
similar to the Bin class, except that it
can hold more than one widget.
As well as with the Bin, you usually will
not create a Container object directly,
but inherit from it in your own class.
The children can be added and removed using the
add_child() and
remove_child() methods of the
Container. In contrast to the
Bin you cannot add those to the
children attribute directly, which also
should be modified by no means except, that
you know, what you are doing. Doing otherwise can result in an
unwanted misbehaviour of the Container
and GUI.
Adding multiple children at once is possible, while the removal of them can be done with one widget at a time only.
container.add_child (label1, button1, label2, entry1)
# Only one child can be removed at a time.
container.remove_child (button1)
Besides the padding attribute, which was
already explained in the section called “Bin” the
Container has a
spacing attribute, which indicates the
pixel amount to place between its children.
container.spacing = 10
Frame examples in the later section
will show you possible concrete results.
TODO: provide implementation examples
Frame widgets are
Containers, that support drawing a
decorative border and title widget around their children. The
basic Frame class is an abstract class,
which defines the common attributes and methods for its
inheritors, while the HFrame and
VFrame widgets are concrete
implementations, that place their children horizontally or
vertically. Both subclasses only differ in the placing behaviour
of their widgets and the basic aligning possibilities, so that,
if not stated otherwise, the following examples always apply to
both widget types, although the HFrame is
used.
The creation of a HFrame is done using
frame = HFrame ()
frame = HFrame (widget)
Frame. The title widget can be any valid
BaseWidget subclass and typically be
placed at the topleft corner of the
Frame. If no title widget is supplied, a
complete border will be drawn around the
Frame, while a set title widget will
discontinue that border at the topleft corner. You can change
or set the title widget at any later time. A few possibilities
should be shown here.
frame = HFrame (Label ("A title label"))
frame.widget = Button ("Button as frame title")
frame.set_widget (VFrame (Label ("Frame in a frame")))
To adjust the look of the Frame, it is
possible to change its border style using the
border attribute
frame.border = BORDER_NONE
frame.set_border (BORDER_SUNKEN)
frame.align = ALIGN_TOP
frame.align = ALIGN_LEFT
HFrame and
VFrame has to be made, because each one
only supports a subset of the alignment possibilities. The
HFrame widget natively supports aligning
its children at the top or bottom only
hframe.align = ALIGN_TOP
hframe.set_align (ALIGN_BOTTOM)
VFrame supports only the left
and right alignment.
vframe.align = ALIGN_LEFT
vframe.set_align (ALIGN_RIGHT)
Below you will find an example to illustrate most of the
abilities of the Frame widget
classes. You do not need to care about other widgets like the
Table class for now as those are
explained later on.
You can find the following example as a python script under
examples/frame.py.
# Frame examples.
import os
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def create_frame_view ():
table = Table (2, 3)
table.position = 5, 5
table.spacing = 5
# Create and display two 'standard' frames.
hframe = HFrame (Label ("Horizontal Frame"))
table.add_child (0, 0, hframe)
lbl = Label ("Vertical Frame" + os.linesep + "with 5 px spacing")
lbl.multiline = True
vframe = VFrame (lbl)
vframe.spacing = 5
table.add_child (0, 1, vframe)
for i in xrange(3):
btn = Button ("Button %d" % i)
hframe.add_child (btn)
btn2 = Button ("Button %d" % i)
vframe.add_child (btn2)
# Create framed frames.
framed1 = VFrame (Label ("VFrame"))
framed2 = HFrame ()
framed3 = VFrame (Label ("VFrame as HFrame.widget"))
framed3.add_child (Label ("Child of a VFrame"))
framed2.widget = framed3
framed2.add_child (Button ("Button 1"), Button ("Button 2"))
button = Button ("Simple Button")
framed1.add_child (framed2, button)
table.add_child (1, 0, framed1)
# Create a Frame with alignment.
frame_align = VFrame (Label ("VFrame with right alignment"))
frame_align.align = ALIGN_RIGHT
label1 = Label ("Label")
label2 = Label ("Even longer label")
button = CheckButton ("A CheckButton")
frame_align.add_child (label1, label2, button)
table.add_child (1, 1, frame_align)
# Add insensitive frames.
hframe = HFrame (Label ("Insensitive HFrame"))
hframe.sensitive = False
table.add_child (0, 2, hframe)
vframe = VFrame (Label ("Insensitive VFrame"))
vframe.sensitive = False
table.add_child (1, 2, vframe)
for i in xrange(3):
btn = Button ("Button %d" % i)
hframe.add_child (btn)
btn2 = Button ("Button %d" % i)
vframe.add_child (btn2)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (600, 300)
re.title = "Frame examples"
re.color = (234, 228, 223)
re.add_widget (create_frame_view ())
# Start the main rendering loop.
re.start ()
Example 31. Frame example
Table widgets, which inherit from the
Container class, allow a table-like
placement of their children in rows and columns. The children
can be placed in the table cells and each cell supports an
individual alignment.
The Table constructor expects the row and
column dimensions to set up for the table, so that
table = Table (2, 2)
table2 = Table (3, 5)
Adding children is different from the usual
Container methods. The
Table needs the additional information,
in which cell to place the child. Thus instead of using
table.add_child (child_widget1, child_widget2) # This does not work!
table.add_child (row, column, child_widget1)
table.add_child (row1, column1, child_widget2)
Table in
contrast works in the same way you already learned about in
the section called “Container”.
As said above, each cell of the Table
supports using an own alignment, which can be set with the
set_align() method.
table.set_align (0, 1, ALIGN_TOP)
table.set_align (1, 1, ALIGN_LEFT)
Table
documentation.
# Aligning the child at the topleft.
table.set_align (0, 1, ALIGN_TOP | ALIGN_LEFT)
# Conflicting alignments, thus using the higher priority of ALIGN_BOTTOM.
table.set_align (0, 1, ALIGN_TOP | ALIGN_BOTTOM)
# Again a conflict. ALIGN_NONE has the lowest priority, thus it will be
# left aligned.
table.set_align (0, 1, ALIGN_LEFT | ALIGN_NONE)
table.set_row_align (row, alignment)
table.set_column_align (column, alignment)
Below you will find an example to illustrate most of the
abilities of the Table widget class.
You can find the following example as a python script under
examples/table.py.
# Table examples.
from ocempgui.widgets import Renderer, Table, Label, Button
from ocempgui.widgets.Constants import *
def create_table_view ():
# Crate and display a Table.
table = Table (9, 2)
table.spacing = 5
table.position = 5, 5
label = Label ("Nonaligned wide Label")
table.add_child (0, 0, label)
table.add_child (0, 1, Button ("Simple Button"))
label = Label ("Top align")
table.add_child (1, 0, label)
table.set_align (1, 0, ALIGN_TOP)
table.add_child (1, 1, Button ("Simple Button"))
label = Label ("Bottom align")
table.add_child (2, 0, label)
table.set_align (2, 0, ALIGN_BOTTOM)
table.add_child (2, 1, Button ("Simple Button"))
label = Label ("Left align")
table.add_child (3, 0, label)
table.set_align (3, 0, ALIGN_LEFT)
table.add_child (3, 1, Button ("Simple Button"))
label = Label ("Right align")
table.add_child (4, 0, label)
table.set_align (4, 0, ALIGN_RIGHT)
table.add_child (4, 1, Button ("Simple Button"))
label = Label ("Topleft align")
table.add_child (5, 0, label)
table.set_align (5, 0, ALIGN_TOP | ALIGN_LEFT)
table.add_child (5, 1, Button ("Simple Button"))
label = Label ("Topright align")
table.add_child (6, 0, label)
table.set_align (6, 0, ALIGN_TOP | ALIGN_RIGHT)
table.add_child (6, 1, Button ("Simple Button"))
label = Label ("Bottomleft align")
table.add_child (7, 0, label)
table.set_align (7, 0, ALIGN_BOTTOM |ALIGN_LEFT)
table.add_child (7, 1, Button ("Simple Button"))
label = Label ("Bottomright align")
table.add_child (8, 0, label)
table.set_align (8, 0, ALIGN_BOTTOM |ALIGN_RIGHT)
table.add_child (8, 1, Button ("Simple Button"))
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (250, 350)
re.title = "Table examples"
re.color = (234, 228, 223)
re.add_widget (create_table_view ())
# Start the main rendering loop.
re.start ()
Example 32. Table example
ScrolledWindow widgets are
Bin widgets that add scrolling abilities
to their attached child. This is extremely useful for
situations, in which the widget to scroll should not exceed a
specific size, but has to display all of its data. Putting such
a widget in a ScrolledWindow allows you
to respect this specific size, while the widget can grow as it
wants.
You create a ScrolledWindow using
window = ScrolledWindow (width, height)
width and
height denote values for the
size attribute of the
ScrolledWindow. The newly created
ScrolledWindow will not exceed this size
by default.
The widget, which needs to be scrolled is packed into the
ScrolledWindow the usual
Bin way.
window.child = widget_to_scroll
To allow a flexibly scrolling behaviour, you can adjust the
scrolling attribute to make the
ScrolledWindow automatic scrolling,
always scrolling or never scrolling.
window.scrolling = SCROLL_ALWAYS
window.scrolling = SCROLL_NEVER
window.scrolling = SCROLL_AUTO
ScrollBar controls attached to the window
and is described in details in the
set_scrolling() method documentation.
You also can influence the scrollbars of the
ScrolledWindow programmatically.
window.vscrollbar.value = 0
window.hscrollbar.value = window.vscrollbar.maximum
ScrolledWindow to scroll to the topright
of its attached child.
The ScrolledWindow widget natively
listens to two signals to support better navigation
possibilities. Those are
SIG_MOUSEDOWN - Invoked, when a mouse button is pressed down on the ScrolledWindow.
SIG_KEYDOWN - Invoked, when a key gets pressed.
The ScrolledList widget class can be used
to display and manage collections in a list-style look and
feel. Technically it is a ScrolledWindow,
which holdes a ListViewPort that takes
care of displaying the list contents.
As the ScrolledWindow the
ScrolledList supports different scrolling
types and anything else, while the keyboard and mouse behaviour
differ slightly to match the needs of list browsing.
To create a ScrolledList you have to
supply the sizing dimensions and an optional collection, which
makes up the contents.
scrolledlist = ScrolledList (width, height, collection=None)
ListItemCollection (explained later)
object is automatically bound to it. The
ScrolledList however only accepts
collections, which inherit from the
ListItemCollection.
Items can be added and removed dynamically to the list using the items property.
for no in xrange (10):
scrolledlist.items.append (TextListItem ("Item no. %d" % no))
# Last one was too much.
scrolledlist.items.remove (scrolledlist.items[-1])
ListItemCollection wraps a list
and fully supports all important operations of, including
slicing, indexed item access and sorting. More details about the
ListItemCollection can be found in the section called “ListItemCollection”.
The FileList widget is useful to display
filesystem contents in a list-style manner. It supports the
distinction between different filetypes through the
FileListItem item type and allows you to
browse filesystem contents.
As the ScrolledList, from which the
FileList inherits, you need to pass the
size dimensions it should occupy and optionally the initial
starting directory to list the contents of.
filelist = FileList (200, 400, "/usr/home")
FileList will list the contents of the
current directory as set in os.curdir.
It allows to list directories programmatically through the
directory attribute and
set_directory() method.
filelist.directory = "C:\"
filelist.set_directory ("/tmp")
FileList will not
list it, but instead provide an acoustic signal using
print "\a".
The FileList additionally supports the
SIG_DOUBLECLICKED signal to allow changing directories
interactively. Of course own methods can be bound to it.
The windows of ocempgui.widgets are
containers, that have an own caption bar, can be moved within the
main pygame window and allow the user to collapse them to their
caption bar. They can be drawn on top of other widgets by
adjusting their depth attribute as already
explained in the section called “Common widget operations - the BaseWidget”.
The base for all the different window types is the
Window class. It is a
Bin container with the additional
ability to collapse itself to its caption bar.
To create a Window you can simply call
its constructor and provide an optional title text, that will be
used as caption.
window = Window ("My new window")
The title can be retrieved or set at any later time with the title attribute.
window.title = "A new title!"
As already mentioned above, the Window
allows the user to minimize it (and of course restore it), which
is also possible in your own code.
if not window.minimized:
window.minimize (True)
minimize() method you
can prevent the user from doing so, if you do not want it for a
certain window.
You can align the child of the window using the align attribute. Different alignments can be combined, although not any case makes sense and some alignment combinations conflict with each other.
# Align the child at the top.
window.align = ALIGN_TOP
# Align the child at the bottom left.
window.align = ALIGN_BOTTOM | ALIGN_LEFT
# Invalid alignment, ALIGN_BOTTOM has a higher priority, thus
# the child will be aligned at the bottom.
window.align = ALIGN_TOP | ALIGN_BOTTOM
Window uses an aligning
priority, which is explained in detail in the
Window documentation.
The Window widget by default listens to
the following signals:
SIG_MOUSEDOWN - Invoked, when a mouse button is pressed down on the Window.
SIG_MOUSEUP - Invoked, when a mouse button is released on the Window.
SIG_MOUSEMOVE - Invoked, when the mouse moves over the Window area.
Below you will find an example of the
Window widget class. You do not need to
care about the DialogWindow class for now
as this is explained in the next section.
You can find the following example as a python script under
examples/window.py.
# Window examples.
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _destroy_dialog (window):
window.child.text = "#Close"
def create_window_view ():
# Create and display a simple window.
window = Window ("Simple window")
window.child = Button ("#Not clickable")
window.child.connect_signal (SIG_CLICKED, window.destroy)
window.position = 5, 5
window.depth = 1
# Create dialog window.
dialog = DialogWindow ("Modal dialog window")
dialog.child = Button ("#Close first to use other widgets")
dialog.child.connect_signal (SIG_CLICKED, _destroy_dialog, window)
dialog.child.connect_signal (SIG_CLICKED, dialog.destroy)
dialog.position = 100, 5
dialog.depth = 2
return window, dialog
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (400, 200)
re.title = "Window examples"
re.color = (234, 228, 223)
re.add_widget (*create_window_view ())
# Start the main rendering loop.
re.start ()
Example 33. Window example
The DialogWindow is a modal
Window widget, that grabs all events that
are sent through the event manager it is attached to. The user
will not be able to interact with other event capable elements
until the DialogWindow is
destroyed. Widgets, that are attached to it of course will still
be notified.
The DialogWindow does not offer any new
features besides those it incorporates from its parent
class(es). To create a new DialogWindow
you use the same constructor syntax as for the
Window.
window = DialogWindow ("A new DialogWindow")
You can find an example of the
DialogWindow in Example 33, “Window example”.
It is often needed to know about how the user interacted with a
certain dialog. Creating various Buttons
with different callbacks or one callback, in which the buttons
are distinguished is of course possible, but finding a safe
distinction mode is a more complex task. You might argue, that
you could check the text of the Button,
but that only will work, if you do not want to offer localized
version of you program.
To circumvent this and other issues the
GenericDialog widget class was created.
It allows you to associate different states with the buttons you
want to place on it.
To create a GenericDialog you have to
pass two lists to its constructor, one containing the
Button widgets you want to display and one
with the result states to associate with.
list1 = [Button ("OK"), Button("Cancel")]
list2 = [DLGRESULT_OK, DLGRESULT_CANCEL]
dialog = GenericDialog ("Title", list1, list2)
influence the order of the buttons from left to right,
influence the results of the buttons.
This means, that the first Button in the
list will be displayed at the leftmost of all other
Buttons, while it will be associated with
the first item of the result list.
To allow a more flexible button and result behaviour (as needed in wizard dialogs for example), you can place new buttons and results at runtime on the dialog.
newlist1 = [Button ("Close"), Button ("Help")]
newlist2 = [DLGRESULT_CLOSE, DLGRESULT_USER]
dialog.set_buttons (newlist1, newlist2)
Now all you have to do is to connect your
GenericDialog with a callback for the
SIG_DIALOGRESPONSE signal, it listens to.
def my_callback (result, dlg):
if result == DLGRESULT_CLOSE:
dlg.destroy ()
elif result == DLGRESULT_USER:
...
dialog,connect_signal (SIG_DIALOGRESPONSE, my_callback, dialog)
To place your own widgets and contents in the dialog, you can
use the content attribute, which is a
VFrame.
label1 = Label ("Label 1")
entry = Entry ("Hello world")
dialog.content.add_child (label1, entry)
...
Frame widget type
applies to this one, too.
Below you will find an example of the
GenericDialog widget class.
You can find the following example as a python script under
examples/genericdialog.py.
# GenericDialog examples.
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _close (result, dialog, label):
if result == DLGRESULT_OK:
label.text = "You pressed OK!"
elif result == DLGRESULT_CANCEL:
label.text = "You pressed Cancel!"
elif result == DLGRESULT_CLOSE:
dialog.destroy ()
def create_dialog_view ():
buttons = [Button ("#OK"), Button ("#Cancel"), Button ("Clo#se")]
results = [DLGRESULT_OK, DLGRESULT_CANCEL, DLGRESULT_CLOSE]
dialog = GenericDialog ("Generic dialog", buttons, results)
lbl = Label ("Press the buttons to see the action.")
dialog.content.add_child (lbl)
dialog.connect_signal (SIG_DIALOGRESPONSE, _close, dialog, lbl)
dialog.position = 30, 30
dialog.depth = 1
return dialog
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (300, 300)
re.title = "GenericDialog examples"
re.color = (234, 228, 223)
re.add_widget (create_dialog_view ())
# Start the main rendering loop.
re.start ()
Example 34. GenericDialog example
The FileDialog widget allows the user to
choose files and directories from a
FileList and can return those easily by a
corresponding method. It also includes an
Entry widget at the top, which keeps
track of the current location and lets the user change the
directory path quickly.
To create a FileDialog you have would
type something like
dialog = FileDialog ("Select a file...", [Button ("OK")], [DLGRESULT_OK])
The selected file and directory entries can be received easily
using the get_filenames() method.
selection = dialog.get_filenames()
Below you will find an example of the
FileDialog widget class.
You can find the following example as a python script under
examples/filedialog.py.
# FileDialog examples.
import os
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _set_files (result, dialog, entry):
string = ""
if result == DLGRESULT_OK:
string = "".join(["\"%s\" " % f for f in dialog.get_filenames ()])
else:
string = "Nothing selected"
dialog.destroy ()
entry.text = string
def _open_filedialog (renderer, entry):
buttons = [Button ("#OK"), Button ("#Cancel")]
buttons[0].size = 80, buttons[0].size[1]
buttons[1].size = 80, buttons[1].size[1]
results = [DLGRESULT_OK, DLGRESULT_CANCEL]
dialog = FileDialog ("Select your file(s)", buttons, results)
dialog.depth = 1 # Make it the top window.
dialog.position = 100, 20
dialog.filelist.selectionmode = SELECTION_MULTIPLE
dialog.connect_signal (SIG_DIALOGRESPONSE, _set_files, dialog, entry)
renderer.add_widget (dialog)
def create_file_view (renderer):
table = Table (1, 2)
hframe = HFrame (Label ("FileList"))
hframe.add_child (FileList (200, 200))
table.add_child (0, 0, hframe)
hframe2 = HFrame (Label ("FileDialog"))
label = Label ("Selection:")
entry = Entry ()
entry.size = 200, entry.size[1]
button = Button ("#Browse")
button.connect_signal (SIG_CLICKED, _open_filedialog, renderer, entry)
hframe2.add_child (label, entry, button)
table.add_child (0, 1, hframe2)
table.set_row_align (0, ALIGN_TOP)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (550, 300)
re.title = "FileDialog examples"
re.color = (234, 228, 223)
re.add_widget (create_file_view (re))
# Start the main rendering loop.
re.start ()
Example 35. FileDialog example
The ImageMap is a widget, that can
display any type of image, pygame can handle, and supports
different mouse events.
In contrast to the ImageButton it does
not react visually upon those events, but can store the last
event, that occured as well as providing the relative position
coordinates of the event.
To create an ImageMap, you have to
provide an image surface or filename similar to the
ImageButton constructor.
imagemap = ImageMap ("path/to/an/image.png")
imagemap = ImageMap (pygame_surface)
set_picture() method.
Below you will find an example of the
ImageMap widget class.
You can find the following example as a python script under
examples/imagemap.py.
# ImageMap examples.
import os
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _get_type (eventtype):
if eventtype == SIG_MOUSEDOWN:
return "SIG_MOUSEDOWN"
elif eventtype == SIG_MOUSEUP:
return "SIG_MOUSEUP"
elif eventtype == SIG_MOUSEMOVE:
return "SIG_MOUSEMOVE"
else:
return "Unknown signal"
def _got_mouseevent (event, imagemap, labels):
labels[0].text = "Signal: %s" % _get_type (imagemap.last_event.signal)
if imagemap.last_event.signal != SIG_MOUSEMOVE:
labels[1].text = "Button: %d" % imagemap.last_event.data.button
else:
labels[1].text = "Button: None"
labels[2].text = "Event pos: %s" % str (imagemap.last_event.data.pos)
labels[3].text = "Rel. pos: %s" % str (imagemap.relative_position)
def _create_vframe (text):
frame = VFrame (Label (text))
frame.spacing = 5
frame.align = ALIGN_LEFT
return frame
def create_imagemap_view ():
frm_map = _create_vframe ("ImageMap")
imagemap = ImageMap ("image.png")
lbl_desc = Label ("Move the mouse over the ImageMap and" + os.linesep +
"press the mouse buttons to interact with it.")
lbl_desc.multiline = True
lbl_results = [Label ("Signal:"), Label ("Button:"), Label ("Event pos:"),
Label ("Rel. pos:")]
for label in lbl_results:
label.get_style()["fgcolor"][STATE_NORMAL] = (255, 0, 0)
imagemap.connect_signal (SIG_MOUSEDOWN, _got_mouseevent, imagemap,
lbl_results)
imagemap.connect_signal (SIG_MOUSEMOVE, _got_mouseevent, imagemap,
lbl_results)
imagemap.connect_signal (SIG_MOUSEUP, _got_mouseevent, imagemap,
lbl_results)
frm_map.add_child (imagemap, lbl_desc, *lbl_results)
return frm_map
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (550, 470)
re.title = "ImageMap examples"
re.color = (234, 228, 223)
re.add_widget (create_imagemap_view ())
# Start the main rendering loop.
re.start ()
Example 36. ImageMap example
The ProgressBar is a non-interactive
widget class, that uses a horizontal bar to display operation
efforts. Its value range reaches from 0.0 to 100.0.
To create a ProgressBar widget, you
simply will invoke its constructor with no arguments.
bar = ProgressBar ()
Similar to the Range widget class, the
ProgressBar supports the
step and
set_step() methods to set the step
range for continouos increments/decrements
bar.step = 1.4
bar.set_step (10)
# Increment/decrement the bar value by the currently set step range.
while process_runs:
bar.increment () # or bar.decrement ()
...
bar.value = 50.0
You can optionally display a short amount of text centered on it,
which can be set with the text attribute or
set_text() method.
bar.text = "Processing data..."
bar.set_text ("Please wait...")
Below you will find an example of the
ProgressBar widget class.
You can find the following example as a python script under
examples/progressbar.py.
# ProgressBar examples.
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
def _update_bar (bar, button):
if bar.value == 0:
while bar.value < 100:
bar.increase ()
bar.manager.force_update ()
button.text = "Clean the progressbar"
else:
while bar.value > 0:
bar.decrease ()
bar.manager.force_update ()
button.text = "Fill the progressbar"
def _update_text (bar):
bar.text = "%.2f" % bar.value + "%"
def _create_vframe (text):
frame = VFrame (Label (text))
frame.spacing = 5
frame.align = ALIGN_LEFT
return frame
def create_progressbar_view ():
table = Table (1, 3)
table.spacing = 5
# Create and display a simple ProgressBar.
frame = _create_vframe ("ProgressBar")
progress = ProgressBar ()
progress.step = 0.5
# Create a button to start filling.
btn = Button ("#Fill the ProgressBar")
btn.connect_signal ("clicked", _update_bar, progress, btn)
frame.add_child (progress, btn)
table.add_child (0, 0, frame)
# ProgressBar with text.
frame = _create_vframe ("Progressbar with text")
progress = ProgressBar ()
progress.text = "0.00%"
progress.step = 0.5
progress.connect_signal (SIG_VALCHANGED, _update_text, progress)
# Create a button to start filling.
btn = Button ("Fill the ProgressBar")
btn.connect_signal ("clicked", _update_bar, progress, btn)
frame.add_child (progress, btn)
table.add_child (0, 1, frame)
# Insensitive progressbar.
frame = _create_vframe ("Insensitive Progressbar")
progress = ProgressBar ()
progress.value = 50.0
progress.text = "50.00%"
progress.sensitive = False
frame.add_child (progress)
table.add_child (0, 2, frame)
return table
if __name__ == "__main__":
# Initialize the drawing window.
re = Renderer ()
re.create_screen (450, 150)
re.title = "ProgressBar examples"
re.color = (234, 228, 223)
re.add_widget (create_progressbar_view ())
# Start the main rendering loop.
re.start ()
Example 37. ProgressBar example
The following section covers the usage of the components used by
the ocempgui.widgets module. Components
denote elements, which are strongly wired with or used by a
widget, but do not inherit from the
BaseWidget in any way. The components can
be found in the ocempgui.widgets.components
submodule.
The ListItem component is an abstract
base class for creating own item implementations, which are
suitable for the usage in list or tree widgets. It contains a
set of attributes and methods, which make it ready to be used in
the ListItemCollection collection class.
You usually will not create ListItem
objects directly, but instead subclass them, whenever you need a
more advanced or specialized item type, than the
TextListItem and
FileListItem offer.
Similar to the widgets inheriting from the
BaseWidget class, the
ListItem offers a
style attribute, that lets you set up an
instance specific look and feel for it.
# Create the instance specific style information.
listitem.get_style()
listitem.style['font']['size'] = 16
The collection, the item should be or is bound to, can be read and set by accessing its collection attribute.
if listitem.collection != my_collection:
listitem.set_collection (my_collection)
To make the ListItem suitable for tree or
list widgets, it contains a selected
attribute that, as the name says, can be used by the according
widget implementation to set or determine the selection state of
the item.
if not listitem.selected:
listitem.selected = True
For optimization purposes in drawing the
ListItem contains, similar to the
BaseWidget, a dirty
attribute and set_dirty() method.
listitem.dirty = True
For concrete implementations and examples, the author recommends
to look at the source code of the
TextListItem and
FileListItem implementations, which will
be explained hereafter.
The TextListItem - as its name suggests -
is a ListItem, that is able to store and
show text. Besides this it does not offer anything oustanding so
that its only improvements are to set and get text.
A TextListItem is created by passing the
text it should store to its constructor.
listitem = TextListItem ("This is a TextListItem")
listitem.text = "I contain changed text."
The FileListItem is an advanced
TextListItem, which contains additional
attributes to make it suitable for storing different file
related information.
The FileListItem requires besides a text
the file mode information (those are explained in detail in the
stat documentation).
# Retrieve the stats for a file.
st = os.stat ("myfile")
# Create the item with the file modes.
listitem = ("myfile", st.st_mode)
Dependant on the passed file mode, which will be stored in the filetype attribute,
if stat.S_ISDIR (listitem.filetype):
print "Item %s is a directory, hooray!" % listitem.text
FileListItem will set load a matching
icon into its icon attribute (at
construction time). This icon will be taken from the
Icons16x16 icon constants of the
ocempgui.widgets.images submodule by
default.
The ListItemCollection is a wrapper
around the python builtin type list. It
supports a set of most important list operations, such as
iterators, slicing and sorting. Several methods, especially the
arithmetic overloads (addition, mulitplication, etc.) are not
available. For a complete list of supported operations, browse
the documentation strings of the
ListItemCollection.
The ListItemCollection is created by
simply invoking its constructor.
collection = ListItemCollection ()
insert(),
append() or
extend() methods for example.
collection.append (item1)
collection.insert (9, item2)
The specialities of the
ListItemCollection are, that it only
accepts ListItem objects as valid items
on the one hand and supports two notification slots on the
other. Those notification slots are implemented as attributes,
item_changed and
list_changed. Any method or function can be
bound to those to get informed about item changes in the list
(e.g. an item has changed its contents) and list changes in
general (items were added, removed, etc.). The
item_changed attribute additionally passes
the affected item to the notification handler, while
list_changed() will pass the
ListItemCollection.
You can find the following example as a python script under
examples/label.py.
# ListItemCollection example.
from ocempgui.widgets.components import ListItemCollection, TextListItem
# Item change handler.
def item_has_changed (item):
print "Item '%s' has changed" % item.text
# List change handler.
def list_has_changed (l):
print "List now contains %d item(s)" % l.length
collection = ListItemCollection ()
# Set up a notification handler for item changes.
collection.item_changed = item_has_changed
# Set up a notification handler for list changes
collection.list_changed = list_has_changed
for i in xrange (5):
collection.append (TextListItem ("Item no. %d" % i))
collection[2].text = "New text in item 3"
Example 38. ListItemCollection example
Sometimes it is necessary to create an own, specialized widget type, that matches your exact needs. The following section will give you an rough overview about what you have to keep in mind and about what you have to take care, when creating custom widgets. You are encouraged to browse the existing widget sourcecode in order to see, how the one or other is implemented.
In this section, you will create an own widget, that lets the user play the famous game TicTacToe and is able to deal with a custom SIG_TICTACTOE event.
First of all you should make yourself a picture about how the widget should look like and what it should be able to do. In our case, this would be an area consisting of 9x9 squares, of which each is clickable exactly one time and should fill - dependant on whose turn it is - the square with either a cross or a circle. When the game is ended, the widget should note that by sending a corresponding event, so that other widgets can update themselves according to that.
After you know about how it should look like and what it should be able to do, its time to collect the things you need. Whenever it is possible, you should use existing code or classes, so that you do not need to reinvent anything.
Luckily our example can be completed by using a
Table widget with 3 rows and 3 columns
and nine ImageButton widgets, that can
display the circle or cross. The only things, that do not exist
are the signal and graphics for a circle and cross.
We start by creating a custom class, that inherits directly from
the Table.
from ocempgui.draw import Image
from ocempgui.widgets import Table
from ocempgui.widgets.Constants import *
class TicTacToe (Table):
"""The famous game as widget.
"""
def __init__ (self):
Table.__init__ (self, 3, 3)
ImageButton widgets into the table. We
will size them to 60x60 px, so that they will not resize
later, when we set their images, which have a size of 48x48 px.
class TicTacToe (Table):
...
def __init__ (self):
Table.__init__ (self, 3, 3)
for i in xrange (3):
for j in xrange (3):
button = ImageButton ()
button.size = 60, 60
self.add_child (i, j, button)
class TicTacToe (Table):
...
def __init__ (self):
Table.__init__ (self, 3, 3)
self._curplayer = "Player 1"
for i in xrange (3):
for j in xrange (3):
...
button.connect_signal (SIG_CLICKED, self._clicked, button,
i, j)
_clicked() method, which we now
implement:
class TicTacToe (Table):
...
def __init__ (self):
...
def _clicked (self, button, i, j):
"""Sets the image of the button, if not already done.
"""
button = self.grid[(i, j)]
# Check, if it is not already set.
if button.picture == None:
if self._curplayer == "Player 1":
# Use the cross. As the ImageButton does not make use of
# transparency or colorkeys, we will load our images
# manually and set the image surface then.
button.picture = Image.load_image ("cross.png", True)
self._curplayer = "Player 2"
else:
button.picture = Image.load_image ("circle.png", True)
self._curplayer = "Player 1"
The widget is fairly usable now, but still lacks the event mechanism, which will be explained in the next section.
To allow a better interactivity with the TicTacToe widget, it will invoke its event handlers, whenever a player clicked on a square. Dependant on what happens, the event mechanism should indicate this. Thus it will have to pass additional data to the event handlers. We want it to send the following data:
"valid square", if the player clicked on an unoccupied button,
"invalid square", if the player clicked on an occupied button,
"win" + player name, if the one of the players wins. Further input should not be allowed afterwards.
Implementing the first and second event is easy and we only have to add four lines of code to our existing class. The first line will define the SIG_TICTACTOE signal.
from ocempgui.widgets import Table
from ocempgui.widgets.Constants import *
SIG_TICTACTOE = "tictactoe"
class TicTacToe (Table):
"""The famous game as widget.
"""
...
class TicTacToe (Table):
"""The famous game as widget.
"""
def __init__ (self):
...
self._signals[SIG_TICTACTOE] = []
class TicTacToe (Table):
...
def _clicked (self, button, i, j):
"""Sets the image of the button, if not already done.
"""
button = self.grid[(i, j)]
# Check, if it is not already set.
if button.picture == None:
if self._curplayer == "Player 1":
button.picture = "cross.png"
self._curplayer = "Player 2"
else:
button.picture = "circle.png"
self._curplayer = "Player 1"
self.run_signal_handlers (SIG_TICTACTOE, "valid square")
else:
self.run_signal_handlers (SIG_TICTACTOE, "invalid square")
The third event handler requires a bit more work as we have to check, if there are three buttons displaying the same picture in a row. The simplest (and unoptimized) algorithm for that would be:
Check all columns for the first, second and third line.
Check all lines for the first, second and third column.
Check diagonal the squares located at (0, 0), (1, 1) and (2, 2).
Check diagonal the squares located at (0, 2), (1, 1) and (2, 0).
class TicTacToe (Table):
...
def _check_input (self):
"""Checks for three in a row.
"""
three = False
image = None
# Check the columns
for i in xrange (3):
if three:
break
image = self.grid[(i, 0)].path
if image:
three = (self.grid[(i, 1)].path == image) and \
(self.grid[(i, 2)].path == image)
if not three:
# Check the rows.
for i in xrange (3):
if three:
break
image = self.grid[(0, i)].path
if image:
three = (self.grid[(1, i)].path == image) and \
(self.grid[(2, i)].path == image)
if not three:
# Diagonal left to right
image = self.grid[(0, 0)].path
if image:
three = (self.grid[(1, 1)].path == image) and \
(self.grid[(2, 2)].path == image)
if not three:
# Diagonal right to left
image = self.grid[(2, 0)].path
if image:
three = (self.grid[(1, 1)].path == image) and \
(self.grid[(0, 2)].path == image)
if three:
self._finished = True
self.run_signal_handlers (SIG_TICTACTOE, ("win", self._curplayer))
class TicTacToe (Table):
"""The famous game as widget.
"""
def __init__ (self):
...
self._finished = False
def _clicked (self, button, i, j):
"""Sets the image of the button, if not already done.
"""
if self._finished:
return
button = self.grid[(i, j)]
# Check, if it is not already set.
if button.picture == None:
if self._curplayer == "Player 1":
# Use the cross.
button.picture = "cross.png"
else:
button.picture = "circle.png"
self.run_signal_handlers (SIG_TICTACTOE, "valid square")
self._check_input ()
# Set it after the check, so we can get the correct player name.
if self._curplayer == "Player 1":
self._curplayer = "Player 2"
else:
self._curplayer = "Player 1"
else:
self.run_signal_handlers (SIG_TICTACTOE, "invalid square")
So far we are done. You can play a basic tic tac toe game and the widget can react upon the user input. It is however neither very usable nor nice to look at. All those things will be explained in the next section, but first let us look at the complete code.
You can find the code as a python script under
examples/tictactoe/TicTacToeSimple.py.
There is also a small starting test script called
tictactosimple.py as well as the both
needed graphics.
from ocempgui.widgets import *
from ocempgui.widgets.Constants import *
SIG_TICTACTOE = "tictactoe"
class TicTacToe (Table):
"""The famous game as widget.
"""
def __init__ (self):
Table.__init__ (self, 3, 3)
self._curplayer = "Player 1"
self._finished = False
for i in xrange (3):
for j in xrange (3):
button = ImageButton ("")
button.size = 60, 60
self.add_child (i, j, button)
button.connect_signal (SIG_CLICKED, self._clicked, button,
i, j)
self._signals[SIG_TICTACTOE] = []
def _clicked (self, button, i, j):
"""Sets the image of the button, if not already done.
"""
if self._finished:
return
button = self.grid[(i, j)]
# Check, if it is not already set.
if button.picture == None:
if self._curplayer == "Player 1":
# Use the cross.
button.picture = "cross.png"
else:
button.picture = "circle.png"
self.run_signal_handlers (SIG_TICTACTOE, "valid square")
self._check_input ()
# Set it after the check, so we can get the correct player name.
if self._curplayer == "Player 1":
self._curplayer = "Player 2"
else:
self._curplayer = "Player 1"
else:
self.run_signal_handlers (SIG_TICTACTOE, "invalid square")
def _check_input (self):
"""Checks for three in a row.
"""
three = False
image = None
# Check the columns
for i in xrange (3):
if three:
break
image = self.grid[(i, 0)].path
if image:
three = (self.grid[(i, 1)].path == image) and \
(self.grid[(i, 2)].path == image)
if not three:
# Check the rows.
for i in xrange (3):
if three:
break
image = self.grid[(0, i)].path
if image:
three = (self.grid[(1, i)].path == image) and \
(self.grid[(2, i)].path == image)
if not three:
# Diagonal left to right
image = self.grid[(0, 0)].path
if image:
three = (self.grid[(1, 1)].path == image) and \
(self.grid[(2, 2)].path == image)
if not three:
# Diagonal right to left
image = self.grid[(2, 0)].path
if image:
three = (self.grid[(1, 1)].path == image) and \
(self.grid[(0, 2)].path == image)
if three:
self._finished = True
self.run_signal_handlers (SIG_TICTACTOE, ("win", self._curplayer))
Example 39. Simple TicTacToe widget
The ocepgui.widgets module offers two
possibilities to change the provided widget appearance. This
section covers the necessary tasks, which have to be performed to
change create an own look and feel to match your personal needs.
The first part will give you a rough overview about how the
styling and drawing system of the
ocempgui.widgets module words, while the
second will explain the style files and syntax, that deal with
basic attributes such as background colors or fonts. The last part
then gives an in-depth explanation, how to provide own drawing
methods for a widget to spend it a completely different look
and feel (such as rounded borders for buttons for example).
The rendering engine contains several methods to draw each widget and some generalized methods for some commonly used parts such as the basic widget surface. The widget to draw is passed to its matching drawing method, which will look up its style settings and then draw it.
The Style supports cascading the widget
style settings. This means, that it will, when it retrieves the
widget style and does not find the style setting it needs, walk
through the inherited classes (the __mro__
attribute) of the widget until it finds the setting. The last
instance it looks the setting up in is the
"default" entry of its
styles attribute.
Theme files for OcempGUI define the most basic settings for the widgets, such as the background color or the font to use. They however do not cause the widget to look completely different. The basic widget layout will stay the same.
The theme files are read by the currently active
Style class (see the section called “Using own drawing routines” for details about the currently
active class) and their information will be stored in its
styles dictionary.
The currently active theme information for a specific widget
class are stored in the styles attribute by
using its lowercase classname. This means that the specific
theme for a Button widget is stored in
Style.styles["button"]. For a
Label widget it would be
Style.styles["label"] and so on.
Such an theme entry is a dictionary, that contains various
information such as the background and foreground color for the
different supported widget states, the font settings for that
widget and more. The complete list of possible settings can be
found in the documentation of the Style,
so it will not be covered in detail here.
Setting up individual styles should be done using an own file for them, so you can easily change them without touching your program code. Let us create a separate theme file, that will cause the buttons to use a blue background color and the labels a different font and foreground color.
After creating the file for that (the author recommends using
the suffix ".rc" for theme files), we use
the python syntax for the contents. First we have to let the
file and its content know about the supported widget states,
thus we will import the Constants of the
ocempgui.widgets module.
from ocempgui.widgets import Constants
Now we will set up our theme dictionary for the
Button widget.
from ocempgui.widgets import Constants
button = { "bgcolor" : { Constants.STATE_NORMAL : (18, 12, 135),
Constants.STATE_ENTERED : (32, 25, 164),
Constants.STATE_ACTIVE : (18, 12, 135),
Constants.STATE_INSENSITIVE : (54, 51, 106) }
}
Button to
different types of a dark blue color. It also will affect any
inherited widget, that does not
implement and own style explicitly,
define the style setting in its own style.
You can easily see this by placing a
Button and a
CheckButton side by side.
Let us now set the styles for the Label
widget. The first part sets up the font, its size and if
antialiasing should be used, the second one sets up different
colors to use for the text according to the widget its state.
from ocempgui.widgets import Constants
...
label = { "font" : { "name" : "Helvetica", "size" : 16, "alias" : True },
"fgcolor" : { Constants.STATE_NORMAL : (250, 250, 250),
Constants.STATE_ENTERED : (150, 150, 150),
Constants.STATE_ACTIVE : (0, 0, 0),
Constants.STATE_INSENSITIVE : (235, 235, 235) }
}
As you see, setting up own themes for widgets is not a complex task. Let us now examine the complete code and a small example, that will make use of the just created theme.
You can find the code and theme as python scripts under
examples/theme_example.rc and
examples/theme.py.
from ocempgui.widgets import Constants
button = { "bgcolor" : { Constants.STATE_NORMAL : (18, 12, 135),
Constants.STATE_ENTERED : (32, 25, 164),
Constants.STATE_ACTIVE : (18, 12, 135),
Constants.STATE_INSENSITIVE : (54, 51, 106) }
}
label = { "font" : { "name" : "Helvetica", "size" : 16, "alias" : True },
"fgcolor" : { Constants.STATE_NORMAL : (250, 250, 250),
Constants.STATE_ENTERED : (150, 150, 150),
Constants.STATE_ACTIVE : (0, 0, 0),
Constants.STATE_INSENSITIVE : (235, 235, 235) }
}
# Theme usage example.
from ocempgui.widgets import *
# Load the theme.
base.GlobalStyle.load ("theme_example.rc")
# Create screen.
re = Renderer ()
re.create_screen (200, 100)
re.title = "Theme example"
# Create widgets.
button = Button ("Button")
button.position = 5, 5
label = Label ("Label")
label.position = 100, 5
re.add_widget (button, label)
re.start ()
Example 40. Customizing the themes
Whenever you need an completely different layout, the creation of own theme files will not be enough. This section explains how to modify and/or override the drawing methods for the widgets.
First you should make yourself clear about if you need to provide and own layout only for specific instances of a widget or if those widgets always should be drawn that way. Dependant on your needs, you have several possibilites.
Subclass the widget and override its
draw() method.
Bind the draw() method of the
instance to your own method or function at runtime.
Provide an own Style subclass with
that particular drawing method for the widget type.
While the first both entries should not need any explanation, the last one includes a bit more work, so let us take a closer look at it.
We will create an own Style subclass and
use an own drawing method for Label
widgets, which adds a dropshadow to them by default. After
creating this subclass we will use an instance of it for our own
small test application.
The first we have to do is to inherit from the Style subclass.
from ocempgui.widgets import Style
class OwnStyle (Style):
def __init__ (self):
Style.__init__ (self)
Style class contains, too. To provide our
own drawing method for the Label, we have
to override the matching method, which is
draw_label().
As you can see from its signature, it receives one argument, the
Label object, for which the surface
should be created.
All widget drawing methods follow the same naming scheme, which is draw_WIDGETTYPE (self, widget).
We will use the existing draw_label()
method as template for our own one and modify it, so it matches
our needs.
def draw_label (self, label):
"""Overrides the label drawing method and adds a dropshadow."""
# We do not care about multiline labels. Thus pass those to the
# parent.
if label.multiline:
return Style.draw_label (self, label)
Now we shorten some attributes, which we will need in our method more often.
def draw_label (self, label):
...
cls = label.__class__
state = label.state
# Peek the style of the label so we can get the colors later.
st = label.style or self.get_style (cls)
Style class to look up the theme
information of the widget. The st variable
will be used to get and set the matching color for the
dropshadow of our Label.
Now will get the foreground color to use for the text and store
it temporarily as we will modify it in the st
variable later.
def draw_label (self, label):
...
# Save the label color temporarily as we will change it for the
# dropshadow. Because we are using references, not plain style
# copies, we have to do this.
fgcolor = self.get_style_entry (cls, st, "fgcolor", state)
# The 2px added here are used for the dropshadow.
width = 2 * label.padding + 2
height = 2 * label.padding + 2
Label surface will occupy. Because the
Label offers a
padding attribute, we have to take it into
account for the surface size.
The basics are set up, so that we can proceed with drawing the surfaces for our widget.
def draw_label (self. label):
...
# Draw the text.
front = None
drop = None
if label.mnemonic[0] != -1:
front = self.draw_string_with_mnemonic (label.text, state,
label.mnemonic[0], cls,
label.style)
# Swap colors.
st["fgcolor"] = { state : self.get_style_entry (cls, st,
"lightcolor",
state) }
drop = self.draw_string_with_mnemonic (label.text, state,
label.mnemonic[0], cls, st)
else:
front = self.draw_string (label.text, state, cls, label.style)
# Swap colors.
st["fgcolor"] = { state : self.get_style_entry (cls, st,
"lightcolor",
state) }
drop = self.draw_string (label.text, state, cls, st)
Label and then use either the mnemonic
string drawing method or the simple string drawing method. We
do that twice, for the normal text and its dropshadow. In line
eleven and nineteen we swap the foreground color of the
st variable with the brighter one, that is
set in st dictionary.
You might wonder, why we use the
get_style_entry() method here, as we
could simply assign their both variables. If you remember
correctly, what was stated in the section called “Changing the widget appearance”, the
style information are cascaded, thus it is not guaranteed, that
the lightcolor values are set. Therefore we
will use this (more or less) failsafe method to retrieve a valid
style entry for the lightcolor.
So we have our both surfaces now and are nearly done. But we
have to respect some definitions of the
BaseWidget and we have to reset the
swapped colors.
def draw_label (self, label):
...
# Surface creation done. Restore the colors.
st["fgcolor"][state] = fgcolor
# Get the size of the surface(s) and add it to the complete
# width and height, the label will occupy.
rect = front.get_rect ()
width += rect.width
height += rect.height
# Guarantee size.
if width < label.size[0]:
width = label.size[0]
if height < label.size[1]:
height = label.size[1]
def draw_label (self, label):
...
# Blit all and return the label surface to the caller.
surface = self.draw_rect (width, height, label.state, cls, label.style)
surface.blit (drop, (label.padding + 2, label.padding + 2))
surface.blit (front, (label.padding, label.padding))
return surface
So far so good. We now have our Style
subclass, that will draw Label widgets
with a dropshadow by default. The very last thing to do is to
make the omcepgui.widgets module use our
own class instead of the default. This is done by assigning the
base.GlobalStyle variable an instance of our
own class in the code, it should make use of it.
base.GlobalStyle = OwnStyle ()
Label widgets will use the just
created draw_label() method.
The complete code of the previous example follows. It includes some test code, so you can easily evaluate the results.
You can find the code as python script under
examples/style.py.
# Style usage example.
from ocempgui.widgets import *
class OwnStyle (Style):
def __init__ (self):
Style.__init__ (self)
def draw_label (self, label):
"""Overrides the label drawing method and adds a dropshadow."""
# We do not care about multiline labels. Thus pass those to the
# parent.
if label.multiline:
return Style.draw_label (self, label)
cls = label.__class__
state = label.state
# Peek the style of the label so we can get the colors later.
st = label.style or self.get_style (cls)
# Save the label color temporarily as we will change it for the
# dropshadow. Because we are using references, not plain style
# copies, we have to do this.
fgcolor = self.get_style_entry (cls, st, "fgcolor", state)
# The 2px added here are used for the dropshadow.
width = 2 * label.padding + 2
height = 2 * label.padding + 2
# Draw the text.
front = None
drop = None
if label.mnemonic[0] != -1:
front = self.draw_string_with_mnemonic (label.text, state,
label.mnemonic[0], cls,
label.style)
# Swap colors.
st["fgcolor"] = { state : self.get_style_entry (cls, st,
"lightcolor",
state) }
drop = self.draw_string_with_mnemonic (label.text, state,
label.mnemonic[0], cls, st)
else:
front = self.draw_string (label.text, state, cls, label.style)
# Swap colors.
st["fgcolor"] = { state : self.get_style_entry (cls, st,
"lightcolor",
state) }
drop = self.draw_string (label.text, state, cls, st)
# Surface creation done. Restore the colors.
st["fgcolor"][state] = fgcolor
# Get the size of the surface(s) and add it to the complete
# width and height, the label will occupy.
rect = front.get_rect ()
width += rect.width
height += rect.height
# Guarantee size.
if width < label.size[0]:
width = label.size[0]
if height < label.size[1]:
height = label.size[1]
# Blit all and return the label surface to the caller.
surface = self.draw_rect (width, height, label.state, cls, label.style)
surface.blit (drop, (label.padding + 2, label.padding + 2))
surface.blit (front, (label.padding, label.padding))
return surface
if __name__ == "__main__":
base.GlobalStyle = OwnStyle ()
re = Renderer ()
re.create_screen (200, 200)
re.title = "Style example."
re.color = (234, 228, 223)
label = Label ("Example label")
label.get_style ()["font"]["size"] = 30
label.position = 10, 10
label2 = Label ("#Mnemonic")
label2.get_style ()["font"]["size"] = 30
label2.position = 10, 60
button = CheckButton ("Dropshadow")
button.position = 10, 100
re.add_widget (label, label2, button)
re.start ()
Example 41. Customizing the widget drawing routines
Below you will find the Widget hierarchy of the
ocempgui.widget module.
BaseObject
+-ActionListener
|
BaseWidget
+-Label
+-Bin
| +-Button
| | +-ImageButton
| | `-ToggleButton
| | +-CheckButton
| | `-RadioButton
| +-ScrolledWindow
| | `-ScrolledList
| | `-FileList
| `-Window
| `-DialogWindow
| `-GenericDialog
| `-FileDialog
+-Container
| +-Frame
| | +-HFrame
| | `-VFrame
| `-Table
+-Editable
| `-Entry
+-Range
| +-Scale
| | +-HScale
| | `-VScale
| `-ScrollBar
| +-HscrolBar
| `-VScrollBar
+-ImageMap
+-ListViewPort
+-ProgressBar
`-StatusBar
Application programming interface
A library, which provides layers to accessibility solutions such as alternate input devices or online keyboards.
A revision control system.
Graphical user interface.
A set of python modules for writing games, based on the SDL.
A cross-platform scripting language.
See Simple DirectMedia Layer .
A cross-platform multimedia library.
A user interface element on a screen, with which the user can interact in a passive or active way.