The problem is that with Pyrex, and I believe this limitation stems from the C/Python API, you cannot share variables and functions between modules unless they are in a class. So if the _windows list is moved to soy.windows coreloop would no longer be able to access it, nor call a soy.windows.render(), nor any other technique we've thought of.
Widgets must add themselves to a list of widgets in their parent window upon creation, and this works, because the parent window is passed as an argument to the constructor. We have no such mechanism for Window objects.
So after some brainstorming, and looking at various workarounds, I started thinking in the direction of a parent class to Window called Screen. This objects of this class would not be generated by the user, but rather created as part of PySoy's init and placed in a soy.screens variable (which acts like a tuple).
Thus, you would say
mywindow = soy.windows.Window(soy.screens[0], 'My Window', size=(500,250)) or, should you wish, any other available screen. You could also look up or even change aspects of a screen through it's attributes. IE:
>>> soy.screens[0].depth
16
>>> soy.screens[0].size
(1024,768)
>>> mywindow.size
(500,250)
>>> soy.screens[0].fullscreen
None
>>> soy.screens[0].fullscreen = mywindow
>>> mywindow.size
(1024,768)We'll need to do more research as far as cross-platform support goes before being able to change resolution/depth, ie I believe with X11 we'll need to provide a list of available modes to select from, whereas on Windows we may be able to attempt any resolution/depth (I may be wrong?). Perhaps the .size could be __set__'able but only to valid modes?
Being as we need this before PySoy can compile w/o freeglut I think it's best we move forward with this and work out the wrinkles as we go along.
No comments:
Post a Comment