I'm interested in playing around with OpenGL in Python. I've used OpenGL in C++ and Objective-C, but I don't have much experience in Python. I'm wondering if there's a good tutorial that works in Snow Leopard. I'd prefer to stay in 64-bit mode if possible, since I've heard 32-bit programs require loading a lot of extra 32-bit libraries.
I've already tried a PyOpenGL/wxPython tutorial. When I ran the code, it crashed with this message:
ImportError: /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode/wx/_core_.so: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode)
It looks like there's a bug in wxPython that prevents it from working on a 64-bit system.
I also looked at Pyglet, but they have a similar issue. They provide a work-around (setting Python to 32-bit mode), but it doesn't look like they're going to fix it.
Finally, I looked at PyGLUT, but I think it's only for Windows.
Are there any other libraries that would let me access OpenGL and draw on the screen? Again, I'd prefer to stay in 64-bit mode, but if nothing works, I'll switch to 32-bit and try wxPython or Pyglet again.
Edit: I've also tried PyGame. It depends on SDL which is broken in SL. I thought about trying to use Cocoa through PyObjc, but the Xcode Python application templates have been removed.
I've used PyOpenGL 3.0.0 quite successfully on Snow Leopard. It uses ctypes, so it should be making 64-bit calls if those libraries are available (and Snow Leopard's Python includes a 64-bit version). I haven't used the wxPython stuff with PyOpenGL so that's where you might be running into problems, but PyOpenGL also includes GLUT, which both run fine.
There's probably no good reason to avoid 32-bit mode. Unless your Python programs need to larger address space, of course.
You could try pygame. Pygame is a python wrapper around SDL. According to their website they have Max OS X binaries. Here is a simple example of using pygame with OpenGL. Once you are able to create the window and handle events most OpenGL programming is just like it would be in C or C++, but with some added python goodness. For OpenGL a great tutorial is NeHe.
Also when programing with OpenGL in python remember that Python datastructures can be rather slow when it comes to requirements for 3D graphics. PyGL developers for example recommend using ctypes for operations that concern graphics, since that way you can get enough performance for some complicated geometry with bareable FPS.
Related
I am writing a wxPython GUI. For certain functionality this requires that I use the Enthought distribution of python, but when I upgraded to Canopy it completely breaks my GUI. When I call up a certain window, everything freezes and I have to force quit. I don't get any kind of error message or traceback, just a freeze.
I am using the 64 bit Canopy, version 1.4.0.1938, and wxPython 2.9.2.4.
I am looking for either of two kinds of advice. 1. What is a good debugging protocol in this kind of situation? 2. How to get wxPython and Canopy to play nice?
I greatly appreciate any suggestions. I am happy to include any code that might be helpful, but I suspect that this is not particularly specific to my code.
edit:
I need the Enthought distribution specifically because my GUI builds on older code that uses some of the data analysis and plotting that EPD provides. This GUI actually incorporates and streamlines several older GUIs for analyzing paleomagnetic data.
This question is inaccurately titled and both your question and your own answer to it are inaccurate and incomplete. On the evidence, and from your comments on the Enthought knowledge base, your problem is twofold:
1) You want to use WXPython 2.8 in 64-bit Python on OSX. This is a fundamental technical impossibility because WxPython 2.8 uses Carbon OSX graphics, which is not supported for OSX 64-bit programs.
2) Failing that, you expect your program to run unmodified with WxPython 2.9 but apparently you have not taken any steps to migrate it to WxPython 2.9. See http://wxpython.org/migrationguide.php.
(Edited 5/6/2014)
My temporary solution was installing the 32 bit version of Canopy and then using the Package Manager to install an older version of wxPython (2.8.10.1). This worked temporarily, until I was able to get to the actual cause of the error.
https://support.enthought.com/entries/22601196-wxPython?page=1#post_22146884
The real problem did indeed turn out to be the version of wxPython.
The specific issue was calling ShowModal() instead of simply Show() for the main window of the GUI, which apparently worked in wxPython 2.8 but caused a freeze in 2.9. The code now thankfully works with 64 bit Canopy. Thanks to Jonathan March for pointing me in the right direction.
I am running OpenCV2.2 on Windows 7 64-bit.
I built OpenCV using cmake with MinGW 32-bit.
I have no problem with the C/C++ build. However the python bindings seem to have some problems. Most of the python samples are crashing.
The HighGui functions seem to cause trouble. Python crashes when I try to read an image (using imread, LoadImage or LoadImageM), display an image (imshow or ShowImage) or even create and manipulate windows (NamedWindow, MoveWindow, etc).\
WaitKey doesn't crash python but it always returns a -1 immediately, no matter how long the delay I provide. Similarly imgproc functionality listed under "Image Filtering" in the reference seem to crash python. I haven't been able to test it with too many other functions, mainly because I can't load in images and I am forced to test it with matrices i have built myself.
I am currently using python 2.6.6 (32-bit) , but I got the same problem with python 2.7 (32-bit). I also tried building the python wrappers for OpenCV2.1, and I got the same problem. It's very likely a problem specific to my setup. I've been cracking my head against this problem for quite some time now, I would appreciate any help.
Thanking you in advance.
Regards,
Anush.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm thinking of making some kind of experimental IDE for digital hardware design. So I can't decide witch platform to choose.
I'm going to have text-editor with syntax highlighting, some vector graphics and lots of tabbed windows.
My goals:
1. to make GUI using as less custom components as possible.
2. to make it as cross-platform as possible
(I know already that CPython and Jython are cross-platform-friendly, but what about IronPython+Mono?)
So - the question is about GUI - what should I choose?
IronPython with Mono is cross platform - to whatever platforms supported by Mono, and for the feature set supported by Mono (which pretty much means Windows Forms is supported fairly well). Other options for GUI toolkits are available, however, which may provide better "cross platform" capabilities, or at least a better feel on non-Windows platforms.
CPython will depend on the GUI suite you choose. Personally, I've found CPython with PyQt to be the most usable, cross platform GUI option from Python. It's very powerful, feature-rich, and works quite well.
Jython will work, but I personally don't like the GUI options as much (this is a 100% personal preference, however).
I'd say that if cross-platform is a goal, forget IronPython. A lot of people hate the dependency hell it causes so it'll be too much work to get it up in running in some OSes/distributions. Jython will suffer this also, albeit to a lesser degree.
Well, Mono does not come with the base of most Linux distributions. It's not a terribly lightweight dependency either, and I think Java is considerably more likely for people to already have. Would you plan on using "Winforms" with Mono? If so, and you don't have experience with Winforms, read about what others have to say :-) The other .NET GUI toolkit is WPF, which unfortunately Mono has no plans to implement.
Jython would be better too, because you can use SWT, which renders native widgets and provides lots of layout possibilities easily. Or you can use Jython with Swing, or whatever else -- even AWT if you love ugliness.
I really like wxPython (which you can use with CPython, which is on most distros by default), because it renders good-looking native widgets in OSX, Windows and Linux (I've only seen the Gnome widgets in person). wxPython is by far the easiest to use GUI toolkit I've used -- even programatically (i.e. layout without Glade or similar). I've also used SWT, which I found quite nice, and Swing, which I personally don't really like the looks of, and Winforms, which was a nightmare to try to do even simple layouts with.
Here's a quick comparison of the existence of the interpreter/language runtime by OS
CPython
Windows - Probably not installed, and you'd have to make a non-python installer install it with your software :-P
Linux - Probably installed (Ubuntu, Gentoo and RedHat all have system tools that are written in Python and run on CPython)
Mac - Preinstalled on OSX
Jython
Windows - Probably installed at some point in my experience, though it doesn't come with
Linux - Probably installed, but more importantly nobody would hate you for depending on it like Mono
Mac - Preinstalled on OSX ("Mac OS X Leopard comes with J2SE 5.0 preinstalled, based on JDK 1.5.0_13_b05" -- Apple's site)
IronPython
Windows - Will probably run fine because I bet most people have at the very least .NET 2.0 if they have a recent version of Windows
Linux - Probably not installed -- the only application with which I've used Mono on Linux was Rasterbator, which worked well but I felt weird putting .NET on Linux
Mac - See above
I would choose a GUI toolkit first, since that will very much impact the user experience and overall difficulty (I would choose wxPython but SWT would be a close second) then consider the above as well maybe as a tiebreaker.
I faced this same question roughly a year ago. After looking at all the alternatives, I ended up with CPython and PyQt. IMO, Qt/PyQt is by far the best choice amongst all of the Python GUI toolkits. After hitting many bugs in wxPython I switched to PyQt and never looked back. Qt/PyQt are much more solid than the wx toolkits in my experience.
I use the exact same code base and build stand alone executables with PyInstaller for Windows and Py2App for the Mac (PyInstaller can be used for Linux as well). Because these builders embed the Python interpreter and all of the dependencies, it takes a lot of the hassle away. The only rub is that you'll need both a Windows and Mac to do the builds. Getting all of the configurations correct can be a pain too, but it's possible and time worth investing.
Take a look at comparable GUI's written in python/jython/ironpython. Look for programs that you like and find out what they use. I guess most if not all will be written in cpython + gtk or cpython + qt. I think all gui toolkits in python are cross platform.
Java is the most portable platform. Jython is written in 100% pure Java. 'Nuff said.
BTW I just switched a CPython/GTK project to Jython (trying to remove as much unmanaged code as possible), the only problem is that Jython is at 2.5 still, which kind of sucks when you're used to 2.6/2.7/3 :)
There are plenty of answers already, but I'd like to add one important thing - regardless of which library you learn, most of the principles will be the same when you move to another library.
I don't know about Qt, but for most graphics programs (in PyGTK or Tkinter) the best thing to do, as far as editing goes, is to use a PIL image (or something similar) to draw on and then draw that image on your canvas widget, otherwise you can lose pixel data if your window gets covered.
You may use Python 2.7 or 3.1 (CPython) with ttk (in Standart Library in 2.7, 3.1), ttk support themes (looks nice and very simple coding)
(1-st screen is text-editor with tabs and syntax highlighting) ttk screenshots
I am currently in a course that is using OpenGL and I have been using C for all the programs so far. I have Python installed on Fedora as well as OpenGL, however the minute I call an OpenGL command in my Python code, I get a segmentation fault. I have no idea why this is.
Just to avoid the "just use C" comments, here is why I want to use Python:
There are a couple reasons I am wanting to switch from C to Python, but the main one is because we are about to start writing a raytracer and I would like to use classes to make it easier on me. Since I hate classes in C++ and structs in C seems a little crazy, I thought I would give Python a try at it. I have also been looking for a reason to use Python again as it has been a while.
Thanks for any help.
You may also want to consider using Pyglet instead of PyOpenGL. It's a ctypes-wrapper around the native OpenGL libs on the local platform, along with windowing support (should handle most of the stuff you want to use GLUT for.) The pyglet-users list is pretty active and very helpful.
Well, I don't know if these are the libs the original poster are using but I saw identical issues in a pet project I'm working on (Graphics Engine using C++ and Python) using PyOpenGL.
PyOpenGL didn't correctly pick up the rendering context if it was created after the python script had been loaded (I was loading the script first, then calling Python methods in it from my C++ code).
The problem doesn't appear if you initialize the display and create the OpenGL rendering context before loading the Python script.
What OpenGL library are you using? What windowing library? What version of Python?
Most likely cause I can think of is that your windowing library (SDL or whatever you're using) isn't initializing OpenGL before you start calling into it.
We have neither ideas about random segmentation faults. There is not enough information. What python libraries are you using for opengl? How do you use them? Can you show us your code? It's probably something trivial but my god -skill ends up to telling me just and only that.
Raytracer in python? I'd prefer just doing that in C with those structs. But then, I'm assuming you aren't going to do a realtime raytracer so that may be ok.
Perhaps you are calling an OpenGL function that requires an active OpenGL context, without having one? That shouldn't necessarily crash, but I guess it might. How to set up such a context depends on the platform, and it's been a while since I used GL from Python (and when I did, I also used GTK+ which complicates matters).
Scripts never cause segmentation faults.
But first see if your kernel and kmod video driver working property ...
Extension modules can cause "segmentation fault".
I need to develop a small-medium sized desktop GUI application, preferably with Python as a language of choice because of time constraints.
What GUI library choices do I have which allow me to redistribute my application standalone, assuming that the users don't have a working Python installation and obviously don't have the GUI libraries I'm using either?
Also, how would I go about packaging everything up in binaries of reasonable size for each target OS? (my main targets are Windows and Mac OS X)
Addition:
I've been looking at WxPython, but I've found plenty of horror stories of packaging it with cx_freeze and getting 30mb+ binaries, and no real advice on how to actually do the packaging and how trust-worthy it is.
http://wiki.wxpython.org/CreatingStandaloneExecutables
It shouldn't be that large unless you have managed to include the debug build of wx.
I seem to rememebr about 4Mb for the python.dll and similair for wx.
This may help:
How can I make an EXE file from a Python program?
Python has an embedded GUI toolkit named TKinter which is based on Tk library from TCL programming language. It is very basic and does not have all the functionality you expect in Windows Forms or GTK for example but if you must have platform independent toolkit I see no other choice taking in mind that you also dont want to grow that much the binary.
Tkinter is not hard at all to use since it doesnt have millions of widgets/controls and options and is the default toolkit included in most python distributions, at least on Windows, OSX and Linux.
GTK and QT are prettier and more powerful but they have a one big disadvantage for you: they are heavy and deppend upon third libraries, especially GTK which has a lot of dependencies that makes it a little hard to distribute it embeded in your software.
As for the binary creation I know there is py2exe which converts python code to win32 executable code (.exe's) but im not sure if there is something similar for OSX. Are you worried because people could see the source code or just so you can bundle all in a single package? If you just want to bundle everything you dont need to create a standalone executable, you could easily create an installer:
Creating distributable in python
That's a guide on how to distribute your software when it's done.
http://Gajim.org for Windows uses python and PyGtk. You can check, how they did it. Also, there's PyQt for GUI (and wxpython mentioned earlier).
I don't have any experience building stand-alone apps for any platform other than Windows.
That said:
Tkinter: works fine with py2exe. Python Megawidgets (an "expansion library" for Tkinter) works fine also, but it does funky things with dynamic imports, so you need to combine all the components into a big file "pmw.py" and add it to your project (well, you'll also have pmwblt.py and pmwcolor.py). There are instructions for how to do this somewhere (either on py2exe wiki or in the PMW docs). Tix (an extension to Tk that you can use with Tkinter) doesn't work with py2exe, or at least that was my experience about four years ago.
wxPython also works fine with py2exe. I just checked an app I have; the whole distribution came to around 11MB. Most of that was the wx DLLs and .pyd files, but I can't see how you'd avoid that. If you are targetting Windows XP, you need to include a manifest in your setup.py or else it will look ugly. See this email for details.
I've used py2Exe myself - it's really easy (at least for small apps).
Combination that I am familiar with: wxPython, py2exe, upx
The key to resolving your last concern about the size of the distribution is using upx to compress the DLLs. It looks like they support MacOS executables. You will pay an initial decompression penalty when the DLLs are first loaded.