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.widgets
Various 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
Container
s, 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.