|[pygame] SGC 0.1.4 Released||Sam Bull||6/8/12 4:54 AM|
I have been working on this toolkit as part of GSoC, and am ready to
announce the next beta release.
The main features of this release is more consistent widget sizing by
making labels external to their widgets. There has also been some work
on extending the support for events, with a new tutorial in the
documentation to explain how this works.
If you'd like to try it out, download the release code. As long as you
have Python 2 and Pygame installed, you should be able to run the
example file immediately.
To use it in your own projects, simply copy the 'sgc' sub-folder into
the top-level of your project or use setup.py to install it system-wide.
Please check it out at:
As before, you can check out the documentation at:
If you'd prefer an offline Devhelp version, there is a separate download
I'd appreciate any feedback on the project or the documentation,
including the new events tutorial.
Limitations still in this beta release:
No Python 3 support.
Using custom images is not documented or properly tested (coming
in the next release).
OpenGL support is not working in this release.
There's an issue with transparency, so (0,0,0) means
transparency in this release, if you find things are invisible
try changing the colour (perhaps (0,0,1)).
There's no developer documentation to help write your own
|Re: [pygame] SGC 0.1.4 Released||illume||6/10/12 12:28 AM|
I like how you have integrated the GUI events with a normal pygame event loop: http://program.sambull.org/sgc/tutorial.events.html
For example, a quit button could work like the following:
if e.type == QUIT or (e.type == GUI and e.widget == quit_button):
Could the tutorials be based on examples? Then people can run the example, and learn that way as well.
You might want to consider putting the examples in sgc.examples with relative imports, so they are easier to run. Likewise, consider adding your unit tests into somewhere like sgc.tests.
Dirty rects are important for performance when not using opengl, have you considered using pygame.sprite.DirtySprite instead of pygame.sprite.Sprite for a base class?
For those not familiar with launchpad...
You need bazaar (http://bazaar.canonical.com/en/)
Then to checkout the branch:
bzr co lp:simplegc
Or you can browse the code online:
|Re: [pygame] SGC 0.1.4 Released||Mike Fletcher||6/10/12 7:55 PM|
On 12-06-10 03:28 AM, Ren� Dudfield wrote:> if e.type == QUIT or (e.type == GUI ande.widget == quit_button):
>I believe one of them is already (the helloworld.py tutorial). Making
all of the tutorials example code does sound like a good idea.
> You might want to consider putting the examples in sgc.examples withKeep in mind, that then the user of the library needs to *delete* them
from the library when they copy the library into their game (or have
extra code and data-files in their project). (Sam moved the examples
*out* at my suggestion, actually). If the examples get beyond a few
trivial files (which I'm hoping they will, as they begin to show how to
use custom images and the like), then that may be a non-trivial size.
Similar issue for the unit tests; if there are enough to be worthwhile
they'll be a non-trivial amount of code, likely with quite a few
As for relative imports; I'm not sure I follow the logic there. If sgc
is on the path (either because you ran setup.py install/develop or
because you are in the root source-code directory), then the examples
should all run. If it's not, then a relative import doesn't, AFAIK,
work (that is, from .. import X will just report "Attempted relative
import in a non-package")?
Anyway, just my thoughts,
Mike C. Fletcher
Designer, VR Plumber, Coder
|Re: [pygame] SGC 0.1.4 Released||illume||6/11/12 12:31 AM|
good points about not including. I can see how the size could get quite large. The smaller the better!
By realtive imports, I mean so people can do:
At the moment, newbies trying it out will just get a failure.
Including the tests, and examples also makes testing easier. No matter how they have installed it, you can ask people to do:
python -m scg.tests
Often people will install by pip or something, and not have the source. Which means the examples won't be installed, and they will give up.
python -m scg.examples.helloworld
You can also get tests to run on remote hosts easily as part of the install process. For example, when pypm (and other bots) grab packages from pypi, the run the setup code, which you can get to run tests. That way you get a bunch of remote testing hosts for free.
Doesn't really matter either way I guess. Each way has upsides, and downsides... just some ideas.
On Mon, Jun 11, 2012 at 4:55 AM, Mike C. Fletcher <mcfl...@vrplumber.com> wrote:
|Re: [pygame] SGC 0.1.4 Released||Sam Bull||6/11/12 3:54 AM|
On Mon, 2012-06-11 at 09:31 +0200, René Dudfield wrote:With the test.py example, it was already possible to do the latter. I've
just added support to run it with the former command also. I'll add the
same support into the other examples soon, just as long as this extra
unrelated code doesn't appear in the tutorial.
Mike's right about relative imports not being possible, but you can get
the same effect from a little path mangling.
It's preferable to use the tarball release available on the right side
of the page:
The development code may break from time to time when I'm in the middle
of working on a new feature.
I'd like to keep the tutorials short and concise. How about instead,
I'll add an extra tutorial at the end which walks you through creating
an example program? And I'll add a 'more info' link to the other
tutorials linking to the appropriate parts of this example?
|Re: [pygame] SGC 0.1.4 Released||Sudo Bash||10/31/12 11:55 AM|
I second that. It is a very good way. I would, however, like to be able to use a different way depending on the situation. I would like the ability to initialize the button to a function and a tupple of arguments for the function. Something like this:
def __init__(self, ... , on_click=None, arguments=() ):
self.function = on_click
self.arguments = arguments
'''called when button is pressed, calls
the on_click function'''
if self.function is not None:
I realize that I can just overload the class or use the already built in on_click function, but it would be nice to be able to pass it some preset arguments too.
Default arguments could of course be done by lambdas; however, it is not the friendliest way, especially to new users who don't understand lambda Perhaps a note on lambdas could be included in the documentation.
Button(..., on_click = lambda: foo(arg1, arg2, arg3))
For example, a quit button could work like the following:
It runs decently, but if I put buttons, for example, in a real-time strategy game, that would be a lot of unnecessary updating. Since the buttons normally don't need to be refreshed this would be important.
How far out is it? This is going to be increasingly important to people. I am thinking about switching to Py3 soon. How about py2exe? Has that been tested?
I wish there was some standard for the color_key. I always use (255,0,255). Could there be some way to set it to a custom value other than (0,0,0)
|Re: [pygame] SGC 0.1.4 Released||oyewole adeleke||11/17/12 7:08 AM|
Hi Sam Bull,
How ru? I check the website called http://www.pygame.org.
Does this website belong to you? If no, could please help find the email address for this site?
Can I please some information, data and website like? I want
your permission, so that I can add this to my webpage. Christmas is
nearly here. I brought my Raspberry Pi kit from Maplins. It would be
nice for a child to have few games & apps to play with. I want to
help people get the best out of the Raspberry Pi. I'm still learn
about the Raspberry Pi & Linux. I am going to add the Omxplayer. When I
first got the Pi, I did not know that the wheezy-raspbian had Omxplayer (basic) which is
hidden. I would like to help people get the best out of the Pi for
Christmas. Keep up the good work.