On Jun 2, 11:45 am, Lynx <[email protected]> wrote:
> XML file: avoids running arbitrary code on a user's machine, since if
> data
> files exist, users will distribute mods for them
things like json and yaml that are human readable (for pickling
information) generally have a safe_load method to prevent arbitrary
code from running. JSON is a great choice (i imagine) since json
support is built into the latest python.
On another note, If you use a document format like xml or yaml, you do
get the added ability to load binary data into the doc so you could
say compile a theme file into a single human readable txt file, among
other things. Such things probably aren't going to fit most people's
idealogies of easy access to resources but if you generally want to
protect your artwork b/c you dont put it under a CC type license, then
it becomes a useful (though minor) deterent which is ussually all
thats probably worth doing.
>
> Single texture: less group context switching if they can all use the
> same
> group, and you can just assign a vertex list some new tex coords to
> change
> the picture rather than migrate it from one group to another.
>
Ive never profiled code doing stuff like this. Does this make a huge
difference? Whats with the migration of the group? Something specific
to simplui, right? Isn't group and batch migrations expensive
operations, as i recall from the documentation. Not sure why this
would need to be done.
> Then, a GUI theme editor that allows you to load a skin texture file
> and create an XML file, and you're good to go!
go theme editor! isn't such things always the best way to show off
your toolkit.
All this talk about gui's made me go back and implement a layout in my
gui system i have right now. As per before, everything is of class
Widget or extended from such (ussually extensions consist of window
and soon-to-be animation events). Now each widget can display as a
block or inline and it flows from top to bottom. Also as before, the
top level widget holds the batch and background/foreground groups that
all its children use.
The two groups are for dropdowns, tooltips, etc, those kinds of
things. Its still got a couple static things for special controls but
using just the Widget class should work just fine. Right now declaring
everything is a little verbose, but for example
dialog = Widget(parent=None, position=(200, 100)) # global position on
window
dialog.sprite = 'background.png' # its a helper, you can optionally
pass a pyglet.sprite.Sprite object but should declare
batch=dialog.batch, group=dialog.background
p1 = Widget(parent=dialog, text='Bonjour Mary!') # again, you can pass
pyglet.text.Label object but should declare batch and group
appropriately
label_users = Widget(parent=dialog, text='Select User: ')
label_users.display = 'inline'
select_users = Select(parent=dialog, options=['john', 'jane', 'joe',
'jill', 'mary']) # this uses some images delcared in the class, need
to push that into init options
@window.event
def on_draw():
window.clear()
dialog.draw()
I use @property decorators as i find them much more readable, i think
that means you need python2.6 iirc, anyone interested at looking at
giving themselves a headache by looking at sparsely commented code can
check it out here.
http://python.pastebin.com/m4a34f8bb
Im going to have this library together for the initial public release
of my vizi sound project and will probably feature tie ins to the work
i did on abstract controls (abstract as in art i guess) as well as tie
ins to box2d for various crazy use cases.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
