ocemp-devel — Development discussions for Ocean Empire

[ocemp-devel] ocempgui with py2exe

[David <dvk...@gm...>]

I have been dealing with this problem myself this afternoon.   I got past
the error you describe by copying the ocempgui directory system from its
site-packages home into the dist directory for my build, and adding a '
sys.path.insert ( 0, '' )' line to the script, so that the local ocempgui
module can be found.

Now, however, I get a 'NonImplementedError: surfarray module not available'=
,
at runtime.

The trace is below.  I attempted to 'import pygame.surfarray' explicitly in
the script, but that does not help.

Advice, anyone?
-----------------------------------
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\RenderLayer.py", lin=
e
150
, in update
    sprite.update ()
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\BaseWidget.py", line
584,
 in update
    self._image =3D self.draw ().convert ()
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\Table.py", line 337,
in d
raw
    return base.GlobalStyle.draw_table (self)
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\Style.py", line 1410=
,
in
draw_table
    width, height =3D table.calculate_size ()
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\Table.py", line 271,
in c
alculate_size
    widget.update ()
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\BaseWidget.py", line
584,
 in update
    self._image =3D self.draw ().convert ()
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\Frame.py", line 251,
in d
raw
    return base.GlobalStyle.draw_frame (self)
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\Style.py", line 1369=
,
in
draw_frame
    width, height =3D frame.calculate_size ()
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\Frame.py", line 202,
in c
alculate_size
    widget.update ()
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\BaseWidget.py", line
584,
 in update
    self._image =3D self.draw ().convert ()
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\Scale.py", line 283,
in d
raw
    return base.GlobalStyle.draw_scale (self)
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\Style.py", line 1449=
,
in
draw_scale
    BORDER_SUNKEN)
  File "C:\Python23\Lib\site-packages\ocempgui\widgets\Style.py", line 467,
in d
raw_border
    array =3D pygame.surfarray.array3d (surface)
  File "pygame\__init__.pyc", line 41, in __getattr__
NotImplementedError: surfarray module not available
------------------------------------------------------------


On 3/22/06, Brian Bull <Bri...@da...> wrote:
>
>  Hi all
>
> Last problem resolved. I've now got a working application running under
> ocempgui - yay. And it is, as I hoped, much quicker than the previous
> version of the app which used pgu.
>
> Something appears to be the problem, however, with my use of py2exe to
> convert the python program to a Windows .exe.  Specifically, the resultin=
g
> .exe fails with:
>
> IOError: [Errno 2] No such file or directory: [path]\\library.zip\\
> ocempgui\\widgets\\default.rc'
> Anyone got knowledge about use of py2exe with ocempgui and can suggest a
> fix?
>
> Many thanks
> B.
>



--
dk...@tr...
Pitcher's Duel -> pduel.sourceforge.net

[SOLVED] Re: [ocemp-devel] Intercepting keyboard events

[Charles D. <cd...@sp...>]

Duff wrote:
> I'm building a rewrite of Parallel 2 
> [http://www.lojban.org/tiki/tiki-index.php?page=Parallel+2&bl] using 
> Ocemp; so far, all is going well -- indeed, almost all core 
> functionality is in place.
>
> One thing I'm uncertain of, however: How can I capture keyboard 
> events? I'd like to intercept all events except those covered by 
> mnemonics, such that page-up/page-down/space/etc. can correspond with 
> actions within the tool.

What I ended up doing is this:

I created a separate class, called KeyListener, which implemented a 
notify method, and added it to the renderer (in its capacity as event 
manager) as a high-priority object. Code follows.

class KeyListener(object):
    def __init__(self, mainScreen):
        self.mainScreen = mainScreen
    def notify(self, event):
        if event.data.key == pygame.K_PAGEUP:
            self.mainScreen.modifyPos(-1)
            event.handled = True
        elif event.data.key == pygame.K_PAGEDOWN:
            self.mainScreen.modifyPos(1)
            event.handled = True
        elif event.data.key == pygame.K_SPACE:
            self.mainScreen.speak()
            event.handled = True
        ...

class MainScreen(object):
    ...
    def init(self):
        ...
        self.renderer.add_high_priority_object(KeyListener(self), SIG_KEYDOWN)
    ...

[ocemp-devel] Intercepting keyboard events

[Duff <cha...@is...>]

I'm building a rewrite of Parallel 2 
[http://www.lojban.org/tiki/tiki-index.php?page=Parallel+2&bl] using 
Ocemp; so far, all is going well -- indeed, almost all core 
functionality is in place.

One thing I'm uncertain of, however: How can I capture keyboard events? 
I'd like to intercept all events except those covered by mnemonics, such 
that page-up/page-down/space/etc. can correspond with actions within the 
tool.

Thanks!

[ocemp-devel] ocempgui with py2exe

[Brian B. <Bri...@da...>]

Hi all
 
Last problem resolved. I've now got a working application running under
ocempgui - yay. And it is, as I hoped, much quicker than the previous
version of the app which used pgu.
 
Something appears to be the problem, however, with my use of py2exe to
convert the python program to a Windows .exe.  Specifically, the
resulting .exe fails with:
 
IOError: [Errno 2] No such file or directory:
[path]\\library.zip\\ocempgui\\widgets\\default.rc'

Anyone got knowledge about use of py2exe with ocempgui and can suggest a
fix?
 
Many thanks
B.

Re: [ocemp-devel] Multi line labels?

[Marcus v. A. <ma...@sy...>]

On, Wed Mar 22, 2006, Brian Bull wrote:

> Hello,
> =20
> Am just starting using ocempgui for my project - I had been using Phil's
> Pygame Utilities but found performance unsatisfactory, ocempgui seems
> much more effective - so thanks to the developer(s).

Thanks for the flowers :-).

> =20
> I have a question. I need a particular sort of widget - a box that will
> contain text, and will wrap the text around if there is too much of it.
> Like a Label, but with automatic word wrapping (as opposed to a Label,
> where you can only get word wrapping by inserting '\n's).
> =20
> Does this exist in ocempgui? If not, can anyone suggest how it might be
> created?

No, such a widget does not exist in OcempGUI. You could however create
it more or less easily by inheriting from the Label class.

As the multiline label relies upon a fixed size, which is used to
determine the wraps, you could do the word wrapping as follows:

* Split the label text at word breaks, such as whitespaces, tabs,
  etc. Dependant on the character sets to support you cannot simply
  check for the whitespace character only as arabic and other sets can
  use various types of word or character spacings.
* Render and measure your newly created words one after each other and
  blit them on the Label surface (do not forget the spaces) until the
  complete width of the Label is occupied and/or the next word does not
  fit the rest width.
* Break to the next line of the Label (add the font height for that plus
  a little line spacing maybe) and continue to render, measure and blit.

I do not know, how the text rendering algorithms of pygame/SDL exactly
work, so it might be that you have to deal with overhanging glyphs
(e.g. for italic text and fonts), differing spacings and so on.
You might have noticed the above algorithm can become very slow, so
rendering and blitting a whole block of text after measuring it (slicing
the text might be your friend here) could perform better.

Certain character spacings such as vertical and horizontal tabs,
newline characters, etc. have to be handled here in a separate manner,
too, - dependant on your needs, of course.

Regards
Marcus

[ocemp-devel] Multi line labels?

[Brian B. <Bri...@da...>]

Hello,
 
Am just starting using ocempgui for my project - I had been using Phil's
Pygame Utilities but found performance unsatisfactory, ocempgui seems
much more effective - so thanks to the developer(s).
 
I have a question. I need a particular sort of widget - a box that will
contain text, and will wrap the text around if there is too much of it.
Like a Label, but with automatic word wrapping (as opposed to a Label,
where you can only get word wrapping by inserting '\n's).
 
Does this exist in ocempgui? If not, can anyone suggest how it might be
created?
 
Thanks
BB

Re: [ocemp-devel] Style Error

[Marcus v. A. <ma...@sy...>]

On, Mon Mar 06, 2006, Mr Mond wrote:

> Hi
>=20
> Using the following code as my style file:
>=20
>=20
> from ocempgui.widgets import Constants
> from pygame.locals import *
>=20
> dark_red =3D Color("DarkRed")[:3]
> red =3D Color("Red")[:3]

[...]

>=20
> Gives the following error:
>=20
>=20
> ...
>   File "E:\Python24\Lib\site-packages\ocempgui\widgets\Style.py", line 33=
0,
> in load
>     for key in widget:
> TypeError: iteration over non-sequence
>
>=20
> I'm using version 0.1.2.
>=20
> What's wrong with the style code?

Style files are currently limited to the following syntax only:

widgetclassname =3D { style_entry : { value(s) } }

This makes it currently impossible to use anything else besides
a) the widget class names and non-variable arguments/values
b) the 'import ocempgui.widgets.Constants' directive.

So using an 'import foo' or 'from bar import *' is likely to fail as
well as variable definitions and assignments are.=20
Yep, pretty lousy when it comes to such cases at the moment. There were
other priorities when 0.1.x was developed and only a minimum set of
necessities for a runtime style handling (give me a few more days for
other clumsy excuses here ;-).
I guess, that should become a necessary task for 0.2.x. If this is a
show stopper for you however, tell me and I'll make up a fix for that in
a few days.

> Is it possible to set the background of widgets to be transparent?

Not without implementing an own draw() method for the specified widget
in 0.1.x and some tweaks here and there. 0.2.x will have limited support
for that due to its different background handling (if you want more
details on that issue and how that stuff is currently done, please tell
me).

> How can I change where the text of an ImageButton is placed?

Override the ImageButton's draw() method in your own ImageButton
implementation or set up an own Style object with your specific
draw_imagebutton() method and bind it to the base.GlobalStyle
variable. More details on that and a short example can be found in the
manual. If you do so, I recommend you to look at the code in
Style.draw_imagebutton() and ImageButton.draw() to get a quick overview,
how it is currently done. Basically you just have to modify the blitting
rectangle values for the text.

Regards
Marcus

[ocemp-devel] Style Error

[Mr M. <mr...@us...>]

Hi

Using the following code as my style file:


from ocempgui.widgets import Constants
from pygame.locals import *

dark_red =3D Color("DarkRed")[:3]
red =3D Color("Red")[:3]

label =3D {"font":
            {"name": "Helvetica",
             "size": 10},
         "fgcolor":
             {Constants.STATE_NORMAL: dark_red,
              Constants.STATE_ENTERED: red,
              Constants.STATE_ACTIVE: red,
              Constants.STATE_INSENSITIVE: dark_red}
          }


Gives the following error:


...
  File "E:\Python24\Lib\site-packages\ocempgui\widgets\Style.py", line 330,
in load
    for key in widget:
TypeError: iteration over non-sequence


I'm using version 0.1.2.

What's wrong with the style code?

Is it possible to set the background of widgets to be transparent?

How can I change where the text of an ImageButton is placed?

Thanks again,

--
mond

RE: [ocemp-devel] OcempGUI unstable rendering patch #2

[Ben O. <bo...@ve...>]

> So basically a user could do something like with that enhancement.
>=20
> object.manager =3D renderer.manager[wanted_layer]

That's exactly what I had in mind. That would allow me to get my
existing OcempGUI code working in 0.2.0 with minimal effort. :)

Ben

Re: [ocemp-devel] OcempGUI unstable rendering patch #2

[Marcus v. A. <ma...@sy...>]

On, Thu Mar 02, 2006, Benjamin Olsen wrote:

> > Of course it is. I just wonder, if that is the right approach as the
> > object then would depend completely on the layer. This could cause it
> to
> > be not informed, if e.g. an event is sent to the previous layer and
> then
> > set as handled. As the Renderer will stop passing that event around
> this
> > could inflict some unwanted side effects on that object.
> >=20
> > Thus an independant Renderer or maybe an own slot to bind (an)
> additional
> > EventManager(s) to it would allow more flexibility. Or do I miss
> > something here?
>=20
> After thinking about for a bit, maybe the user just needs an easier way
> to attach an EventManager to a custom BaseObject. Perhaps something like
> the lambda functions at the bottom of Renderer (and most other OcempGUI
> classes). It's the user's responsibility to decide what needs to happen

Easier than doing object.manager =3D MyEventManagerInstance? Hard to
imagine ;-).

> on which layers, so maybe all the user needs is a more convenient way to
> call it from the Renderer. Does that make sense?

So that a user has full access to all layers. That's possible and an
enhancement I had in mind since this discussion came up :-).

So basically a user could do something like with that enhancement.

object.manager =3D renderer.manager[wanted_layer]

Regards
Marcus

Re: [ocemp-devel] Layering

[Marcus v. A. <ma...@sy...>]

On, Thu Mar 02, 2006, Mr Mond wrote:

> Hi
>=20
> I was wondering if I could get some advice on how to best approach the
> problem I'm having. On the main game screen I want to have sprites and
> surfaces layered like the following:
>=20
>       top
> __________   windows/dialogs
> __________   UI widgets
> __________   UI overlay image
> __________   surface with sprites and text (surface can be scrolled)
>    bottom
>=20
> How can I achieve this using the Renderer class? As I can only add sprites
> to Renderer would I have to make the overlay image a sprite?=20

No. Simply put the overlay image and scrollable surface into an own
surface and set this as background image for the Renderer. You should
use an own event loop for updates, etc. and pass the Renderer those
events after you did all necessary operations with and on them.

In short:

Prerequisites:
* Bind your background to the Renderer.

Main loop:
* Process events in your own event loop and draw and update your your
  background as necessary.
* Pass events to the Renderer object and enforce a manual update using
  your preferred mechanisms (update() and/or draw()).

> How can I add the text? I don't want it to be a label because I would

Use the pygame text drawing routines or the ocempgui.draw.String drawing
routines (which wrap the pygame stuff only and use some caching to speed
up things) and blit the text surfaces on your background surface.

> have to create a different style. How can I impose depth ordering for
> drawing?

If you want depth ordering for widgets only, set the 'depth' attribute
of widget to the wanted depth (see also the documentation of it), if not
provide some more information what you want to achieve with that.

> Would the new features of 0.2.x help me out? How suitable is it to use at
> the moment?

0.2.0 is not more than a rough idea and some experimental code at the
moment. Do not use it for productive development. It is likely that the
interfaces of the classes and internal processing will change every hour
;-).

> Thanks very much! Keep up the good work.

Thanks for the flowers.

Regards
Marcus

RE: [ocemp-devel] OcempGUI unstable rendering patch #2

[Ben O. <bo...@ve...>]

> Of course it is. I just wonder, if that is the right approach as the
> object then would depend completely on the layer. This could cause it
to
> be not informed, if e.g. an event is sent to the previous layer and
then
> set as handled. As the Renderer will stop passing that event around
this
> could inflict some unwanted side effects on that object.
>=20
> Thus an independant Renderer or maybe an own slot to bind (an)
additional
> EventManager(s) to it would allow more flexibility. Or do I miss
> something here?

After thinking about for a bit, maybe the user just needs an easier way
to attach an EventManager to a custom BaseObject. Perhaps something like
the lambda functions at the bottom of Renderer (and most other OcempGUI
classes). It's the user's responsibility to decide what needs to happen
on which layers, so maybe all the user needs is a more convenient way to
call it from the Renderer. Does that make sense?

Ben

[ocemp-devel] Layering

[Mr M. <mr...@us...>]

Hi

I was wondering if I could get some advice on how to best approach the
problem I'm having. On the main game screen I want to have sprites and
surfaces layered like the following:

      top
__________   windows/dialogs
__________   UI widgets
__________   UI overlay image
__________   surface with sprites and text (surface can be scrolled)
   bottom

How can I achieve this using the Renderer class? As I can only add sprites
to Renderer would I have to make the overlay image a sprite? How can I add
the text? I don't want it to be a label because I would have to create a
different style. How can I impose depth ordering for drawing?

Would the new features of 0.2.x help me out? How suitable is it to use at
the moment?

Thanks very much! Keep up the good work.

Regards,

mond

Re: [ocemp-devel] OcempGUI unstable rendering patch #2

[Marcus v. A. <ma...@sy...>]

On, Mon Feb 27, 2006, Benjamin Olsen wrote:

> > Right, this is not possible without some effort at the moment, as it
> has
> > to be specified on which layer the object should reside. Possibly an
> > additional 'catchall' EventManager for the Renderer should be added,
> > which is used to distribute the events to additional objects in the
> > first place.
> > Of course one could use an own additional EventManager, but that would
> > cause her to implement an own event loop. So I guess adding an
> > additional EventManager in the first place to the Renderer would be
> > sufficient here, not?
>=20
> Well, the Renderer already has a default EventManager on layer[0],
> right? I think it would be simpler to make the 'catchall' just linked to
> this default layer's EventManager. Is that possible?
>=20

Of course it is. I just wonder, if that is the right approach as the
object then would depend completely on the layer. This could cause it to
be not informed, if e.g. an event is sent to the previous layer and then
set as handled. As the Renderer will stop passing that event around this
could inflict some unwanted side effects on that object.

Thus an independant Renderer or maybe an own slot to bind (an) additional
EventManager(s) to it would allow more flexibility. Or do I miss
something here?

Regards
Marcus

RE: [ocemp-devel] OcempGUI unstable rendering patch #2

[Ben O. <bo...@ve...>]

> Right, this is not possible without some effort at the moment, as it
has
> to be specified on which layer the object should reside. Possibly an
> additional 'catchall' EventManager for the Renderer should be added,
> which is used to distribute the events to additional objects in the
> first place.
> Of course one could use an own additional EventManager, but that would
> cause her to implement an own event loop. So I guess adding an
> additional EventManager in the first place to the Renderer would be
> sufficient here, not?

Well, the Renderer already has a default EventManager on layer[0],
right? I think it would be simpler to make the 'catchall' just linked to
this default layer's EventManager. Is that possible?

Ben

Re: [ocemp-devel] OcempGUI unstable rendering patch #2

[Marcus v. A. <ma...@sy...>]

On, Fri Feb 24, 2006, Benjamin Olsen wrote:

> > Widgets are bound automatically to the 'correct' EventManager of their
> > layer, when they are added to the Renderer, so you usually do not need
> > to take care of that.
> > Of course they are correctly added to an EventManager, if they are
> > packed into a Bin or Container, which already has one (same processing
> > as with 0.1.x).
>=20
> I should clarify my EventManager question. When creating my own objects
> from BaseObject, I used to add them to my Renderer's EventManager by
> just setting a reference to the Renderer as their manager attribute.
> Short code example:
>=20
> ---------------------
> re =3D Renderer()
> myObj =3D Object(re)
>=20
> class Object(BaseObject):
>   def __init__(self, manager):
>     BaseObject.__init__ (self)
>     self._signals[MYSIG] =3D []
>     self.connect_signal(MYSIG, self._some_func)
>     self.manager =3D manager
> ---------------------
>=20
> With the new Renderer, there are EventManagers for every layer, and they
> aren't immediately obvious when connecting them to another object. How
> should I do the above code now?

Right, this is not possible without some effort at the moment, as it has
to be specified on which layer the object should reside. Possibly an
additional 'catchall' EventManager for the Renderer should be added,
which is used to distribute the events to additional objects in the
first place.
Of course one could use an own additional EventManager, but that would
cause her to implement an own event loop. So I guess adding an
additional EventManager in the first place to the Renderer would be
sufficient here, not?

Regards
Marcus

RE: [ocemp-devel] OcempGUI unstable rendering patch #2

[Ben O. <bo...@ve...>]

> Widgets are bound automatically to the 'correct' EventManager of their
> layer, when they are added to the Renderer, so you usually do not need
> to take care of that.
> Of course they are correctly added to an EventManager, if they are
> packed into a Bin or Container, which already has one (same processing
> as with 0.1.x).

I should clarify my EventManager question. When creating my own objects
from BaseObject, I used to add them to my Renderer's EventManager by
just setting a reference to the Renderer as their manager attribute.
Short code example:

---------------------
re =3D Renderer()
myObj =3D Object(re)

class Object(BaseObject):
  def __init__(self, manager):
    BaseObject.__init__ (self)
    self._signals[MYSIG] =3D []
    self.connect_signal(MYSIG, self._some_func)
    self.manager =3D manager
---------------------

With the new Renderer, there are EventManagers for every layer, and they
aren't immediately obvious when connecting them to another object. How
should I do the above code now?


> This sounds like your pygame installation is a bit out of date.
> Make sure, that you installed pygame-1.7.1 and that ocempgui refers to
> it. Previous versions (1.6.x) did not expose the pygame.Rect
attributes,
> so that the BaseWidget.initclass() method fails here.

Oops, good call.

Ben

Re: [ocemp-devel] OcempGUI unstable rendering patch #2

[Marcus v. A. <ma...@sy...>]

On, Wed Feb 22, 2006, Benjamin Olsen wrote:

> Hey Marcus,
>=20
> I finally had a chance to look at 0.2.0-alpha and have a couple
> questions:
>=20
> How does the EventManager work in the Renderer now? I looks like every
> layer gets its own EventManager. Since I like to inherit from BaseObject
> when creating my own classes, how do I tie in a layer's EventManager? It
> used to be simple, since the Renderer inherited from EventManager, I
> just sent it to my classes and gave them the Renderer as their
> EventManager. What's the right way to do it now? Does it matter which
> layer I use?

The new system sends events through the Renderer to all layers (the
EventManagers of the layers), so nothing critical changes. The layer
order however might be interesting as it works in the following way:

Renderer -> emit event on currently active layer (Renderer._active_layer)
Renderer -> emit event on all other layers, sliced at the active layer in
            reverse order (Renderer._get_layers()).

The active layer can be set either manually or is set automatically by
specific widgets, such as the Window widget. If a window receives the
input focus (e.g. through a mouse click), all events should be processed
on it first, such as keyboard navigation, hotkeys and so on.
If the event is not consumed by that layer, it is sent to the next lower
layer, from there to the next lower...

Only the mouse events are processed a differently as they are always
emitted on the topmost layer first and then on all the others in reverse
order. As we still do not have full 3D input and output support on
computers we have to stick with that 2D->3D emulation :-).

The topmost layer is the one with the highest id, by the way.

Widgets are bound automatically to the 'correct' EventManager of their
layer, when they are added to the Renderer, so you usually do not need
to take care of that.
Of course they are correctly added to an EventManager, if they are
packed into a Bin or Container, which already has one (same processing
as with 0.1.x).

> Also, widgets will have their Pygame rects created and available once
> they're created, right? I created a simple Button example to test
> things, and got an error about Label not having a width attribute. I did
> a quick work-around by putting these in Label.py's __init__:
>   self.width =3D 0
>   self.height =3D 0
>
> And then set the values in Style.py's draw_label function (around line
> 1025):
>   label.width =3D width
>   label.height =3D height
>=20
> Is this the idea you're going for? Will this be the way the rect
> attributes are created and set?

This sounds like your pygame installation is a bit out of date.
Make sure, that you installed pygame-1.7.1 and that ocempgui refers to
it. Previous versions (1.6.x) did not expose the pygame.Rect attributes,
so that the BaseWidget.initclass() method fails here.

Regards
Marcus

RE: [ocemp-devel] OcempGUI unstable rendering patch #2

[Ben O. <bo...@ve...>]

Hey Marcus,

I finally had a chance to look at 0.2.0-alpha and have a couple
questions:

How does the EventManager work in the Renderer now? I looks like every
layer gets its own EventManager. Since I like to inherit from BaseObject
when creating my own classes, how do I tie in a layer's EventManager? It
used to be simple, since the Renderer inherited from EventManager, I
just sent it to my classes and gave them the Renderer as their
EventManager. What's the right way to do it now? Does it matter which
layer I use?

Also, widgets will have their Pygame rects created and available once
they're created, right? I created a simple Button example to test
things, and got an error about Label not having a width attribute. I did
a quick work-around by putting these in Label.py's __init__:
  self.width =3D 0
  self.height =3D 0

And then set the values in Style.py's draw_label function (around line
1025):
  label.width =3D width
  label.height =3D height

Is this the idea you're going for? Will this be the way the rect
attributes are created and set?

Thanks,
Ben

> -----Original Message-----
> From: oce...@li... [mailto:ocemp-devel-
> ad...@li...] On Behalf Of Marcus von Appen
> Sent: Tuesday, February 14, 2006 6:54 AM
> To: Ocemp-devel
> Cc: Brad G
> Subject: [ocemp-devel] OcempGUI unstable rendering patch #2
>=20
> Hi,
>=20
> here is the next patchset for OcempGUI.
>=20
> The most notably change is a full z-axis support through different
layers
> in the Renderer class. Although it is not perfect for now, it seems to
> work quite well for most cases. The layers hold three items, a
separate
> widget list, an own EventManager for that layer and an indexing list
for
> the mnemonic and keyboard access. Event are sent to the last active
> layer first and then sent to the other ones in reverse layer order
> (highest layer depth first).
>=20
> Several update issues from the last patch have been fixed and
Containers
> as well as Bins should update themselves correctly now.
>=20
> The Window class has been changed in its event handling, but is still
> far away from being perfect. Windows still cause some problems, when
it
> comes to correct updates of underlyling/intersecting widgets, which
> hopefully will be fixed soon.
>=20
> Unfortunately several widgets are still broken, although some first
> attempts of redesigning them were made:
> StatusBar, ScrolledWindow, ScrolledList, ListViewPort, FileList,
> FileDialog
>=20
> The changes within the BaseWidget, which were introduced by the last
> patchset cause OcempGUI to depend on pygame > 1.7.1 from now on, as
the
> pygame.Rect class does not export its attributes clearly in earlier
> versions, which in turn prevents the BaseWidget.initclass() method
from
> exposing the pygame.Rect attributes.
>=20
> Those are the most important changes within that patchset. It should
> apply cleanly against the latest CVS version. Alternatively you can
> download a copy of my local development branch.
>=20
> The patch is available from:
>     http://ocemp.sourceforge.net/pre/ocempgui_patch_2.diff.gz
>=20
> A completely patched package can be downloaded from:
>     http://ocemp.sourceforge.net/pre/OcempGUI-0.2.0-alpha-2.tar.gz
>=20
> Regards
> Marcus

Re: [ocemp-devel] Installation error for OcempGui

[Marcus v. A. <ma...@sy...>]

On, Tue Feb 21, 2006, Kevin Field wrote:

> That sounds a bit confusing :p. I might just import draw and widget or

It is not that hard. You might read through the chapter for software
packaging and installation of the python documentation.

But of course you can go the easy way and simply copy the ocempgui/ and
data/ directory into your source distribution. Just make sure, that the
path for the icons in Icons16x16.py is set correctly, if you want to use
the FileList or FileDialog widgets from ocempgui.widgets.

> something like that. By the way-what is the attachment that you attached to
> the previous email? I looked at it but it is only gibberish. Thanks for your

This is a GPG/PGP signature, that verifies, that I am the sender and not
someone else misusing my mail address.

Regards
Marcus

Re: [ocemp-devel] Installation error for OcempGui

[Kevin F. <kev...@gm...>]

That sounds a bit confusing :p. I might just import draw and widget or
something like that. By the way-what is the attachment that you attached to
the previous email? I looked at it but it is only gibberish. Thanks for you=
r
time.


On 2/21/06, Marcus von Appen <ma...@sy...> wrote:
>
> On, Tue Feb 21, 2006, Kevin Field wrote:
>
> > Hi,
> > I am creating a pygame script for bowling but have been having trouble
> with
> > creating objects like rectangles. OcempGui seemed like a good choice fo=
r
> > ease of use, but I came up with an error for installation.
> > When I run python setup.py install in the command line given by windows=
,
> i
> > get this error
> > error: package directory 'ocempgui' does not exist.
> > Do you have any idea what I am doing wrong? I am doing this on my P:
> drive
> > at school, and python is installed on C:. I do not have access to C:
> with
> > explorer, but I can get to it with command line.
>
> Sounds like you do not have write access to the python installation
> directory on C:. Make sure, you have or install the package to another
> prefix using the --prefix argument. Unfortunately you might have to
> patch the ocempgui/widgets/images/Icons16x16.py  file to make sure, it
> uses your new prefix and not sys.prefix.
>
> There might some other errors occur, which I am currently not aware of.
> If this is the case, tell me and we surely will find a solution.
>
> Regards
> Marcus
>
>
>


--
Sincerely,
Kevin Field

Re: [ocemp-devel] Installation error for OcempGui

[Marcus v. A. <ma...@sy...>]

On, Tue Feb 21, 2006, Kevin Field wrote:

> Hi,
> I am creating a pygame script for bowling but have been having trouble with
> creating objects like rectangles. OcempGui seemed like a good choice for
> ease of use, but I came up with an error for installation.
> When I run python setup.py install in the command line given by windows, i
> get this error
> error: package directory 'ocempgui' does not exist.
> Do you have any idea what I am doing wrong? I am doing this on my P: drive
> at school, and python is installed on C:. I do not have access to C: with
> explorer, but I can get to it with command line.

Sounds like you do not have write access to the python installation
directory on C:. Make sure, you have or install the package to another
prefix using the --prefix argument. Unfortunately you might have to
patch the ocempgui/widgets/images/Icons16x16.py  file to make sure, it
uses your new prefix and not sys.prefix.

There might some other errors occur, which I am currently not aware of.
If this is the case, tell me and we surely will find a solution.

Regards
Marcus

[ocemp-devel] Installation error for OcempGui

[Kevin F. <kev...@gm...>]

Hi,
I am creating a pygame script for bowling but have been having trouble with
creating objects like rectangles. OcempGui seemed like a good choice for
ease of use, but I came up with an error for installation.
When I run python setup.py install in the command line given by windows, i
get this error
error: package directory 'ocempgui' does not exist.
Do you have any idea what I am doing wrong? I am doing this on my P: drive
at school, and python is installed on C:. I do not have access to C: with
explorer, but I can get to it with command line.
Thank you for your time.
--
Sincerely,
Kevin Field

[ocemp-devel] OcempGUI 0.1.2 released

[Marcus v. A. <ma...@sy...>]

OcempGUI 0.1.2 has been released.

OcempGUI is a python based toolkit for creating (graphical) user
interfaces using the pygame library. It offers various widgets and base
classes, which make it suitable for a broad range of projects and easily
extensible.

Dependencies
------------
* python (>= 2.3)       http://www.python.org
* pygame (>= 1.6)       http://www.pygame.org

Features in 0.1.2
-----------------
events package:
  * Added EventManager.emit_event() method, which emits Event objects.

widgets package:
  * New method set_children() in Container class, which allows to set
    the children of a Container using lists of widgets.
  * New method insert_child() in Container class, which allows to insert
    a widget at a specific position within the Container.

Changes in 0.1.2
----------------
* Minor typo fixes and corrections in the documentation.
* Improved TicTacToe example.

widgets package:
  * Changed Label.multiline behaviour from os.linesep checks to
    newline (\n) checks.
  * Fixed a bug in Label.set_widget(), which prevented it from being
    reset.
  * Fixed a minor height calculation bug in the Window class.
  * Fixed a bug in the Renderer which caused it to loose its set
    background.

Download
--------
The package and its signature are available from here:
http://sourceforge.net/project/showfiles.php?group_id=100329release_id=394069

MD5 sum = 3f2b7e654df555d757560d8bf4bf90cb

Regards
Marcus

[ocemp-devel] OcempGUI unstable rendering patch #2

[Marcus v. A. <ma...@sy...>]

Hi,

here is the next patchset for OcempGUI.

The most notably change is a full z-axis support through different layers
in the Renderer class. Although it is not perfect for now, it seems to
work quite well for most cases. The layers hold three items, a separate
widget list, an own EventManager for that layer and an indexing list for
the mnemonic and keyboard access. Event are sent to the last active
layer first and then sent to the other ones in reverse layer order
(highest layer depth first).

Several update issues from the last patch have been fixed and Containers
as well as Bins should update themselves correctly now.

The Window class has been changed in its event handling, but is still
far away from being perfect. Windows still cause some problems, when it
comes to correct updates of underlyling/intersecting widgets, which
hopefully will be fixed soon.

Unfortunately several widgets are still broken, although some first
attempts of redesigning them were made:
StatusBar, ScrolledWindow, ScrolledList, ListViewPort, FileList, FileDialog

The changes within the BaseWidget, which were introduced by the last
patchset cause OcempGUI to depend on pygame > 1.7.1 from now on, as the
pygame.Rect class does not export its attributes clearly in earlier
versions, which in turn prevents the BaseWidget.initclass() method from
exposing the pygame.Rect attributes.

Those are the most important changes within that patchset. It should
apply cleanly against the latest CVS version. Alternatively you can
download a copy of my local development branch.

The patch is available from:
    http://ocemp.sourceforge.net/pre/ocempgui_patch_2.diff.gz

A completely patched package can be downloaded from:
    http://ocemp.sourceforge.net/pre/OcempGUI-0.2.0-alpha-2.tar.gz

Regards
Marcus