Those 2 issues are the major reasons I don't use pyglet at the moment, so they are critically important to me. But at the same time I understand completely why he's not doing them, and support that. Basically he wants to do what he can do well - He wants no dependencies whatsoever and wants everything to work well and reliably cross platform.
Also, there are no patches he is refusing for those features and there is no reason why those features couldn't be independently implemented, or monkey patched into pyglet or any of that. Furthermore he releases pyglet under the generous BSD license (much better than GPL, in my opinion) so he's basically saying if you want to make a fork and relicense it how you want, go ahead just do attribution. Really I think there's nothing to fault him on here. If you really want this stuff, I would suggest you go start writing it. Resolution changing isn't that hard really, there is plenty of source for it, SDL has it for tons of platforms, and ctypes makes it easy to call platform stuff from python. Customized texture to texture blitting is actually even easier to write as long as it can go super slow. I understand it's better to have those things in a library so people can help you with the really hard work of testing and iterating and improving until it's great - but who knows, maybe Alex would help you with all that by putting it in pyglet if you had a good start at it. On Sun, Sep 7, 2008 at 11:20 PM, 3TATUK <[EMAIL PROTECTED]> wrote: > > What are your general opinions on the following two issues? > > 1. The lack of monitor resolution changing capability > 2. The fact that image.Texture.blit_into() isn't alpha-aware > > The bottom two URLs link to more specific info/discussion about these > issues, to which Alex has basically responded to saying he thinks it's > out of pyglet's scope to implement these two features. > > I highly disagree. > > I mean, I'm not demanding here 'ALEX: CODE THIS STUFF'.. but I'm > saying why completely reject them? Maybe put them on the 'to do > slate', if not at least say something like 'if someone codes it, i > will include it'? > > I mean the way Alex is currently responding is as if someone hands him > the code he won't even be willing to add it to pyglet..? > > I think these two are both _utterly_ in the realm of pyglet _and_ are > pretty significant things to have. > > :) > > > 1. > > http://groups.google.com/group/pyglet-users/web/issues-with-full-screen-resolution > > 2. > > http://code.google.com/p/pyglet/issues/detail?id=340&can=1&sort=-id&colspec=ID%20Status%20Type%20Milestone%20OpSys%20Summary > > > > Cheerio! > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
