I think it would be useful to make another 1.1.x release that integrates cocoa support in a manner acceptable to all. I think not relying on PyObjC 2.3 is a good thing, and ctypes is sorta messy by definition. But. it should be ultimately up to whomever will support and maintain that code to decide which is better, with the caveat that the PyObjC dependancy is not a deal breaker. Can PyObjC be auto-installed via setuptools (or whatever)? If so then it could just be added as a dependency. Granted autoinstalling into the Mac system Python is probably going to suck. Probably some smarts could be added to setup.py to prevent folks doing that blindly.
-Casey On Thu, Apr 28, 2011 at 2:44 AM, Phillip Nguyen <[email protected]> wrote: > > > On Apr 27, 2:45 pm, Bruce Smith <[email protected]> wrote: >> On Mon, Apr 25, 2011 at 12:05 AM, Phillip Nguyen <[email protected]> >> wrote: >> >> > On Apr 24, 9:59 pm, Leonardo Santagada <[email protected]> wrote: >> >> Any news on this? How about merging it back in pyglet trunk? >> >> > The ubiquitous send_message() weirdness that I am using in the cocoa- >> > ctypes clone seems like it would not be very maintainable to me, so I >> > don't think it would be a good idea to merge it into the trunk as it >> > is. I could be wrong though. >> >> I think keeping it in a separate branch causes definite harm and not >> much good, and I think the question of when to merge it is independent >> from the question of whether all the bugs have been fixed (given that >> merging it won't affect systems that run the other platforms, and that >> all systems that can use Carbon will still do so by default). This is >> why I'm in favor of merging it back into the trunk as soon as >> possible, regardless of bug status. > > Just to make sure that we're all on the same page, because I think my > previous post may have not been clear, I *did* already merge the > PyObjC-based Cocoa port of Pyglet into the trunk back in March. It's > fully functional. The only catch is that you have to have PyObjC 2.3 > installed for it to work properly, and it seems that several people > have run into problems getting PyObjC 2.3 installed. > > The ctypes-based Cocoa port of Pyglet that I hacked together and put > up as a clone (I assumed this is what Leonardo was asking about) also > is fully functional without requiring PyObjC at all, but the code > looks like a mess to me. If you're suggesting that we should merge > this into the trunk, replacing the PyObjC-based code, then I'm open to > the idea. But I would like to hear some opinions from others first, > especially after they have reviewed the ctypes-based code. > > Is the PyObjC dependency that big of a problem? My impression from > PyWeek is that there aren't that many people using the 1.2dev version > of Pyglet anyway for it to really matter . . . actually I think it > might be worthwhile to have a discussion in another thread about > current Pyglet development. > > -- > 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. > > -- 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.
