Re: [pygame] GUI

["ShredWheat" <shredwheat@mediaone.net>]

> Well, this question is probably just more of the same then, but since
> we're on the topic:  What chance is there that PyGame will be able to act
> on a screen which is embedded on a Tk canvas?  Or even a wxWindows one
> (heck, I'm not picky!)?  Would that be simpler than implementing a native
> SDL GUI kit from scratch?  Granted, that means that your GUI would
> (probably) only be usable as an adornment to PyGame on the borders of the
> main SDL screen, but it's better than nothing.

getting a pygame surface into a separate window manager is going
to be a bit of work. currently, i see this question pop up on the
SDL mailing list from time to time, and there is not real easy way
to do it. there is an example out there of a C program mixing SDL
and GTK. i know there's a python GTK binding, so i'm not sure if you
could look at the C example and try to do something similar.
(never looked at it myself)


if you want to use SDL graphics and sound with something like TK, 
i imagine it would be possible if you do it like this...

Firstly, SDL can support just about any image type out there. All
the GUI libraries should be able to take some type of image and
paste it onto the screen. (heh, again, not too much experience).

What you'll want to do is initialize pygame's display module
(and mixer if you want sounds/music). The trick is to never call
pygame.display.set_mode(). You'll need to let whatever GUI you're
using handle all the windowing and input.

from here it should be easy to create a basic offscreen surface that
is in some useful format that the GUI library can handle. (8bit colomap
would be an easy guess). Then you just do all you blitting and action
into the offscreen surface just like it was the screen object. Then,
instead of calling pygame.display.update() (or flip()) you would make
some call in the GUI library to copy the offscreen image onto the GUI
window.
getting the sound and music would be extremely basic. it shouldn't
take anything special to get that working.
the main difference would be that all input events (mouse/keyboard)
would need to come from the GUI library. the way most platforms work
is that whoever is in charge of the window is in charge of the input.
this likely means that there would be no joystick support for your pygame
program running inside another GUI toolkit.

well, does this make much sense? SDL has some handly tools for
wrapping a surface onto some area that already exists in memory.
i haven't quite made similar functions for that in python.

my guess is it will all come down to needing one function that makes
a GUI bitmap and SDL surface share the same memory space. if you get
that far and have some info on what type of bitmap the GUI toolkit
is using and how to best get that hooked to SDL it should be pretty
easy to write!



> Just want to say this too:  THANK YOU, THANK YOU, THANK YOU!  You saved me
> from having to go back to VB or the very cool (and very non-portable)
> BlitzBasic for the game I just started working on.  Tkinter based
> animations were way too slow (I never did figure out how to get
> transparencies for sprites working anyway) and I was starting to get
> frustrated with the Python based options; raw SDL looked too intense for
> my time availability.  Anyway, thank you again and I hope you're finding
> this to be a rewarding endeavor!!!

glad it's helping. i still feel like there's so much i want to get
done for this, but pygame is actually pretty usable where it's at now.
what type of animations are you trying to do? (aliens style? heh)

you got me snooping around the blitzbasic site looking for good
ideas for pygame! if you know of features that are extremely useful
in blitzbasic but difficult to do in pygame, i wouldn't mind hearing
about that either :]


____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org