[IPython-user] Qt gui now usable (sort of) :-)
Ville M. Vainio
Sun Nov 30 14:49:58 CST 2008
On Sun, Nov 30, 2008 at 10:13 PM, Richard Riley
> Out of curiosity, and possibly naivety, why expend effort on this? Whats wrong with iPython in
> a console? I can understand an iPython for an editor like emacs (works
> great) in order to drive ipython from edit buffers, but why another
> stand alone QT GUI front end?
Glad that someone asked!
- One reason is integration with other tools (embedding). The console
takes "too much" control, and doesn't always play well with gui event
loops. The "threading" versions of ipython shells (to be used with qt,
gtk et al) are a constant source of woes. My particular use case for
this is "ILeo":
http://webpages.charter.net/edreamleo/IPythonBridge.html - Leo is
being ported to Qt, and I want IPython to be first class citizen
Sometimes the console ipython can be comfortably integrated with gui
event loop using PyOS_InputHook, but esp. with Qt & windows, it was
too slow. Tk is a well-behaved exception it this respect.
- We can offer better feature set with gui shells. For example, the qt
shell allows seamless multiline editing using the qscintilla feature
set, while multiline editing with console ipython is not that stellar
(unless you switch to an external editor using %edit, losing tab
completion). Other features are basically limited by people's
imagination (think object browsers, namespace searchers, clickable
- readline is a recurrent pain, and cause of bugs that just can't be
fixed - whereas with gui shells, we can make things behave pretty much
the way we want.
Obviously the "classic" terminal ipython isn't going anywhere, since
it can be used be where the gui shells can't (and for simple jobs,
plain terminal is probably the most elegant interface).
Ville M. Vainio
More information about the IPython-user