As far as I know, the minimal implementation for the window and a clickable
Thing is similar to the following:
# First we need PyGlet, window and image for the faces.
from pyglet import window, image
# And the pyglet events
from pyglet.window import event
# and the mouse events.
from pyglet.window import mouse
# And we want to be able to wait a bit (and save processor time).
from time import sleep
class Window(pyglet.Window):
def __init__(things=[], *args, **kwds):
super(Window, self).__init__(fullscreen=True)
self.things = things #: The list of things which appear on the screen
def action():
"""Do whatever the class should do in each loop"""
pass
def event_loop():
self.dispatch_events()
self.clear()
self.action()
self.flip()
# wait for 3ms which is quite unnoticeable but massively reduces CPU load
sleep(0.003)
def on_mouse_release(self, x, y, button, modifiers):
"""Check, if a mouse-click hit a card. If yes, perform the clicked()
action."""
for i in self.things:
if i.is_inside(x, y):
i.clicked()
class Thing(object):
def __init__(image_path, *args, **kwds):
# super is necessary here to make multiple inheritance possible for
subclasses.
super(Thing, self).__init__(*args, **kwds)
self.image = image.load(image_path) #: the image to show
def is_inside(area, x, y, width=0, height=0):
"""Check if the given coordinates (optionally: A part of the given area)
is inside.
If the given coordinates or some part of the object given by the coordinates
and width and height are in the area, return true."""
# Do so. For an example, please check the attached files.
pass
def clicked():
"""Perform whatever action should be done when the icon thing was
clicked."""
print i, "was clicked."
For the mouse gestures, you might also need some mouse-tracking code since
this code only covers clickable Things.
Best wishes,
Arne
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "pyglet-users" group. To post to this group, send email to
> pyglet...@googlegroups.com To unsubscribe from this group, send email to
> pyglet-users...@googlegroups.com For more options, visit this
> group at http://groups.google.com/group/pyglet-users?hl=en
> -~----------~----~----~----~------~----~------~--~---
--
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken.
- Arne Babenhauserheide ( http://draketo.de )
-- Weblog: http://blog.draketo.de
-- Mein öffentlicher Schlüssel (PGP/GnuPG):
http://draketo.de/inhalt/ich/pubkey.txt
Google "GLUT"
> As far as I know, the minimal implementation for the window and a clickable
> Thing is similar to the following:
What you've outlined is a minimal *use* of an existing pyglet Window.
Richard
In short - and I'm a little hazy on this because it's been a long time since I
last had my hands in the window code - the core responsibility is to provide
an OpenGL context. Of course there's a lot that goes into that - capabilities
requested by the programmer, handling multiple screens, etc. You might find
it useful to examine the existing pyglet.window.carbon implementation since
it's one of the most straight-forward of the three.
Richard
Of course, since the OP is targetting the iPhone, there's probably no
need to support multiple screens or capabilities ;-) Porting any
minimal OpenGL Cocoa example to Python would be sufficient to get
started.
The story as of a week or so ago was that PyObjC hasn't yet been
ported to the iPhone CPU (ARM?) (which is your only possible interface
to Cocoa).
Alex.
I didn't think that could work, but it did!
(In german "Glut" is the word for "glow", so I was quite sure that googling
wouldn't give me useful results)
> What you've outlined is a minimal *use* of an existing pyglet Window.
I misunderstood you. Sorry.
Wishes,
Arne
Great stuff. It's been widely reported on the blogs, slashdot etc
that the license terms for distributing an application over the iPhone
store (the only way for non-developers to get install additional
software) prohibit applications that require a non-Apple-bundled
interpreted language (i.e., Python). Quote:
"No interpreted code may be downloaded and used in an Application
except for code that is interpreted and run by Apple's Published APIs
and builtin interpreter(s)… An Application may not itself install or
launch other executable code by any means, including without
limitation through the use of a plug-in architecture, calling other
frameworks, other APIs or otherwise."
http://blog.mozilla.com/rob-sayre/2008/03/06/apple-bans-firefox-spidermonkey-lisp-lua-ruby-python-rhino-java-opera-gcc/
I haven't checked the license agreement to verify the context of this,
as reading it requires an iPhone developer membership, which in turn
requires me to answer loaded questions that imply I intend to develop
for the iPhone (I don't).
To me this looks like Python/pyglet on the iPhone is restricted to
hobbyist activities only.
Alex.
The key terms are "downloaded and used" and "install or launch other
executable code" - meaning the app is forbidden from running anything
*outside* of the app. If all the code (python or otherwise) the app
executes is part of the signed iPhone bundle, it wouldn't be a
violation of the terms at all. There's nothing in that particular
clause that restricts interpreted code within the app.
Either someone at Apple doesn't understand the notion of a Von Neuman
architecture, or *I* don't understand the gist of this license. :)
On Wed, Mar 12, 2008, Brian Fisher <thor...@gmail.com> wrote:
> The key terms are "downloaded and used" and "install or launch other
> executable code" - meaning the app is forbidden from running anything
> *outside* of the app. If all the code (python or otherwise) the app
> executes is part of the signed iPhone bundle, it wouldn't be a
> violation of the terms at all. There's nothing in that particular
> clause that restricts interpreted code within the app.
Is there anyone in the iPhone community that is interested in trying
to get a signed Python framework for the iPhone?
-Peter