• OcempGUIHelpRequests

OcempGUI Help Requests

This place is for installation troubles and woes on running OcempGUI.

• Setting widget's text to something different than ascii string (in my case: Polish language string) causes the widget to display incorrectly. I've figured out, that widgets don't know how to handle utf-8 strings (trash on screen) and one HAS to decode the string to pure unicode for them to work. Is it a feature or a bug??

In the below example:

   1 button = Button ("Zażółć gęślą jaźń") # displays trash on the button
   2 button = Button ("Zażółć gęślą jaźń".decode('utf-8')) # this works fine

Note, that this is a problem in case gettext is used:

   1 button = Button (_(Hello, world)) # will not work
   2 # below line would be necessary and valid only
   3 # if the programmer is sure that gettext returns utf-8 string
   4 button = Button (_(Hello, world).decode('utf-8'))

• If you are using utf-8 text, you have to mark it as such using the u switch.

•    1 button = Button (u"Zażółć gęślą jaźń") # works like a charme with utf-8 encoding.
  

• Your gettext files should use utf-8 instead of native encodings, wherever possible. Make sure, your _() gettext macro returns a unicode string as well, not only a plain string. -- -- Marcusva 2008-04-11 06:17:06

• I installed python and pygame, everything works fine... But i cant get OcempGUI running. When i start the hello_world.py (from the example directory) i get the following error:

Traceback (most recent call last):
  File "C:\OcempGUI-0.2.1\doc\examples\hello_world_signals.py", line 2, in ?
    from ocempgui.widgets import *
  File "C:\Python24\Lib\ocempgui\__init__.py", line 45, in ?
    import ocempgui.widgets
  File "C:\Python24\Lib\ocempgui\widgets\__init__.py", line 34, in ?
    import base
  File "C:\Python24\Lib\ocempgui\widgets\base.py", line 29, in ?
    from Style import Style
  File "C:\Python24\Lib\ocempgui\widgets\Style.py", line 36, in ?
    from themes import default
ImportError: No module named themes

Would be nice if somebody could help me, thanks --Krabb

• It seems that the library was not installed correctly. How did you install it and where does the DEFAULTDATADIR constant inn C:\Python24\Lib\ocempgui\widgets\Constants.py point to?

• Are you sure you ran python setup.py install [your-additional-flags] correctly? --marcus

Ahh thanks, there must be something wrong... the constant points to "@DATAPATH@". Rerunning the install.py (with the argument "install") prints the following: (Its german, sorry :/ )

• @DATAPATH@ is definitely wrong here. The installation then did not do what it should have done (@DATAPATH@ will be replaced here). Rerunning the installation should only be done using a previous python setup.py clean and/or removing the newly created build directory.

• If this still does not help, it'd be great, if you could send me an installation log (by redirecting the installation output to a file) via email including such information as Windows version, etc.pp. -- Marcusva 2006-10-20 10:48:48

"Der Befehl "pkg-config" ist entweder falsch geschrieben oder konnte nicht gefunden werden." means something like: "The command "pkg-config" isn't spelled correctly or could not be located."

Der Befehl "pkg-config" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
The following information will be used to build OcempGUI:
         Python:     2.4.3
         Pygame:     1.7.1release
         ATK:        not found
         Build Papi: False
running install
running build
running build_py
running install_lib
running install_data
byte-compiling c:\python24\Lib\site-packages\ocempgui\widgets\Constants.py to Constants.pyc

I´m a python beginner, i have no clue whats going on What does "ATK" stand for? Could you help me again? Thanks --Krabb

• The error message about pkg-config can be silently ignored on Win32 systems because ATK (an accessibility toolkit) is not supported on this platform. Thus you won't have ocempgui.access.papi (a completely independant module) and that's all the error message is about. So do not worry about that. -- Marcusva 2006-10-20 10:48:48

• I am trying to get an exe from my code with py2exe. The process of creation is fine, but when I launch the exe file I get the error:

Traceback (most recent call last):
  File "elderlore.py", line 868, in ?
  File "elderlore.py", line 87, in __init__
  File "elderlore.py", line 634, in __init__
  File "el_gui.pyc", line 63, in __init__
  File "ocempgui\widgets\GenericDialog.pyc", line 103, in __init__
  File "ocempgui\widgets\DialogWindow.pyc", line 46, in __init__
  File "ocempgui\widgets\Window.pyc", line 110, in __init__
  File "ocempgui\widgets\BaseWidget.pyc", line 907, in <lambda>
  File "ocempgui\widgets\BaseWidget.pyc", line 408, in set_minimum_size
  File "ocempgui\widgets\BaseWidget.pyc", line 932, in <lambda>
  File "ocempgui\widgets\BaseWidget.pyc", line 513, in set_dirty
  File "ocempgui\widgets\Bin.pyc", line 205, in update
  File "ocempgui\widgets\BaseWidget.pyc", line 848, in update
  File "ocempgui\widgets\Window.pyc", line 314, in draw
  File "ocempgui\widgets\BaseWidget.pyc", line 767, in draw
  File "ocempgui\widgets\Window.pyc", line 307, in draw_bg
  File "C:\Python24\share\ocempgui\themes\default\DefaultEngine.py", line 1282, in draw_window
    font = String.create_font (fn, sz, fs)
  File "ocempgui\draw\String.pyc", line 135, in create_font
  File "ocempgui\draw\String.pyc", line 71, in create_file_font
RuntimeError: default font not found

Is there some font file I have to add ? My script is running fine through python.exe. Any help would be fine !

• It usually only ships with the tuffy.ttf in the examples/ directory, which is not the cause of the error. It merely sounds like that typical pygame bug with freesansbold.ttf not being deployed correctly. One often mentioned fix is to copy the freesansbold.ttf font of pygame manually into the distribution directory and to add it to the build process: http://www.pick.ucam.org/~ptc24/pygame_py2exe.html. As I never used py2exe, I have no idea how to do that exactly. -- Marcusva 2006-12-18 13:35:15

• You must add the freesansbold.ttf to your library.zip, in the pygame folder inside the zip. -- 201.14.23.89 2007-01-17 01:41:03

Thanks for your help. After solving this font problem, I bumped into the same py2exe problem Conrado met and talked about on dev forum. As a workaround, I isolated the files needed to run the binary file, and made a zip of them. You can find them here: http://sourceforge.net/project/showfiles.php?group_id=184938 You need to extract this file to the root of your C drive in order to run your binary file. I hope this will help anyone trying to use py2exe.

• I am using an ImageMap to display the main part of my game; I'd like to blit only a part of it and display the change to the screen, is it possible ?

• Not without some effort. You would have to override the draw() (and maybe draw_bg()) method of the ImageMap as well as to implement an optimized update() method for your widget. The draw() method of your new widget then would only blit the changed areas on its surface and its update() method would only pass the dirty area(s) of it to the parent.

• So instead of passing the oldrect variable to the parent's update() method you would pass it a rect that matches your area to update. Take a look at the BaseWidget's update() and draw() methods for details about how the updates work. The ImageMap's draw() method should be pretty self-explanatory. -- Marcusva 2007-01-05 13:11:51

Woah, that seems a little out of my knowledge capacity ! Would you have any plan to implement such a feature in a future release ? Anyway, thanks for your explanations.

• The ImageMap now supports such updates using the new invalidate() method in (available in CVS, will go into 0.2.6). You now can do somthing like:

• imagemap.picture.blit (surface, (50, 50))
  rect = surface.get_rect ()
  imagemap.invalidate (pygame.Rect (50, 50, rect.width, rect.height))
  

  • -- Marcusva 2007-01-22 23:31:22

• Hey, I'm loving OcempGui--excellent implementation and documentation. I have one little problem: I have a menu screen with a number of VFrames and Tables. After loading the menu widgets into the Renderer, then clearing the Renderer, and loading a new menu, I get:

• Fatal Python error: (pygame parachute) Segmentation Fault
  Aborted
  

Have you run across this at all? I've been poking through the Renderer code and my own, trying to catch when it happens, but I can't pin it down yet. All I know is that it happens somewhere in clearing the Renderer and adding a lot of new widgets.

-- DavidEyk

• Looking into the magic crystal sphere reveals nothing. Please provide some more information at which line (within the Renderer or your code) it breaks exactly and the relevant portion of your code, so this misbehaviour can be reproduced. -- Marcusva 2007-01-29 11:39:31

Well, now here's a problem: I delved deeper in with the debugger, and every time I run it, the Segmentation Fault happens at different iterations of a loop in my code. Here's the (simplified) loop in question:

•         for group in group_items:
              for stat in group[1]:
                  label = widgets.Label(stat)
                  this_resource = avatar.resources[stat]
                  res_label = self.mkResourceLabel(this_resource)
                  rows.append((label, res_label))
  

This is part of a loop to create Labels which eventually go into a Table which is wrapped in a VFrame. Each Table contains between 20-40 Labels. Here's simple take on the pattern: I create two Tables, add them to the Renderer, clear the Renderer, and create two more Tables. While iterating through the above loop for the fourth Table, I get the Segmentation Fault, but it varies as to which iteration of the loop faults. Sometimes it faults in the Label init, sometimes it faults in my loop, sometimes it faults in mkResourceLabel, which is just a factory method wrapper for Label().

I realize this is sketchy information--but it's as reproducible as I can get at the moment. What else would you like to know? --DavidEyk

• I cannot reproduce such a segfault here, even with multiple tables containing up to 100 cells each. Could you send me your source code so I can take a look into it or point me to a location where I can download it from? -- Marcusva 2007-01-30 09:54:09

I think I've tracked it down. I was subclassing Label and Entry to make widgets that tracked with variables on game objects. Here's the code for the Label subclass:

• class ResourceLabel(widgets.Label):
      """A label that tracks a given resource.
      """
      def __init__(self, resource):
          self._resource = resource
          dispatcher.connect(self.updateText, self._resource.signal)
          text = resource.value_str
          super(ResourceLabel, self).__init__(text)
      def __repr__(self):
          return "<%s sprite>" % (self.__class__.__name__)
      def __del__(self):
          try:
              dispatcher.disconnect(self.updateText, self._resource.signal)
          except DispatcherKeyError:
              pass
          try:
              super(ResourceLabel, self).__del__()
          except AttributeError:
              pass
      def updateText(self):
          """Update our Label's text.
          """
          self.text = self._resource.value_str
  

I was creating these ResourceLabels in the aforementioned loop, and I had a few of my ResourceEntry subclasses elsewhere on the screen. When I replaced the fancy subclassing with a fancy factory method that uses plain-vanilla widgets and some lambda magic, the segmentation fault disappears.

Might this have something to do with widgets being subclasses of Sprite? As you can see, I had to do a little dance to make the subclass work (with the repr and the del stuff). Any idea why this may have been happening? --DavidEyk

• Overriding the del() method does not produce that error on my side. Maybe it's your _resource attribute, which keeps some internal refs (no idea, what the _resource is exactly in your code)? -- Marcusva 2007-02-01 07:34:03

After some time and a lot of dead-ends, I think I may have accidentally discovered a solution. Running the garbage collector during the menu-state transitions seems to make the Segmentation Fault disappear (I was having unrelated(?) issues with zombie widgets). Or it may have been renaming _resource. So far so good. Thanks for taking the time to look at this. --DavidEyk

• Me again (--DavidEyk). Two issues:

• I've noticed that when I change a lot of Label text attributes all at once, it produces a "cascading" effect as each widget updates it's portion of the screen. Would it be worthwhile to make the changes all at once, then update the screen one time using the Renderer's update() on a fixed cycle? Will the Renderer make use of doublebuffering? Might this help at all, or am I re-arranging deck chairs on a slow CPU?

• If they are placed in a container widget, lock() the container when making those changes to the Labels and unlock() it once all are done. Calling the Renderer's update() method manually here would inflict the need to change the widget's update() methods as well as it invokes the Renderer's update() method. Thus I do not think, that this will be an easy task. The Renderer does not use the DOUBLEBUF flag by default, but it can be passed to the create_screen() method. -- Marcusva 2007-02-14 20:24:26

• Excellent advice--I do indeed get a superb speedup by locking the container when adding the labels. This will teach me to read the API docs more thoroughly. However, I'm now having the following problem: I lock the frame containing the table containing the labels, change the .text on some of the labels, then unlock the frame The labels never update themselves. I'm not exactly sure why. I could force a refresh, but this doesn't seem to be working as advertised. --DavidEyk

• Update: I mentioned that the labels were in a table in the frame. I was locking the frame. I tried locking the table instead, and the Labels update after they unlock. --DavidEyk

• This seems to be a bug. Usually the Table should be marked as dirty so it will be updated as soon as the Frame is unlocked. I'll look into it. -- Marcusva 2007-02-16 08:01:43

  • Related to the locking bug I cannot reproduce that behaviour. Could you please pass me your broken code? -- Marcusva 2007-02-19 17:04:21

  • Took me a little bit to find the correctly-broken version. I hope you can make sense of my source--I'm working solo on this right now, so you're the first person besides me to poke at it. The problem is in menus_ocemp.py. The columns (VFrames) are created around line 125 and get locked and unlocked at 225 and 230, when the RadioButtons get toggled.

  • Here's the source file in question:

  • http://wush.net/trac/worldsenough/browser/fey/gui/menus_ocemp.py?rev=301

  • Here's the source: http://eykd.net/pub/FreeSky-0.1a.dev.r295.tar.gz

  • --DavidEyk

    • Hmm, I should also mention--the above source includes a local OcempGUI 0.2.5 (gui/ocgui). There's also a patch (hack?) to RadioButton to explicity call SIG_TOGGLED when a radio is indirectly toggled off by another member of the group. --DavidEyk

  • Something seems to be updated there (the skills frame flickers and the labels move a bit), but the labels do not seem to receive the correct values. Did you recheck the code for that? -- Marcusva 2007-02-21 12:24:02

    • I didn't check directly. I just changed the setup so that the table is locked instead of the frame, and the value update appropriately. The only significant difference I can find is locking the frame versus locking the table. --DavidEyk

      • No idea what causes this issue then. Due to the complexity and threads debugging is really painful here. As long as it works for you, anything should be fine so far. If you however consider that problem again with other code pieces, try to make up an easy(ier) example to look into :-). -- 81.14.218.8 2007-02-21 20:41:36

  • Finally, I've got this locking issue figured out (I think). If I lock a container containing containers of widgets, then update those widgets, then unlock the container, I need to set container.dirty = True after unlocking, or those widgets never blit their way up to the top. At least, this is the case with the custom widgets I'm using, but I don't see how I'm overriding anything important in the update/draw chain of calls. This may be obvious, but I sure missed it for the longest time. --DavidEyk

• * Another speed issue. When building a complex screen with two tables of the abovementioned 20-40 labels, it takes several seconds on my Pentium III (speed demon that it isn't). During that time, if I wave the mouse around enough, I can fill up the pygame event queue and bring the game to an abrupt halt. Any thoughts on avoiding this pitfall?

• You can often gain incredible speedups for such cases by locking the container before you start e.g. adding your widgets (esp. for a large amount like those 20-40 Labels). Thus you would do something like:

• table = Table (10, 10)
  table.lock ()
  for i in xrange (100):
      # Add labels
      ...
  table.unlock () # This causes the Table to update after resetting the lock.
  

• Note, that for each lock() an unlock() has to appear. The event queue issue is something I have to investigate in - it sounds like a bug that should not happen on longer-lasting updates. -- Marcusva 2007-02-14 20:24:26

• I suspect that this (the event queue issue) may be a pygame issue rather than OcempGUI. During a blocking task (like drawing my complex screen before I added the locks), the loop won't get around to distribute_events() until the task is finished. I was waving the mouse around *a lot*, and it was producing a lot of events. After a little digging, I found that the pygame docs mention this off-handedly as a potential source of trouble. Since I'm using Simon Wittber's nanothreads for my main loop, I've "solved" the problem by throwing the blocking task off into a generator and yielding as often as I can. I'm also experimenting with a threadpool, since nanothreads supports full-on threads, but I'm not so sure about it yet. Anyway, best of luck in looking into it. --DavidEyk

• Sure, it is a messy behavior of pygame, but it is hard to avoid without loosing events (on the pygame side). The docs of the event queue explicitly state that we have to take care of it, so OcempGUI should, when it can (e.g. by flushing the queue in the Renderer.update() method). -- Marcusva 2007-02-16 08:01:43

  • I added a call to pygame's event.clear(SIG_MOUSEMOVE) to the end of the Renderer's update, and it seems to fix the problem on my side, with the added benefit of speeding up a lot of things (dragging dialog boxes, moving the mouse across a field of Buttons, etc.).

  • I've also implemented a lock/unlock feature for the Renderer--it's basically a duplication of the BaseWidget feature (except the unlock calls refresh instead of update). It's nice for adding widgets directly to the Renderer--everything shows up at once, instead of one by one.

  • If you want to see either of these changes, I can pass along my patches. --DavidEyk

    • Sure. Feel free to send them via mail to me. -- Marcusva 2007-02-23 19:12:42

• Hi, I've installed Python 2.5, Pygame 1.7.1 and Ocempgui 0.2.7 on Windows XP. When trying to run the included example program from the Ocempgui package I get an import error for the numeric module. As numeric is depreciated it took a bit of tracking down to find an installer for Python 2.5. If this is an Ocempgui rooted error then the source should be updated to use the Numpy module which is the successor to Numeric. Also when using mnenomics, the left-alt key works fine but right-alt has no effect. Thanks for your time.

• Pygame needs Numeric for its surfarray module, which is heavily used by OcempGUI (as stated in the README shipped with it).
  The right alt modifier usually sends a different key value to the system, thus it's not usable for the mnemonics. This however depends on the OS, the set keyboard type and modifier settings. There won't be any changes in OcempGUI to make use of the right alt key for mnemonics. Instead you should modify your keyboard settings to get the corresponding values. -- Marcusva 2007-03-28 12:53:51

• Hello, I have a few questions. I have been working with ocempgui and py2exe, and in order to get my exe files working on computers that don't have ocempgui installed, I needed to change two things in the ocempgui code.

The first change I needed to make was in the String.py file inside the draw folder. On line 71 I needed to make this change:

• #retval = PygameFont.Font (fontfile, size) retval = PygameFont.Font ('freesansbold.ttf', 10)

The reason for this change was that the exe would be unable to find a font otherwise. I have read of other people fixing this just by including the font in the library.zip file built by py2exe, however I could not get this to work for some reason unless I made the change above.

• This will prevent OcempGUI from using other fonts, you (or the user) choose. Better would be to pass the font to the method where necessary. If you do not use any other font, it should be okay however. -- Marcusva 2007-07-04 09:00:44

The second change I needed to make was in the Constants.py file inside the widgets folder. At the end of the file I changed @DATAPATH@ to:

• DEFAULTDATADIR = os.path.join("ocempgui")

After doing so I moved the themes folder directly into the ocempgui folder.

• That is perfectly fine as long as the subdirectory structure is preserved. -- Marcusva 2007-07-04 09:00:44

These changes were made in an uninstalled version of ocempgui. This is because I was afraid that the .pyc files might prevent the changes from working, and also because I didn't want to mess anything in my actual installation up. After making the changes, everything seems to work now. The exe files built with py2exe seem to run on any computer, without needing to install python or ocempgui.

My question is, do you think these changes are safe? I feel like it is a very hackish way to get py2exe working with my program, and am unsure if these changes would prevent anything in ocempgui from working correctly. I should mention that I am only doing this to make self contained windows binaries. I have been writing all my programs in linux, so these changes will only affect things compiled with py2exe, not the source code.

• It should be for the common cases. As I do not know much about py2exe and its options, I cannot guarantee it to work for all configurations and cases, but basically the changes are okay. If it works for you and your installation procedures, it should be safe to keep it like that. -- Marcusva 2007-07-04 09:00:44

• I have problems applying my own style to some elements. Is there any examples how to style a scrolledlist and it's items in both color and font? How should the rc-file look like? Is there any reference of all the elements in the style definition?

• The scrolledlist.py example under doc/examples contains a ScrolledList with items using a different font and color. The theme.py example and theme_example.rc file show you how to make your own rc-file and load it. The default.rc and DefaultEngine.py files under data/themes/default contain the default styles and drawing methods which you might want to take a look at for even more details.
  You also can find some indepth information about which style entries are available for the different widgets in the Style.py documentation. pydoc ocempgui.widgets.Style will show you them - or alternatively you can browse it online at http://ocemp.sourceforge.net/doc/index.html -- Marcusva 2007-07-25 08:10:20

Hanging on exit

Hello, I'm jumping into OcempGUI enthusiastically, since it looks very well developed. When I run the code from the FAQ in the section "Renderer integration into own pygame loop" via iPython everything works great and looks dandy until I attempt to close the window. At this point Python/Pygame becomes nonresponsive and eventually collapses into a force-quit. I tried out several other scripts from the example set, and they all displayed this behavior.

Interestingly, this behavior is limited to when I employ the iPython magic command "%run" to start the scripts. Normal command-line python interpreter prompts produce flawlessly-executing ocempGUI goodness. I wonder what could be causing this incompatibility. Certainly not a major flaw, but a curiosity.

This behavior noticed on WinXP with python 2.5.1, pygame 1.8.0, OcempGUI 0.2.9, iPython 0.8.2

Any ideas?

~~Theo

• This sounds much like the pygame issue with IDLE (http://www.pygame.org/wiki/FrequentlyAskedQuestions). The mentioned issue is caused by IDLE as it seems to keep some references to pygame and other modules, thus not invoking its exiting internals correctly. Try to use an explicit

•    1 pygame.quit()
  

• at the end of your exiting code. I'd expect it to work correctly after doing so, though I do not not know anything about how iPython works. -- Marcusva 2008-08-03 09:45:03