Let's start out with a list of things that I want, roughly in order of importance:
A possibility is to rely on an external debugger like Winpdb http://mithatkonar.com/wiki/doku.php/qt:pyqt_ide_options– which is why debugging is listed toward the bottom. Profiling? Dreaming.
In almost all cases, getting good autocompletion/calltips requires adding api files, references to libs, or possibly both.
The following are needed specifically for easy PyQt4 development:
<formname>.uifile as well as a
<formname>.pyfile that defines a
*.qrcQt resource files
These are designed as editors only but promise Python-pleasing features. Setting up to make a good IDE context will be non-trivial.
Even more than the above, but then you can roll-in things you want like
One possibility is to make a Rope plugin for Monkey Studio.
means good, ~ means eh, – means available but sucks, ✘ means not possible/not available, ext means handled externally automatically or by specifying a user command
|Monkey Studio||–||?||✘||~ ext|
* After significant manual intervention
|IDE||PyQt proj||PyQt forms||qrc files||designer|
* With Qt support from Nokia, has nice GUI for adding resources, but compile with pyrcc4 for python must be done manually.
† Need to check what happens w/ Qt for Eclipse stuff from Nokia
‡ With just Eclipse+PyDev, it's external. With the Qt for Eclipse stuff from Nokia, it's either.
p means untested plugin available
t means template, not wizard
!!! means it's ill on Linux because of MIME issues (works with GNOME, Xfce (I think), and KDE (maybe), but not in others)
†† has facility to add
*.ui files (as XML) but not the corresponding
* API based
† Needs custom config (adding lib to PYTHONPATH or tweaking Rope config or similar)
‡ With Eric4's Rope plugin you can select the identifier, and then do navigation with Refactoring → Query → <an option>, then double click on an entry (or assign a keyboard shortcut to bring up the dialog and enter to dismiss and goto.)
I have some results in pyqt ide autocompletion testing.
If project wizards were not available or were poopy, evaluations were made using this project that originated with Monkey Studio.
It looks like we're not getting out of this without making a standalone PyQt4 App wizard.
We may have to also make a standalone refactoring system.
Definitely needing to be solved is mapping *.ui files to Designer on my system (probably with a new mime type).
It's freaking heavy and bit obtuse. Setting up is a multi-step process. Once set up, to get code completion to work, you need to add the PyQt lib path (
/usr/lib/pymodules/python2.6/PyQt4) to project's PYTHONPATH. (You need to specify extra info for PyQt to a lot of IDEs, but this is one of the cases where the info needs to be provided on a *per project* basis.) Even then, the code completion doesn't seem to always pick up variables declared in the file itself–unless it's just slow or requires a Ctrl+Space to make go. This needs testing. But once it gets going, it seems to be really nice.
There is no PyQt integration in PyDev and none available elsewhere it seems. No PyQt form creation automation, no PyQt project creation. Does adding Qt stuff for CDT from Nokia and CDT help this?
There are three installation options, and each will provide a different set of features (and startup time/RAM use?):
*.uiform files, but not the associated *.py (obviously)
*.qrcresource files along with a nice resource manager interface
Yes. Autocompletion needs more testing. Biggest con: it's a resource hog. Setting up is a bit of a PITA. Setting the per-project PyQt4 stuff is definitely a PITA.
Designed as a text editor, with plugins makes a decent IDE. It's in alpha now but usable.
Hugely promising. UI a little awkward to use, but the basic features are there. When autocomplete and calltips work, it's beautiful–but I think the system might be fragile.
The default UI is painful by default but can be tweaked. Rope handles refactoring. Hg support listed on homepage but is only available in Eric 5. PyLint plugin available. Lotsa custom tweaks and plugin downloading required.
A project wizard exists but doesn't really make a PyQt4 project. Adding forms is a little different but doable – but I can't figure out how to add custom slots to e.g.
mainwindow.py because any changes to the
mainwindow.ui file requires “recompiling” to
mainwindow.py, nuking all your changes. Solution seem to be not to use the “Eric way” of building forms–i.e., compiling the py files from ui files–and instead use the “Monkey Studio way” of reading the ui file into a module when it runs. This may be fixable with a change to the template so it uses the same
from PyQt4 import uic (Ui_MainWindow, QMainWindow) = uic.loadUiType('mainwindow.ui') class MainWindow (QMainWindow): """MainWindow inherits QMainWindow""" def __init__ (self, parent = None): QMainWindow.__init__(self, parent) self.ui = Ui_MainWindow() self.ui.setupUi(self) def __del__ (self): self.ui = None
structure that Monkey Studio uses.
There are three autocompletion/calltip providers available: QScintilla, Rope (a plugin that also handles refactoring), and Assitant (a plugin).
To get QScintilla to give decent results, you need to point it to API files. This can be done by installing package eric-api-files and manually pointing Eric at them (Settings→Preferences→Editor→API). There's also a script eric4-api to make apis for you. The resulting files are full of ?4 and other strange things the meanings of which are unknown to me. You only need to configure the API file location once. However–and this is the major problem with API-based autocomplete/calltips–if the API changes you'll have to manually update it. And you will forget to do that.
Rope's offerings were quite poor until I changed its config to this one (which takes its values from a Rope testing script I downloaded from the Spyder Google Project Hosting site):
# The default ``config.py`` def set_prefs(prefs): """This function is called before opening the project""" # Specify which files and folders to ignore in the project. # Changes to ignored resources are not added to the history and # VCSs. Also they are not returned in `Project.get_files()`. # Note that ``?`` and ``*`` match all characters but slashes. # '*.pyc': matches 'test.pyc' and 'pkg/test.pyc' # 'mod*.pyc': matches 'test/mod1.pyc' but not 'mod/1.pyc' # '.svn': matches 'pkg/.svn' and all of its children # 'build/*.o': matches 'build/lib.o' but not 'build/sub/lib.o' # 'build//*.o': matches 'build/lib.o' and 'build/sub/lib.o' prefs['ignored_resources'] = ['*.pyc', '*~', '.ropeproject', '.hg', '.svn', '_svn', '.git', '.eric4project', '_eric4project'] # Specifies which files should be considered python files. It is # useful when you have scripts inside your project. Only files # ending with ``.py`` are considered to be python files by # default. #prefs['python_files'] = ['*.py'] # Custom source folders: By default rope searches the project # for finding source folders (folders that should be searched # for finding modules). You can add paths to that list. Note # that rope guesses project source folders correctly most of the # time; use this if you have any problems. # The folders should be relative to project root and use '/' for # separating folders regardless of the platform rope is running on. # 'src/my_source_folder' for instance. #prefs.add('source_folders', 'src') # You can extend python path for looking up modules #prefs.add('python_path', '~/python/') # Should rope save object information or not. prefs['save_objectdb'] = True prefs['compress_objectdb'] = False # If `True`, rope analyzes each module when it is being saved. prefs['automatic_soa'] = True # The depth of calls to follow in static object analysis prefs['soa_followed_calls'] = 4 # If `False` when running modules or unit tests "dynamic object # analysis" is turned off. This makes them much faster. prefs['perform_doa'] = False # Rope can check the validity of its object DB when running. prefs['validate_objectdb'] = True # How many undos to hold? prefs['max_history_items'] = 32 # Shows whether to save history across sessions. prefs['save_history'] = True prefs['compress_history'] = False # Set the number spaces used for indenting. According to # :PEP:`8`, it is best to use 4 spaces. Since most of rope's # unit-tests use 4 spaces it is more reliable, too. prefs['indent_size'] = 4 # Builtin and c-extension modules that are allowed to be imported # and inspected by rope. prefs['extension_modules'] = ["PyQt4", "PyQt4.QtGui", "QtGui", "PyQt4.QtCore", "QtCore", "PyQt4.QtScript", "QtScript", "os.path", "numpy", "scipy", "PIL", "OpenGL", "array", "audioop", "binascii", "cPickle", "cStringIO", "cmath", "collections", "datetime", "errno", "exceptions", "gc", "imageop", "imp", "itertools", "marshal", "math", "mmap", "msvcrt", "nt", "operator", "os", "parser", "rgbimg", "signal", "strop", "sys", "thread", "time", "wx", "wxPython", "xxsubtype", "zipimport", "zlib"] # Add all standard c-extensions to extension_modules list. prefs['import_dynload_stdmods'] = True # If `True` modules with syntax errors are considered to be empty. # The default value is `False`; When `False` syntax errors raise # `rope.base.exceptions.ModuleSyntaxError` exception. prefs['ignore_syntax_errors'] = True # If `True`, rope ignores unresolvable imports. Otherwise, they # appear in the importing namespace. prefs['ignore_bad_imports'] = True def project_opened(project): """This function is called after opening the project""" # Do whatever you like here!
With this config, I think Rope starts to become useful but for the fact that calltips show blank parameter lists and no return types (bug report filed.)
Setting up Assistant also requires API files. Supposedly it “adds support for icons in completions determined from document.”1)
If the problem with Rope calltips can be solved (no arguments shown) then Eric4 would be the one to use. The best interim solution seems to be to let Rope do autocomplete and Assistant do calltips. This is a usable but imperfect setup. Eric ships with a command-line tool for generating API files from source files.
Eric Assistant makes minimal use of icons in its popups – subjectively better than Spyder (but without the extra info) and not as nice as Editra (but more complete).
At the moment, I am inclined to rate Spyder and Editra's tied (for different reasons) and just ahead of Eric's – but this very well may change.
No real time error checking.
Starting “Interpret” and “Debug” of files/projects brings up an arguments dialog. I can't figure out how to turn that off.
Debugger works but doesn't seem that friendly.
Has qt resource file support.
Maybe. Major hassle setting it up but can be simplified with by distributing an
*.ini file, icons, API files and instructions. If project and form adding/handling can be sorted out, it's a possibility (but doing this within the IDE structure is looking increasingly grim). Getting rid of the “arguments” dialog when executing would be nice, as would better GUI icons in general (which I have taken care of). Biggest con: Autocomplete/calltip needs API files (rather than being ) and an odd mixture of tools.
Very fast but UI lacks “Go” button (but shortcut is programmable), defaults to “save before go” to see changes but can be changed thru preferences. Code completion exists but is limited, but you can make it reference API files (e.g.,
/usr/share/eric/api/python/pyqt.api file that ships with Ubuntu's “eric-api-files” package)2). Calltips appear as Scintilla-esque one liners with up/down icons to let you select the tip you want to see. No real-time error indication. No Python debugging support–though support for external commands looks present. No PyLintish stuff, but possibly via external command. Really good PyQt project template built-in, and adding templates is straight-forward. This is the only IDE that I can say either of these about. Achilies heel is code (in)completion and calltips – maybe can be improved with api files.
That leaves (1) refactoring, which short-term could be User Tooled out to a refactoring-enabled (i.e., Roped) editor and (2) debugging, which could be User Tooled out to winpdb or something similar.
I sent a comment to the author several days ago about autocompletion and haven't heard back yet. The forums show the most recent activity was 3 weeks ago.
No. Code completion needs more experimentation (do I need to reload the API every time I start?), and support for refactoring needs to be sorted out. Biggest con: autocompletion is API based but there is no packaged API tool as there is with Eric; also project maintenance/mindshare seems lacking.
Python support seems stalled. No PyQt project template. Designer is external. Debugger doesn't work well with PyQt. “Python refactorting is approximate. Review all changes.” File templates don't exist but are fairly easy to add. Project templates don't exist and are difficult to add well. Code completion brings up a huge list of nonsensical stuff and is agonizingly slow. There are a couple references to “tests” in the UI, but it didn't look like either was for lint-ish testing.
No. The code completion offerings are worse than no completion at all.
Actually designed for MATLAB-ish work but works pretty well as a general purpose IDE.
Maybe. If the authors added refactoring (it already uses rope for autocompletion and calltips) it would be hard to beat.
Project templating again seems to be an issue.
Comes highly recommended, but payware makes it less than appealing. No cost licenses to educators, etc are available, but still, it's not FOSS.